This posting about means of communication, accuracy, and aesthetics, appears in german language only due to german language references. International readers, I apologize.
Kommunikationsmittel
Die Sprache, die Schrift, eine technische Zeichnung oder ein Blatt Noten sind »Kommunikationsmittel[…], mit deren Hilfe sich Menschen untereinander verständigen können.«. Ein Architekt vermittelt mit einer Zeichnung anderen, wie das geplante Gebäude aussehen soll, während ein Komponist durch Noten ausdrückt, welches Musikstück sich in seiner Vorstellung entwickelt hat. Damit das Ganze funktioniert, bedarf es einer Konvention – beide müssen “die gleiche Sprache” sprechen.
Interpretationsspielräume in der Kommunikation
Trotz der Konvention gibt es Interpretationsspielräume durch Unschärfen im Kommunikationsmedium. Ein Notenblatt beispielsweise kann weder Tonhöhen noch Rhythmus beliebig fein auflösen. Kommunikation enthält außerdem auch unbewusste Komponenten, die vom Empfänger in seiner Vorstellung in einen entsprechenden Kontext gesetzt werden. Speziell in der schriftlichen Kommunikation kann man zudem gelegentlich feststellen, dass der eine sich präziser artikulieren kann und dabei auch Wert auf ästhetische Gesichtspunkte legt, während der andere wesentlich pragmatischer zu Werke geht. Wer ein Bild malt wird bezüglich der Ästhetik andere Maßstäbe anlegen als jemand, der eine Einkaufsliste verfasst.
Was aber hat das mit agiler Softwareentwicklung zu tun?!?
Code ist ein Kommunikationsmittel
Wie eine technische Zeichnung ist ein Stück Code in der Softwareentwicklung auch die Repräsentation der Gedanken desjenigen, der ein bestimmtes Problem lösen möchte. Mit dem Code, den er schreibt, teilt er nicht nur der Maschine, sondern auch seiner Nachwelt mit, was er dabei erreichen wollte – der Code ist also ein Kommunikationsmittel. Die Wahrscheinlichkeit, dass später entweder der Autor selbst oder ein anderer Fehler beheben, Verbesserungen oder gar neue Funktionalität hinzufügen möchte, ist groß. Sofern der Code bestimmten Konventionen folgt, präzise formuliert und gut strukturiert ist, wird es in einem halben Jahr deutlich einfacher sein, die dann anstehenden Änderungen vorzunehmen.
Wer agile Softwareentwicklung als Profession betreibt wird vielleicht sogar auf testgetriebene Entwicklung setzen, in der die Tests zum Ausdruck bringen, welches Bild der Programmierer beim Schreiben des Codes im Kopf hatte.
Der Softwarearchäologe
Boris Gloger hat vorgestern in seinem Posting Agile Architektur ist änderbar! das Problem beschrieben und ein paar nette Metaphern genutzt. Das Verstehen und effiziente Ändern von Code, den man nicht selbst geschrieben hat, ist für alle Mitglieder eines ScrumTeams ein wichtiger Baustein zum Erfolg.
Boris schreibt:
Lesbarkeit: Der Code sollte so strukturiert und geschrieben sein, dass er leicht verständlich und lesbar ist.
Eigentlich sollte das eine Selbstverständlichkeit sein. Allerdings erfordert das Disziplin. Es ist einfach, Code zu schreiben, der etwas Nützliches tut. Es ist aber aufwändiger ihn so zu schreiben, dass die Gedankengänge auch später noch nachvollziehbar sind – sei es für den Autoren selbst oder für andere. Und nicht zuletzt spart lesbarer Code, der in »Usable Software« mündet, eine Menge Dokumentationsarbeit ein.
Doch halt – was ist mit Kommentaren? Boris schreibt weiter:
Inline-Dokumentation der Entscheidungen: Es sollte im Code erklärt sein, warum gewisse Entscheidungen so getroffen wurden, wie sie getroffen wurden. Der Code selbst ist ja die Dokumentation dessen, was der Code macht. Nur wieso man die Dinge so angegangen ist, wie sie vorliegen, wäre wichtig zu wissen.
Kommentare sollten nur dort zum Einsatz kommen, wo der Code nicht mehr selbsterklärend geschrieben werden kann. Beispielsweise weil man um eine Unzulänglichkeit des Betriebssystemes (»Was macht er denn da?!?«) herumkommen musste.
Kommentare wie
// Traversing the list
for ( int i = 0; i < lst.size(); i++ )
oder
// Checking whether we can open the file
if ( !f.open() )
sollten gelöscht, dafür die Bezeichner etwas sprechender gewählt werden.
Vor ein paar Tagen habe ich eine Codestelle geändert. Gestern bemerkte ich, dass ich vergessen hatte, den darüberstehenden Kommentar zu ändern. Den Bug habe ich gefixt. Indem ich den Code so umgeschrieben habe, dass der Kommentar überflüssig wurde.
Interlude
Goke hält mit ausgestreckten Armen ein iPad so vor sich, dass er die Noten gut lesen kann. Mit spitzen Lippen pfeift er die Melodie. Nach wenigen Sekunden stimmt Peek mit ein.
Schlussfolgerung
Jedes Mitglied eines ScrumTeams, das vom Erfolgsfaktor der kollektiven Codeverantwortlichkeit in der agilen Softwareentwicklung überzeugt ist, wird darauf drängen, dass der Code als Kommunikationsmittel lesbar geschrieben wird. Jeder kann damit aus dem Stand gleich morgen anfangen. Wichtig ist nämlich nicht das Wollen, sondern das Tun in kleinen Schritten.
Wenn sich später noch die Lektüre von Büchern wie Agile Developer Skills (ISBN 3868020608) von Christoph Mathis und Andreas Wintersteiger oder Clean Code (ISBN 3826655486) von Robert C. Martin anschließt - umso besser.
