- Implementieren Sie Ihr Produkt basierend auf dem Entwurf (passen Sie den Entwurf ggf. an)
- Projektname muss Gruppenname enthalten!
- Maven:
- Das Produkt muss sich mit Hilfe von maven bauen lassen.
- Das Bauen muss ohne
mvn installfunktionieren. - Die Tests müssen über maven ausgeführt werden.
- GUI-Tests müssen sich ausschalten lassen.
- Andere Build-Tools wie Gradle
sind nicht (mehr) erlaubtdürfen maximal ergänzend verwendet werden. Maven muss aber funktionsfähig vorhanden sein.
- Sinnvoll: (echtes) Pair-Programing Pairprogramming (mit Tauschen der Rollen!): Hinweise zum Pairprogramming
- Es gibt ein Plugin für IntelliJ, mit dem man gemeinsam am Code arbeiten kann (habe ich allerdings noch nicht getestet)
- Code With Me: "Das kostenlose Plug-in lässt sich direkt aus der Entwicklungsumgebung heraus über Preferences / Settings | Plugins | Marketplace installieren" (https://www.heise.de/news/Entwicklungsumgebung-JetBrains-veroeffentlicht-Plug-in-fuer-Pair-Programming-4915934.html)
- Es gibt ein Plugin für IntelliJ, mit dem man gemeinsam am Code arbeiten kann (habe ich allerdings noch nicht getestet)
- Sinnvoll: längere Programmiersitzungen
- Erstellen Sie dabei die nötigen Systemunterlagen (tw. erst zum Ende des Projektes)
- Benutzerhandbuch,
- Testunterlagen,
- Installationshandbuch etc.
- Testen Sie die wichtigen Klassen mit JUnit, nicht erst am ENDE!
- Hilfreich: Dependency Injection (z.B. Google Guice)
- TestFX kann beim Testen der GUI helfen. Wichtiger sind aber Tests der Funktionalitäten!
- Beachten Sie, dass die GUI-Tests normalerweise nicht mit ausgeführt werden sollen, damit die Tests problemlos auch auf einem Build-Server (wie bamboo) ausgeführt werden können.
- Mocken Sie Abhängigkeiten in Unit-Tests mit Mockito
- Führen Sie Integrations- und Endtests durch
- Führen Sie mindestens ein dokumentiertes gruppenweites Code–Review durch
- Nutzen Sie Tools wie FindBugs oder Checkstyle, Checkstyle oder SonarLint
- Es ist grundsätzlich nicht erlaubt, Warnungen zu unterdrücken (Wenn Warnungen unterdrückt werden, dann muss es einen sehr guten Grund geben! Jede zusätzliche Warnung muss dokumentiert und begründet sein!)
- In Scrum muss ein Produktinkrement getestet und lauffähig sein.
- Versuchen Sie möglichst früh und regelmäßig die aktuelle Version auch auf dem Rechner in der Arbi zu deployen.
- Das MVP sollte "von Hand" erstellt werden und sich nicht auf Tools wie AfterburnerFX abstützen. Die Erfahrung zeigt, dass dies sonst im Laufe der Zeit viele Dinge (insbesondere Tests) unnötigt verkompliziert.
Page History
Overview
Content Tools