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?

Teil der Serie
  1. 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.

No prototypes. Just make the game. Polish as you go. Don't depend on polish happening later. Always mantain constantly shippable code.
John Romero

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.

The code should be boring and obvious because then it's more maintainable. It has better glance ability and more people can use it.
Mat Ryer

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.

As programmer we want to be creative all time and we want to find cool creative ways of doing everything but actually I don't think we need to do that in our code.
Mat Ryer

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.

Keep your code absolutely simple. Keep looking at your functions and figure out how you can simplify further.
John Romero

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.

Write your code for this game only - not for a future game. You're going to be writing new code later because you'll be smarter.
John Romero

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.

Programming is a creative art form based in logic. Every programmer is different and will code differently. It's the output that matters.
John Romero

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.

Stand vom 12.08.2020