Kent Beck hat (zusammen mit anderen) vor über 25 Jahren die Art und Weise, wie Software entwickelt wird, revolutioniert. Er ist Mitbegründer von Extreme Programming (XP), Test-Driven Development (TDD) und Erstunterzeichner des Agilen Manifests. Seine beiden Bücher Extreme Programming Explained: Embrace Change (zusammen mit Cynthia Andres) und Test-Driven Development: By Example aus den Jahren 2000 und 2002 sind Meilensteine der Software-Literatur.
Software-Design
Tidy First? Mini-Refactorings für besseres Software-Design heißt nun das neue Buch von Kent Beck, das ich hier vorstellen möchte. Es ist das erste von drei Büchern, die Beck über Software-Design schreiben möchte. Das zentrale Credo für alle drei Bücher lautet: „Softwaredesign ist eine Übung in zwischenmenschlichen Beziehungen.“ Während es in den kommenden Büchern um die Beziehungen zwischen den Entwicklern:innen und dann allen Stakeholdern geht, fokussiert der erste Band auf die „Beziehung des
Programmierers oder der Programmiererin zu sich selbst.“
Im Kern dieser Beziehung steht das Tidying, das Ordnung-Schaffen. Beck untersucht, womit (Teil I: Aufräumereien), wie (Teil II: Managen) und warum (Teil III: Theorie) man Code aufräumen sollte.
Tidyings
Im ersten Teil stellt Beck fünfzehn Tidyings, in der deutsche Ausgabe mit „Aufräumereien“ übersetzt, vor. Hier ist auch der deutsche Untertitel „Mini-Refactorings“ passend. „Aufräumereien sind“, wie Beck schreibt, „eine Untermenge der Refactorings. Sie sind niedliche, knuddelige kleine Refactorings, die niemand wirklich hassen kann.“ Refactorings sind Code-Änderungen, die die Struktur, aber nicht das Verhalten ändern. Sie sind zentraler Bestandteil der agilen Softwareentwicklung. Doch sie bergen auch eine Gefahr: „Das Refactoring hat ernsthaften Schaden genommen, als Menschen begannen, es zu nutzen, um lange Pausen bei der Feature-Entwicklung zu erklären.“ Deshalb bringt Beck Mini-Refactorings ins Spiel. Es sind Refactorings, die man in fünf Minuten, maximal in einer Stunde, erledigen kann.
Alter Wein in neuen Fäßern?
Schaut man sich die 15 Aufräumereien dann im Detail an, ist man wohl möglich enttäuscht. Es sind bekannte und lang etablierte Pattern. Das erste Tidying, Guard Clauses (siehe meine vorherigen Blog-Beitrag), hat Beck in seinem Buch „Smalltalk Best Practice Patterns“ schon 1996 eingeführt. Und auch das zweite Tidying – „Toter Code: Löschen Sie ihn.“ – sollte niemanden vom Hocker reißen. Ist man dann beim letzten Tidying („Redundanten Kommentare entfernen“) angelangt, kann sich eine gewisse Ernüchterung bereit machen. Doch hier sollte man weiterlesen. Es sind nicht die einzelnen Tidyings, die die Stärke des Buchs ausmachen, sondern der Rahmen (das „Managen“ und die „Theorie“), in dem sie eingeordnet werden.
Managen
Beim Managen geht es im Wesentlichen um drei Aspekte:
- Getrenntes Aufräumen: Man kann vor oder nach einer Verhaltensänderung aufräumen, aber man sollte niemals Strukturänderungen mit Verhaltensänderungen vermischen.
- Batchgröße: Es geht um die Frage, wie viele Tidyings man in einem Pull-Request (PR) unterbringen sollte. Grundsätzlich sollten die PR’s klein sein. Das ist übersichtlicher und führt zu weniger Merge-Konflikten. Dem stehen aber die „fixen Kosten, die entstehen, wenn eine einzelne Änderung den Review- und Deployment-Prozesses durchläuft“, entgegen. Um kleinere PR’s zu ermöglichen, muss man diese Kosten reduzieren. Hier schlägt Beck vor, gegebenenfalls auf das Review von Tidyings zu verzichten.
- Vorher, nachher, später, nie: Hier geht es um das Fragezeichen in „Tidy First?“. Häufig wird empfohlen, vor einer Verhaltensänderung die betroffenen Codestellen aufzuräumen. Meistens ist das auch sinnvoll. Aber – und hier wendet sich Beck gegen ein dogmatisches Tidy First – nicht immer. Unter bestimmten Voraussetzungen kann ein Tidy After, Tidy Later oder Tidy Never besser sein.
Orientiert man sich an diesen Grundsätzen, sollte das Tidying zu einen leichtgewichtigen Bestandteil des Entwicklungs-Workflow werden. Die Vision ist, dass jede einzelne Entwicklerin, jeder Entwickler selbständig, ohne (große) Team-Rücksprache, kontinuierlich aufräumt. Zu dieser Vision gehört auch, dass ein Tidying das nächste evoziert. Im Idealfall kommt es zu einer „Lawine“: „eine Aufräumerei führt zu vielen weiteren.“ Und so kann es auch sein, dass Tidyings dann Refactorings, die über einfaches Aufräumen hinausgehen, sichtbar machen. Diese können dann, ohne den Entwicklungsprozess zu blockieren, als Team-Aufgabe angegangen werden.
Theorie
Im letzten Teil geht es ums Geld. Was ist der Wert und was sind die Kosten von Software.
Optionalität
Die naheliegende Antwort auf die erste Frage, den Wert von Software, ist: „Was sie heute tut“. Also „Gehaltsabrechnungen erstellen, Lieferaufträge verschicken, Freunde benachrichtigen.“ Aber Software hat noch einen weiteren Wert: „Die Möglichkeit neuer Dinge, die wir morgen tun können“. Von zwei Systemen, die heute dasselbe tun, ist dasjenige das wertvollere, dass sich leichter erweitern lässt. „Optionen sind die ökonomische Magie von Software.“ Das Problem ist, dass die Struktur von Software (das „Leichter-Erweitern“) viel schwerer zu bewerten ist als das Verhalten. Wenn wir in die Struktur von Software investiert haben, „können wir nicht wirklich sagen, ob wir was getan haben. Der Code lässt sich leichter ändern? Wirklich?“ Auch wenn es hier keine leichte Antwort gibt, geht es Beck um die grundsätzliche Erkenntnis, „dass Strukturänderungen und Verhaltensänderungen zwei Wege sind, mit denen Werte geschaffen werden.“
Constantines Äquivalenz
Die Antwort auf die zweite Frage, den Kosten, lautet:
Kosten(Software) ~= Kopplung.
Beck nennt es Constantines Äquivalenz, benannt nach Larry Constantine, der diese Äquivalenz zusammen mit Edward Yourdon in dem berühmtem Klassiker Structured Design 1975 aufstellte. Die Kosten von Software sind proportional zum Grad der Kopplung.
Die Herleitung dieser Äquivalenz läuft so: Die Kosten von Software setzen sich aus den Kosten der initialen Entwicklung und den Änderung-Kosten zusammen. Die initialen Kosten sind in Vergleich zu den Änderungskosten gering. Also gilt: Kosten(Software) ~= Kosten(Änderung). Die Kosten der Änderung setzen sich wiederum aus den Kosten der kleinen Änderungen und den Kosten der großen Änderungen zusammen. Kleine Änderungen sind häufig, aber billig. Doch irgendwann zeigen sich „Spannungen“. Plötzlich kostet eine Änderung sehr viel. Diese Ausreißer sind nach dem Potenzgesetz verteilt. Sie sind selten, aber in der Summe sind sie teurer als die vielen kleinen Änderungen. Also haben wir: Kosten(Software) ~= Kosten(große Änderungen). Doch wie kommt es zu großen Änderungen? Das liegt daran, dass es sich um „kaskadierende Änderungen“ handelt: „Ändern wir dieses Element, müssen wir jene zwei Elemente ändern, die jeweils das Ändern anderer Elemente erfordern – und so weiter und so fort.“ Und „was sorgt für das Ausbreiten von Änderungen? Kopplung.“ Somit haben wir Constantines Äquivalenz: Kosten(Software) ~= Kopplung.
Kopplung und Kohäsion
Kopplung lässt sich nicht vollständig beseitigen. Hier kommt dann Kohäsion ins Spiel. Elemente innerhalb eines Teils sollten eine möglichst hohe Kopplung besitzen. Die Kopplung zwischen den einzelnen Teilen sollte dagegen möglichst gering sein. Das ist die zentrale Schlussfolgerung von Larry Constantine und Edward Yourdon in Structured Design. Kent Beck bricht das auf ein einfaches Tidying herunter: Gekoppelte Elemente sollte „beieinanderstehen“. Das gilt für Funktionen in einer Datei ebenso wie für Dateien in einem Verzeichnis.
Fazit
Tidy First? ist ein schmales, leicht zu lesendes Buch. Es ist sicher kein wegweisenden Buch wie Extreme Programming Explained. Alles, was sich darin findet, ist – im Prinzip – bekannt. Doch die Zusammenstellung und Fokussierung ist einzigartig. Seine Leistung besteht darin, Tidyings als Vorstufe zu Refactorings zu etablieren. Im Fokus steht dabei Kopplung und Kohäsion. Kopplung soll auf einfache Weise verringert und Kohäsion erhöht werden. Zentral ist dabei ein empirischer Ansatz. Jeder Schritt soll durch „Beobachtung und Erfahrung“ überprüft werden und leitet zum nächsten Schritt über.
Es macht Spaß, Tidy First? zu lesen. Und es macht Lust auf mehr.