Service Architektur: Qualitätsmerkmale
Bei den Vorbereitungen für den ersten Artikel für eine Reihe über Service Architektur Pattern kam mir die Frage, was zeichnet für mich ein guter Code aus?
- Service Architektur: Qualitätsmerkmale
Bei der Beantwortung der Frage wie guter Code aussieht und in wie der Code auch das Team beeinflusst, stieß ich auf John Romero und Mat Ryer.
John Romero (Mitgründer von id Software), definiert in seinem Vortrag auf der code.talks 2019 einige Prinzipien, die er bei der Entwicklung von Computerspielen wie Doom aufstellte. Seine Aussagen stehen im Kontext eines hohen Zeitdrucks und keiner Möglichkeit nachträglich Fehler zu beheben.
Mat Ryer ist in der Go Welt für seinen viel diskutierten Blogpost “how I write http services after seven years” bekannt. Eine überarbeitete Version ist auf seiner Firmenwebseite zu finden.
Die Wartbarkeit und Übersichtlichkeit eines Projektes sind meiner Meinung nach die wichtigsten Eigenschaften eines Konzepts. Gerne wird ein MVP/Prototyp gebaut, der zum Testen des Business Case in den Einsatz geht. Einmal im Betrieb wird hier und da schnell eine Funktionalität erweitert und schon ist der Prototyp das Produkt.
Ein Kompromiss liefern hier Frameworks. Oft geben diese eine Struktur vor, Teammitglieder sind mit dieser zumeist vertraut und es existiert eine gute Dokumentation. In der Entwicklung kann sich dadurch auf den perfekten Code konzentriert werden.
Es wird abstrahiert, verschachtelt, ausgelagert und auf keinen Fall doppelter Code geschrieben. Dabei werden externe Module für einfachste Funktionalitäten hinzugezogen, die mit ihren eigenen Pattern und Dokumentationen eine weitere Abhängigkeit und Komplexität mitbringen. Dafür kann ein externes Modul besonders zu Beginn des Projektes viel Geschwindigkeit in die Entwicklung bringen.
Der Code muss einen leichten Einstieg ermöglichen, damit in stressigen Phasen kurzzeitig Hilfe aus anderen Teams dazu geholt werden kann und neue Mitarbeiter früher effektiv mitarbeiten. Ältere Codestellen sind zudem leichter zu warten, da sich schneller in den Code hineinversetzt werden kann.
Der Code muss langweilig sein, damit jedes Teammitglied ihn versteht und Fehler vermieden werden. Das resultiert oft in mehr Code oder Funktionen, aber macht ihn übersichtlicher, da jemand zweites weniger interpretieren muss, was für einen kreativen Erguss zu diesem Code geführt hat.
Oft entsteht Komplexität durch das Abbilden mehrerer Anwendungsfälle um die Funktion noch einmal wieder zu verwenden. Funktionen werden zur Black Box und das Ergebnis ist oft nicht nachvollziehbar.
Das Zerteilen der Funktionen in kleinere Funktionen, benannt nach ihrer Tätigkeit, erspart die Dokumentation. Je nach Anwendungsfall können Funktionen in kleinere Funktionen aufgeteilt werden. Eine Funktion ruft die kleinen Funktionen in einer Art Komposition in der richtigen Reihenfolge auf. Für Sonderfälle kann eine eigene Komposition erstellt werden, in der gezielt Funktionen ausgetauscht oder weggelassen werden. Besonders bei funktionalen Programmiersprachen können Funktionen leicht verkettet werden und die Ergebnisse weitergereicht werden.
Um eine produktive Code Review zu ermöglichen, sollte hier nicht die kreativste, beste Umsetzung erwartet werden, sondern Code der genau den geforderten funktionellen Umfang bereitstellt. Ist dieser gut nachvollziehbar, befolgt die Struktur des Architektur Patterns und liefert das gewünschte Ergebnis, ist dies ausreichend.
Die Suche nach der perfektesten Lösung durch den Prüfer führt eher zu vielen Feedback Schleifen und Kosten. Frustriert sind am Ende Kunde, Programmierer und Prüfer. Prüfer neigen gerne dazu ihre kreative Lösung zu bevorzugen und der Programmierer tippt dies schon fast wie beim Diktat mit.
Zum Abschluss eine kleine Bitte: Vermeidet Abkürzungen, eigene Wortschöpfungen oder ähnliches. Bei einer Projektübernahme oder Wartung von fremden Code möchte niemand parallel in einem Wörterbuch nachschlagen oder sich unsicher sein was für ein Objekt dort genutzt wird. Gibt es zum Beispiel zwei Typen von Verträgen, schreibt den Type mit in die Benennung.
Zusammengefasst finde ich ähnlich wie John Romero und Mat Ryer, dass Code langweilig und einfach gestrickt sein muss. Das heißt nicht, dass man auf neue Sprachfeatures verzichten muss, aber es ist öfter übersichtlicher, wenn etwas über mehrere Zeilen gestreckt ist. Auch Lücken mit Kommentaren, die den nächsten Block zusammenfassen, können einen schnellen Einstieg ermöglichen. Und ja, der Code ist danach unsexy, altbacken und viel zu lang. Aber wenn ihr in 1-2 Jahren etwas ändern müsst werdet ihr euch selbst danken.