// der php hacker

// archiv

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.

Quelle

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
02. Mai 2009
knalli

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 :)


#002
02. Mai 2009
unset

Stimmt, ich hätte auch einfach den Blogpost verlinken können und dazu die drei Punchlines “Comment, comment, comment”, “Refactor early, refactor often” und “Keep it simple, stupid” raushauen können. Oder ich schreibe lieber mehr als die üblichen Phrasen. Bewusst versuche ich solche “Faustregeln” lieber in ein paar Sätzen auszuformulieren, denn: Sie sind einfach, sie sind leicht zu merken. Und sie sind leicht falsch zu verstehen.


#003
03. Mai 2009

Also gerade die Erweiterbarkeit hat überhaupt nicht mit Code und Wartung zu tun sondern ausschließlich mit der Architektur (beispielsweise ist OOP ja gerade darauf hin ausgelegt).
Die Erweiterbarkeit, so man sie denn auf den Code beziehen möchte, ist in diesem Fall ein “Nebenprodukt” des Gesamtprozesses.
Wer die Sache objektorientiert programmiert und gut dokumentiert, wird hier sowieso das Richtige machen, denn idealerweise hält die Vorgehensweise auch Funktionen verhältnismäßig klein und übersichtlich.

Intuitiv – oh je, das hat fast was von Benutzerfreundlichkeit. Im Fall Code ist aber das Intuitive dann zum Teil auch etwas Subjektives.
Und da sind wir auch ganz schnell bei der Frage, die sich viele beispielsweise beim Thema CSS stellen: wie schlank und elegant darf/muss es denn sein? Wo liegt die Grenze zwischen “für mich gut lesbar” und Best Practices?
Ein Thema, dem ich sehr kritisch gegenüber stehe, weil es so subjektiv ist.
Wichtiger ist dann doch “kein Codegewurschtel” – sprich, wer gut programmiert, dessen Code kann man auch gut lesen.


#004
04. Mai 2009

Also, “intuitiv” ist ganz wichtig; ich habe es beruflich sehr oft mit fremden Code zu tun … viel mehr, zu schaffen. Manche Stellen sind ganz okay, bei vielen Code-Stellen kommt aber oft das “was-will-uns-der-Autor-damit-sagen”-Gefühl hoch und man sitzt mitunter Stundenlang an einer ganz trivialen Funktion, die der Autor aber – warum auch immer – auf gut einem dutzend DIN-A4 Seiten untergebracht hat.
Wir hatten letzte Woche dieses Erlebnis, dass wir es geschafft haben, einen Codeblock von 600 Zeilen (erstreckte sich über 5 Dateien mit mehreren Dutzend Funktionen, aufruf anderer Funktionen, die wieder die ersten Funktionen aufriefen usw.) auf gut 36 Zeilen zu kürzen. In einer Datei, in 2 Funktionen, mit einem besseren Ergebnis, was die Geschwindigkeit betrifft.
“Intuitiv” ist ganz wichtig…aus nervlicher-, vor allem aus Finazieller Sicht.


#005
13. Mai 2009
knalli

Hört sich so jetzt super an – vielleicht ist der Code aber jetzt nicht mehr wiederverwandbar und modular aufgebaut wie vorher? *g*


#006
14. Mai 2009

@Anne-Kathrin
>> Wer die Sache objektorientiert programmiert
>> und gut dokumentiert, wird hier sowieso das Richtige machen
Das halte ich aber für eine riskante Aussage. Ich kann auch objektorientiert einen völligen “Müll-Code” hinzauben;-)

// kommentieren

// senden
theme von mir, software von wordpress, grid von 960 grid system. funktioniert in allen browsern, aber der safari bekommt das mit der schrift am schönsten hin.