Wo wir stehengeblieben sind

Vor ein paar Wochen haben wir darüber geschrieben, wie unser Frontend dieselben Entwurfsmuster, die ein Java-Entwickler wiedererkennen würde, aus Tabellen und Composables gewinnt, fast ohne eine einzige Klasse. Das Gespräch darüber endete nicht mit der Veröffentlichung. Innerhalb des Teams ging es weiter, weil dieser Text etwas Größeres berührte als irgendein einzelnes Muster: Wir hatten für jede dieser Formen einen Namen, und alle wussten bereits, was dieser Name bedeutete, bevor das Gespräch überhaupt begann.

Diese Gewohnheit verdient eine eigene Erklärung, unabhängig von jeglichem konkreten Muster. Vor einiger Zeit hat jemand entschieden, dass es sich lohne, eine Form zu benennen und aufzuschreiben, und das Team hat dies seitdem beibehalten.

Was ein Tutorial vermittelt

Komponentenbibliotheken sind eine echte Erleichterung. Man bindet eine ein, und ein funktionierender Datumswähler oder ein Dropdown kommt bereits fertig gebaut an, erprobt durch weit mehr Einsatz, als ein einzelnes Team ihm je geben könnte. Ein Code-Schnipsel spart die zehn Minuten, die es kostet, sich an die genaue Syntax für etwas zu erinnern, das selten genug vorkommt, um es zu vergessen. Ein Tutorial ist oft der schnellste Weg, eine Technik wirklich zu lernen, weil es die Überlegung dahinter durchgeht.

All dies ist nützlich und richtet sich an eine einzelne Person, die in einer Sitzung eine bestimmte Technik erlernt. Ein Team stellt sich jedoch eine zweite Frage: Worauf sollte sich eine Gruppe von Personen, von denen die meisten den ursprünglichen Code nicht geschrieben haben, stützen, wenn das nächste Mal eine ähnliche Entscheidung ansteht? Die Antwort darauf liegt beim Team.

Die tatsächliche Praxis

So läuft es bei uns ungefähr ab. Jemand bemerkt, dass dieselbe Form von Problem zum zweiten oder dritten Mal auftaucht, meist beim Review eines Pull Requests, der es ein bisschen anders löst als das letzte Mal. Diese Person gibt der Form einen Namen, direkt im Gespräch, im Review-Kommentar selbst. Übersteht der Name noch ein paar weitere Male den Gebrauch, wird er aufgeschrieben: was die Form ist, wann sie zutrifft, und ein kurzes Beispiel, das schon im Code steckt.

Die schriftliche Liste ist bewusst kurz gehalten und umfasst die vom Team verwendeten Muster. Sie dient dazu, dass eine Entwurfsentscheidung in einem einzigen Satz gefasst werden kann. Wenn jemand in einer Überprüfung schreibt: „Machen Sie daraus eine Registry“, wissen alle, die den Kommentar lesen, bereits, um welches Muster es sich handelt, ganz ohne Diagramm und ohne Besprechung.

Ein weiterer Bereich, in dem sich diese Vorgehensweise bezahlt macht, ist die erste Woche eines neuen Entwicklers. Beim Durchlesen der Liste lernen diese die wenigen Muster kennen, die in der Codebasis verwendet werden, in den eigenen Worten des Teams. Ein Styleguide regelt, wie eine Zeile formatiert werden soll. Diese Liste behandelt hingegen, wie man eine Entscheidung durchdenkt, bevor die Zeile geschrieben wird.

Warum wir uns die Mühe machen

Die Benennung einer Struktur erfordert einen Austausch, und das Aufschreiben kostet Zeit, die immer wieder aufgewendet werden muss, wenn sich die Codebasis ändert. Der Nutzen ist genau der, für den das Buch, das wir letztes Mal erwähnt haben, direkt plädiert: Ein einheitlicher Name ermöglicht es, eine gute Entscheidung schnell zu treffen, und er macht eine schlechte Entscheidung sichtbar, solange sie noch ein Satz ist und bevor sie zu einem Pull-Request wird, der rückgängig gemacht werden muss.

Die Benachrichtigungs-Engine, die wir letztes Mal beschrieben haben, immer noch bei rund vierzig Zeilen nach jeder Erweiterung, hat genau aus diesem Grund gehalten. Die Form hatte einen Namen, bevor die vierte oder fünfte Benachrichtigung eintraf. Eine weitere hinzuzufügen erforderte danach keine Abwägung.

Der menschliche Teil einer architektonischen Entscheidung

Dies ist in erster Linie eine Vorgehensweise, mit der sich eine Gruppe von Menschen auf Dinge einigt, und erst in zweiter Linie eine Programmierpraxis. Ein Team trifft seine Entscheidungen Schritt für Schritt, bei jeder Überprüfung und in jedem Gespräch, und die Liste hält diese Entscheidungen fest, sobald sie getroffen wurden. Jede Entscheidung wird nur einmal getroffen.

Das gilt, ob die Sprache Java oder JavaScript heißt, und ob das Team fünf Leute hat oder fünfzig. Die Form im Code folgt der Form, wie die Menschen, die ihn bauen, miteinander darüber sprechen, und genau diesem zweiten Teil widmen wir die bewussteste Aufmerksamkeit.

Zusammenfassung

Komponentenbibliotheken, Code-Schnipsel und Tutorials vermitteln jeweils einer einzelnen Person eine einzelne Technik in einer Sitzung. Ein gemeinsames Vokabular für eine Entwurfsform lebt zwischen den Menschen in einem Team und wird von allen gleichzeitig verwendet.
Die Praxis, konkret: ein Name, vorgeschlagen in einem Review-Kommentar, erprobt an ein paar weiteren echten Fällen, dann aufgeschrieben mit dem, was er ist, wann er zutrifft, und einem kurzen Beispiel, das schon im Code steckt.
Die schriftliche Liste bleibt absichtlich kurz. Sie existiert, damit eine Entwurfsentscheidung ein Satz sein kann.
Ein neuer Entwickler liest die Liste in seiner ersten Woche. Er lernt die Formen, die der Code tatsächlich verwendet, in den eigenen Worten des Teams, ohne sie aus altem Code zusammenzusuchen.
Der Gewinn ist derselbe, für den das Buch hinter unserem letzten Text argumentiert: ein gemeinsamer Name macht eine gute Entscheidung schnell und eine schlechte sichtbar, solange sie noch ein Satz ist.
Das ist eine organisatorische Gewohnheit, bevor es eine Code-Gewohnheit ist. Ein Team einigt sich auf Dinge, ein Gespräch nach dem anderen, und die Liste ist der Ort, an dem diese Einigungen aufbewahrt werden.