Code-Reviews sind für mich ein täglicher Bestandteil der Software-Entwicklung. Mein Haupt-Augenmerk richte ich in meinen Reviews darauf, ob die eingereichten Änderungen die bestehenden Strukturen des Systems berücksichtigen. Beim Nachdenken darüber, warum mir das Einhalten von Strukturen so wichtig ist, kam ich auf den Gedanken, dass Software-Systeme ein Eigenleben entwickeln. Davon handelt dieser Artikel…
Im Laufe der Jahre bin ich in viele Software-Projekte eingestiegen. Manchmal konnte ich die Architektur und das Design eines neuen Systems auf der grünen Wiese frei entwerfen. Andere Male stand ich vor einem bestehenden System, das ich erst begreifen musste.
Wenn ich mich in ein bestehendes System einarbeite, versuche ich nicht nur die fachlichen Anforderungen und technischen Zusammenhänge zu verstehen. Sondern ich möchte auch herausfinden, wie in dem System bestimmte Probleme gelöst worden sind. Also: Welche Muster und Idiome haben meine Vorgänger verwendet, um das System zu strukturieren?
Immer wieder bin ich dann froh, wenn ich Strukturen vorfinde, die ich persönlich auch gewählt hätte. Aber ebenso oft finde ich Strukturen, die ich in dieser Form nicht entwickelt hätte. Da ist die Versuchung natürlich groß, von den bestehenden Mustern abzuweichen und meinen neuen Code nach meinen eigenen Vorstellungen zu schreiben.
Software-Systeme mit Eigenleben
Je mehr Systeme ich gesehen habe, desto mehr habe ich aber begriffen, dass Software-Systeme ein Eigenleben führen, das es zu respektieren gilt. Und dazu gehört, sich an die bestehenden Strukturen zu halten. Ein großer technischer Erfolgsfaktor für das langfristige (Über-)Leben eines Systems besteht darin, möglichst konsistent und variantenarm entwickelt worden zu sein.
Neue Projekte werden oft mit einer großen Mannschaft begonnen, die schnell viel Code erstellen. Jahre später ist das System noch immer erfolgreich im Einsatz, aber aus der großen Mannschaft ist ein kleines Team geworden, das in erster Linie die Aufgabe hat, kleine Änderungen durchzuführen und Fehler zu beheben – das System also am Leben zu behalten.
Auch ein großes System muss also durch ein kleines Team beherrschbar sein. Wenn man überall im System die gleichen Strukturen und Muster vorfindet, ist es viel leichter, sie zu verstehen und anzupassen. Wenn hingegen früh im Projekt jeder Entwickler nach eigenem Geschmack seine Lieblingsansätze umgesetzt hatte, müssen spätere Entwickler immer wieder neu begreifen, wie einzelne Teile des Systems funktionieren.
Nicht, dass es grundsätzlich verboten sein soll, Strukturen zu verändern. Dann aber bitte abgestimmt im ganzen Team und als Teil einer Strategie, die neuen Strukturen überall einzuführen. Inkonsistente Änderungen an einem Software-System lassen sich begreifen als Verletzungen an einem Wesen. Hier ein kleiner Schnitt, da ein blauer Fleck. Jede einzelne Wunde ist nicht schlimm, aber irgendwann bricht das Wesen wegen zu vieler Verletzungen zusammen.
Das System war schon vor mir da und es wird immer noch da sein, wenn ich gegangen bin.
Einige Jahre nach dem Start eines neuen Projekts tritt oft der Zustand ein, dass im Entwicklerteam kein Entwickler der ersten Generation mehr dabei ist. Alle, die die grundlegenden Entscheidungen getroffen haben, sind gegangen. Eventuell sind diese Entwickler niemandem im aktuellen Team mehr bekannt. Und es kann gut sein, dass irgendwann in der Zukunft auch niemand vom aktuellen Team mehr an dem System arbeitet wird.
Die Entwickler im Team kennen das System mehr oder weniger gut. Strukturänderungen werden dann meistens auch deswegen unterlassen, weil es schwer abzuschätzen ist, wie sich das System daraufhin verhält. Lieber bleibt man bei den bestehenden Ansätzen, als seine eigenen Vorlieben umzusetzen.
So kann es vorkommen, dass ein System weiterentwickelt wird mit Konzepten und Ansätzen, die niemand im aktuellen Team so von sich aus ausgesucht hätte. Und Fragen nach dem Wesen des Systems können nur noch tautologisch beantwortet werden: „Es ist, wie es ist, weil es ist, wie es ist.“
Betrachtet man das mit etwas mentalem Abstand, dann wirkt es, als hätte das System ein eigenes Leben entwickelt. Und nicht mehr formen die Entwickler das System, sondern das System formt die Entwickler.