Ich erinnere mich noch daran, wie vor Jahren ein Senior-Entwickler zu mir sagte:
Ich finde, das Spannende an C ist, dass man drei Entwicklern ein kurzes Programm zeigt und fragt, was es tut, und drei unterschiedliche Erklärungen bekommt.
Martin Fowler, Kent Beck et. al schrieben in ihrem Refactoring im Jahr 1999:
Jeder kann Code schreiben, den ein Computer versteht. Gute Programmierer schreiben Code, den Menschen verstehen.
Nun, manchmal habe ich das Gefühl, dass es zu wenige gute Programmierer gibt, denn ich ertappe mich sehr oft dabei, Legacy-Code anzuschauen und dabei zumindest nicht mit ausreichender Sicherheit sagen zu können, was dieser Code tut.
Ohne Zweifel
Ich persönlich finde Code schon problematisch, wenn es ein gewisses Maß an Zweifel darüber gibt, was der Code tut und warum er überhaupt existiert. Für mich sind solche Unsicherheiten und die daraus resultierenden Diskussionen ein sicheres Anzeichen für schlechten Code. Das mag kleinlich wirken, aber die jahrelange Erfahrung hat mich gelehrt, dass es durchaus sinnvoll ist, dies so strikt zu sehen.
Eine der wichtigsten Lektionen, die gute Entwickler lernen müssen, ist: wenn man zugibt, dass vorhandener Code schwer zu verstehen ist, dann macht einen das nicht zu einem schlechten Entwickler. Ganz im Gegenteil.
Das Wort Code hat verschiedene Bedeutungen. Soweit ich recherchieren konnte, stammt es vom lateinischen codex ab, das im Prinzip ein Stück Holz bezeichnet, auf dem man schreiben kann. Später hat sich im Altfranzösischen die Bedeutung zu System of Law weiterentwickelt. Nun, ich denke wir sind uns alle einig, dass ein System Of Law schon etwas ist, das niemand wirklich versteht.
Eine andere Wortbedeutung von Code ist Chiffre, eine Nachricht, die verschlüsselt wurde, um ihre ursprüngliche Bedeutung zu verschleiern. In neuester Zeit meint Code auch "Instruktionen für einen Computer".
Code ist das falsche Wort. Ein Computerprogramm soll nicht kryptisch, schwer zu lesen, verschleiert oder sogar mystisch sein. Wir schreiben nicht Code für Computer, sondern Programme für Menschen. Versuchen Sie einmal, Code zu verstehen, den Sie vor drei Jahren geschrieben haben, falls Sie mir in der Argumentation noch nicht folgen wollen.
Bevor jeder agil wurde, oder dies zumindest behauptet hat, hat man umfangreiche Spezifikationen geschrieben, und versucht, danach funktionierende Software zu programmieren. Dabei war schon immer eines der ungelösten Probleme, dass niemand so wirklich sagen konnte, ob die Software denn nun auch tatsächlich alle Anforderungen umsetzt – oder gar, überhaupt irgendwelche der genannten Anforderungen umsetzt.
Ausführbare Spezifikationen
Einige Fachleute, mich eingeschlossen, sind der Ansicht, dass automatisierte Tests eine ausführbare Spezifikation sein sollten. Die agilen Methoden lehren uns ohnehin, dass es nicht sinnvoll ist, big design up front in Form von umfangreichen Dokumenten zu machen. Warum sollten wir dann nicht die Spezifikationen in kleinen Schritten aufschreiben?
Man kann das tun, indem man zuerst einen fehlschlagenden automatisierten Test
schreibt, und dann darauf hinarbeitet, dass der Test fehlerfrei durchläuft.
Ein anderer Ansatz, zugegebenermaßen deutlich weniger
ausgefeilt, ist, einige Zeilen Programmcode zu schreiben und dann im Browser F5
zu drücken,
um genau diesen Code auszuführen.
Ohne einen automatisierten Test wird dabei allerdings die Spezifikation niemals aufgeschrieben, sondern existiert nur vorübergehend im Kopf eines Entwicklers. Mit der Zeit geht dieses Wissen verloren, und nach ein paar Wochen beginnen sich Zweifel darüber, was ein Programm tut - oder was es tun sollte - auszubreiten. Und diese Zweifel breiten sich wie ein Virus über die ganze Organisation aus.
Ein Computerprogramm so aufzuschreiben, dass es für Menschen lesbar ist, und automatisierte Tests als ausführbare Spezifikation dessen, was ein Programm tut (oder nicht tut) zu benutzen, erspart es einem, umfangreiche Anforderungsdokumente zu schreiben. Aber wenn man sich das Papier dafür spart, aber auf der anderen Seite unlesbaren Code schreibt, dann hat man am Ende doch wieder nur ein weiteres Legacy-System geschaffen, das niemand versteht.
Ich werde diese Gedanken im Herbst in meiner Präsentation Domain-Specific Languages in PHP weiterführen. Bis dahin wäre es toll, wenn wir damit aufhören würden, Computerprogramme als Code zu bezeichnen.