Entwicklungspraktiken development-practices

Arbeiten gemäß einer Definition von "Fertig" work-according-to-a-definition-of-done

Jedes Team hat eine andere Definition, was "getan"bedeutet, aber es ist wichtig, eine zu haben und sicherzustellen, dass eine Geschichte die definierten Kriterien erfüllt, bevor sie akzeptiert wird.

Einige häufig von Teams festgelegte Kriterien sind:

Ohne ein klar definiertes DoD ist es einfach, in einer Situation zu landen, in der viele Dinge auf halbem Weg erledigt sind und nichts wirklich vollständig ist.

Kodierungs- und Formatierungskonventionen definieren und einhalten define-and-adhere-to-coding-and-formatting-conventions

Dinge wie Einzüge und Leerräume erscheinen möglicherweise nicht wichtig, aber korrekt formatierter Code trägt erheblich zur Lesbarkeit und Pflegeleichtigkeit bei. Konventionen sollten im Team abgesprochen und beim Programmieren befolgt werden.

Auf hohe Testabdeckung abzielen aim-for-high-test-coverage

Je größer eine Projektimplementierung, desto mehr Zeit ist auch erforderlich, um sie zu testen. Ohne entsprechende Testabdeckung kann das Test-Team nicht skalieren und die Entwicklerinnen und Entwickler kommen irgendwann vor lauter Bugs nicht mehr hinterher.

Entwickler sollten TDD praktizieren und fehlschlagende Einheitstests vor dem Produktions-Code schreiben, der ihre Anforderungen erfüllt. Die Qualitätssicherung sollte einen automatisierten Satz von Abnahmeprüfungen erstellen, um sicherzustellen, dass das System von einer hohen Ebene aus wie erwartet funktioniert.

Es stehen benutzerdefinierte Frameworks wie Jackalope und Prosper zur Verfügung, um die Nachahmung von JCR-APIs zu vereinfachen, um die Produktivität der Entwickler beim Schreiben von Komponententests sicherzustellen.

Demo bereit halten stay-demo-ready

Das System sollte am Ende jeder Iteration für Demos im Unternehmen zur Verfügung stehen. Indem das System immer bereit für Demos gehalten wird, ist das Team immer nur eine Iteration von Produktionsbereitschaft entfernt und technische Rückstände werden auf ein vertretbares Maß beschränkt.

Kontinuierliche Integrationsumgebung implementieren und verwenden implement-a-continuous-integration-environment-and-use-it

Das Implementieren einer kontinuierlichen Integrationsumgebung ermöglicht das einfache und wiederholte Durchführen von Einheits- und Integrationstests. Außerdem werden so Bereitstellungen vom Entwicklungs-Team entkoppelt, was andere Teile des Teams effizienter und Bereitstellungen stabiler sowie vorhersehbarer macht.

Entwicklungszyklus durch niedrige Erstellungszeiten beschleunigen keep-the-development-cycle-fast-by-keeping-build-times-low

Wenn Einheitstests zu viel Zeit beanspruchen, lassen Entwickler sie aus, wodurch sie ihren Wert verlieren. Wenn es viel Zeit in Anspruch nimmt, den Code zu erstellen und bereitzustellen, werden diese Aufgaben seltener durchgeführt. Indem Sie kurze Erstellungszeiten zur Priorität machen, wird sichergestellt, dass die Zeit, die wir in unsere Testabdeckung und CI-Infrastruktur investiert haben, weiterhin der Produktivität des Teams zugutekommt.

„Sonar“ sowie andere statische Codeanalysewerkzeuge optimieren und ihre Berichte verwerten fine-tune-sonar-and-other-static-code-analysis-tools-and-act-on-their-reports

Code-Analysewerkzeuge haben nur dann einen Wert, wenn ihre Berichte vom Entwickler-Team verwertet werden. Ohne die Optimierung der Analysen, die diese Tools bieten, sind die generierten Empfehlungen nicht relevant und verlieren ihren Wert.

Der Pfadfinderregel folgen follow-the-boy-scout-rule

Pfadfinder haben eine Regel: „Hinterlass es besser, als du es vorgefunden hast.“ Sofern sich alle Mitglieder des Entwickler-Teams an diese Regel halten und eine Verbesserung vornehmen, wenn sie einen Fehler sehen, wird der Code konstant verbessert.

Implementierung von YAGNI-Funktionen vermeiden avoid-implementing-yagni-features

YAGNI (für „You Aren’t Gonna Need It“, zu deutsch: „Du wirst es nicht brauchen“)-Funktionen sind Dinge, die implementiert werden, wenn erwartet wird, dass sie in der Zukunft benötigt werden, momentan aber nicht benötigt werden. Idealerweise sollte der einfachste Code implementiert werden, der heute funktioniert, und anhand konstanter Refaktorierung sichergestellt werden, dass sich die Architektur des Systems mit den Anforderungen und der Zeit weiterentwickelt. Dies ermöglicht eine Konzentration auf das Wesentliche und verhindert das Aufblähen des Codes sowie das Einschleichen von Funktionen.