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.
Als Code-Formatter sollte der IntelliJ IDEA Standard genutzt werden. Falls Anpassungen erforderlich sind, sollten diese gemeinsam abgestimmt und anschließend hier importiert werden.
Zur statischen Codeanalyse werden in den Projekttemplates PMD, Checkstyle und FindBugs für Java, sowie Detekt und KTLint für Kotlin verwendet.
Für die Analyse der Architektur ist im Projekttemplate kein Standard hinterlegt, jedoch sollte mindestens eines der folgenden Tools verwendet werden.
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.
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.
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 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 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.
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.
″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.
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.
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.
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.