Was ist “wartbarer Code”?
Geschrieben am 02. Mai 2009 von Cem Derin
Auf Limespace wird sich die Frage gestellt, was eigentlich wartbarer Code ist. In etwas eigenwilliger Grammatik wird vermutet, dass Code dann wartbar ist, wenn er drei Kriterien entspricht:
- Debugbar – Wenn es fehler gibt, muss durch ausreichend Kommentare und gute Struktur die Möglichkeit bestehen diese schnell zu beseitigen / zu finden.
- Erweiterbar – Eine Anpassung an der Anwendung sollte nicht das ganze “Gerüst” zum Einsturz bringen
- Intuitiv – Auch ein dritter sollte schnell verstehen was der vorliegende Code macht / und warum.
Ich sehe das allerdings ein bisschen anders. Für mich ist Code, die Wartbarkeit von Code gar keine direkte Eigenschaft, sondern das Resultat aus einer ganzen Reihe von anderen Eigenschaften. Auch die drei oben beschriebenen Eigenschaften rühren aus anderen positiven Merkmalen.
“Debugbar” ist in erst einmal jeder Code. Der eine besser, der andere schlechter. Vor allem aber, wenn man mit einem echten Debugger an die Sache herangeht, kann man sich sogar durch das gröbste Spaghettigericht prügeln. Im Grunde steht aber auch schon im Eingangspost dazu: Code sollte verständlich sein. Verständlichkeit erreich man – auch erwähnt – durch ordentliche Kommentare. Darüber hinaus sollten gewisse Richtlinien herrschen, was Benamung angeht: Verständliche und einheitliche Klassen- und Methodennamen, Variablennamen- und Reihenfolgen und eine konsistente Struktur tun ihr übriges.
Erweiterbarkeit hat meiner Meinung nach hingegen nichts mit Wartbarkeit zu tun. “Warten” heißt in diesem Zusammenhang ja auch eigentlich nichts anderes, als den Code instand zu halten. Evtl. Sicherheitslücken auszubügeln und Bugs auszumerzen. Feature- oder Scope-Änderungen fallen da nicht mehr drunter. Sollte es sich allerdings nicht um Wegwerfsoftware handeln, sollte man sich als Entwickler diese Hintertür natürlich nicht verabauen 
Die Intuitivität von Code ist ja eigentlich schon durch den ersten Absatz gegeben. Trotzdem hier noch ein paar Worte dazu, auch wenn es eigentlich ein leichtes Abschweifen ist. Irgendwann kommt man an die Stelle, an der die (vermeintlich) bessere Lösung die weniger gut lesbare beziehungsweise verständliche ist. Man baut also hier und dort komplizierte, schwer zu verstehende und sehr wirre Konstrukte, die nach kürzester Zeit selbst dem Author wie Hexenwerk vorkommen. Fragt man in solchen Situationen, warum das gemacht wurde, murmeln alle was von Arbeitsspeicher, Performance oder Stil. Und hier kommen wir zu dem Punkt, an dem die Kosten dieser Code-Stelle in die Höhe schnellen: Wenn sie nicht mehr funktioniert. Dann wird nämlich kaum jemand noch mit Gewissheit sagen können, wie man dieses Stück Code wieder repariert. Und wenn sich ein Entwickler ein paar Stunden Gedanken dazu machen muss, war dies eine – sogar finanziell – verdammt teure Entscheidung.
#001
Vielleicht vor allen drei Punkten ein “leicht…” hinzufügen
Die Gründe betreffen ja wohl die eigentliche Architektur und die Struktur der Anwendung. Prinzipiell ist jeder Code irgendwie “wartbar”.. aber mit welchen Aufwand? Irgendwann sagt auch der beste Programmierer in der Rolle des Wartungsdienstes “Nein, das funktioniert nicht (in 5 Jahren).” 
Wenn ein Code gewartet werden muss – aus welchen Gründen auch immer – so ist natürlich, und das ist jedem klar, ein “Spaghetticode” nicht optimal. Ob ich nämlich das ganze Programm in den Debugger einprügele oder nur gezielte Breakpoints setze, liegt am Code selber (weil ich schnell die Architektur und Funktionsweise erkenne). Das die Holzhammermethode nur zufällig schnell zum Ergebnis führen kann, ist ja wohl klar.
Erweiterbarkeit fällt natürlich streng genommen nicht unter Wartbarkeit, wohl aber o.g. Fixes. Außerdem die Sachen, um einen Arbeitsverlauf zu gewährleisten, der sich ggf. durch andere Umgebungen oder Eigenschaften verändert hat. Und dies kann dann wiederum durchaus die Erweiterbarkeit (bzw. deren Eigenschaften in einem Softwareprodukt) berühren.
Zu Intuitivität: Man kann es auch abkürzen: KISS