"...das hat schon mal funktioniert!" - Wie refactoring trotz Code & Teams im ständigen Fluss langfristig gelingen kann.
(inspiriert durch Robert C. Martin)
Wir finden diese 5 Stichwörter sehr nützlich, weil sie ziemlich gut in den Sprint-Prozess eingegliedert werden können.
Organisation ist nicht nur im Code wichtig, sondern auch im Team. Source Code wird ständig neu organisiert, das ist der Kern von refactoring. Im Team sollen die Regeln dann von allen Mitgliedern abgestimmt und nach Bedarf systematisch (z.B. in der Retro) angepasst werden.
Wer nach Domain Model entwicklen will, braucht dafür eine Domain-bezogene Sprache. Die Dokumentation der Architektur zusammen mit den einheitlichen Begriffen im Glossar gehören dazu.
Für viele ist das eine Sache der Perspektive. Aber genauso wie im Code unnötige Stellen und Kommentare verschwinden sollen, gibt es für Architektur und Dokumentation einen Gärtner (s. arc42), der dafür sorgt, dass durch das ganze Unkraut die Bausteine sichtbar bleiben.
Wieder unser Lieblingsthema: Arbeiten im Team bedeutet, dass alle eine ähnliche Sprache sprechen. Ob das in einem Domain Model ausgedrückt wird, durch die Formatierung des Codes oder durch das Einhalten der Definition of Done - all das trägt zu einem erfolgreichen refactoring bei.
Für uns vielleicht der wichtigste Teil der Regeln. Jeder sollte bereit sein, selbständig zur Verbesserung der Qualität, Arbeit oder des Produkts beizutragen. Dazu gehört natürlich auch die Teamdisziplin, die man in Sprint Retrospektive diskutieren kann.
(von Noam Nisan und Shimon Schocken)
Warum spielt es eine Rolle, ob eine Variable in Java als int oder Integer deklariert wird? Warum macht die Art und Weise wie eine Datenstruktur aufgebaut ist einen Unterschied in der Laufzeit-Performance? Wer sich solche Fragen noch nicht gestellt hat, ist mit diesem wunderbaren Projekt an der richtigen Stelle.