Skip to content

📜 Definition von Projektgerüsten inklusive einem Vorschlag zum Vorgehensmodell

Notifications You must be signed in to change notification settings

SmartsquareGmbH/smart-starter

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

17 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Smartquare Entwicklungsprozess

Dieses Repository definiert einen einheitlichen Entwicklungsprozess innerhalb der Smartsquare GmbH auf technischer Ebene. Eine Guideline zur Vor- und Nachbereitung eines Projektes kann der Projekt-Guideline entnommen werden. Die Projekttemplates in diesem Repository können gerne als Basis genommen werden und enthalten bereits vorkonfigurierte Analysetools.

Code Formatter 📕

Als Code-Formatter sollte der IntelliJ IDEA Standard genutzt werden. Falls Anpassungen erforderlich sind, sollten diese gemeinsam abgestimmt und anschließend hier importiert werden.

Statische Codeanalyse 📈

Zur statischen Codeanalyse werden in den Projekttemplates PMD, Checkstyle und FindBugs für Java, sowie Detekt und KTLint für Kotlin verwendet.

Architektur

Für die Analyse der Architektur ist im Projekttemplate kein Standard hinterlegt, jedoch sollte mindestens eines der folgenden Tools verwendet werden.

Code Coverage

Wir möchten uns in diesem Dokument nicht auf eine minimale Code Coverage festlegen, jedoch sollte jeder Entwickler auch durch die Code Coverage prüfen, ob zusätzlich zum TDD Zyklus Tests implementiert werden müssen. Die Coverage wird in den Beispielprojekten durch JaCoCo ermittelt.

Code Review 👮

Um die Qualität unserer Software stetig zu steigern sind Code Reviews eine gute Möglichkeit. Ein Code Review sollte mindestens ein mal vor einer Auslieferung oder Projektübergabe stattfinden, bestenfalls jedoch kontinuierlich während der Entwicklung.

Pull Requests

In der Vergangenheit haben wir gute Erfahrungen damit gemacht Features oder größere Refactorings in Pull Requests zu entwickeln. Eine Entwicklung muss dadurch vor dem Merge in den Entwicklungsbranch ein Code Review durch einen weiteren Mitarbeiter durchlaufen.

Mob Review

Mob Reviews sollten, ebenso wie Pull Requests, kontinuierlich in der Entwicklung stattfinden und sind generell vor großen Architekturentscheidungen zu empfehlen. Außerdem hat sich diese Art des Reviews nach Projektabschluss als nützlich erwiesen, um gemachte Fehler zu identifizieren und in der Zukunft zu vermeiden.

Pair Programming 👬

Pair Programming sollte generell nach Belieben praktiziert werden. Gute Erfahrungen haben wir in der Vergangenheit damit gemacht, dass ein Entwickler einen fehlschlagenden Test implementiert, der Zweite den Code Under Test entwickelt und anschließend einen weiteren fehlschlagenden Test implementiert.

Double Loop - Outside In Development ➿

Optimalerweise sollte die Entwicklung behaviour-driven oder acceptence-test-driven stattfinden. Dabei kann beispielsweise ein Feature mit Cucumber spezifiert werden und anschließend test-driven entwickelt werden. Alternative Bilbiotheken für dieses Vorgehensmodell wären JGiven und JBehave. ATDD Zyklus

Dokumentation 📃

″Working Software Over Comprehensive Documentation″, das ist auch unsere Ansicht als Smartsquare GmbH, jedoch erachten wir ein gutes JavaDoc und eine minimale Architekturdokumentation als sehr sinnvoll.

Architekturdokumentation

Um Dritten einen Überblick über die Anwendung und ihren Kontext zu geben sollte ein Architekturdokumentation gepflegt werden. In dieser Dokumentation sollte beschrieben werden in welchem Kontext die Anwendung existiert, warum sie existiert und welche Schnittstellen zu anderen Systemen existieren. Die Dokumentation sollte vorzugsweise als *.adoc verfasst werden. Ein Template nach arc42 findet sich hier.

JavaDoc

Das JavaDoc sollte verwendet werden um einem Dritten den Einstieg in die API eines Projektes zu erleichtern. Das bedeuted, dass package-infos, öffentliche Klassen und Methoden zu dokumentieren sind insofern eine nötige Komplexität erreicht ist.

Continuous Integration 🔄

Als CICD Plattform sollte vorzugsweise der interne TeamCity Server gewählt werden. Nachdem ein TeamCity Projekt angelegt wurde und der erste Build durchgelaufen ist, kann anhand dieser Dokumentation das Code Coverage Reporting aktiviert werden.

About

📜 Definition von Projektgerüsten inklusive einem Vorschlag zum Vorgehensmodell

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published