Frage: Was braucht man um einen Parameter in einem vor einem Jahr ausgelieferten Programm zu ändern?
Antwort: 1 Student, 2 Doktoren und 6 Stunden
Frage: Wie kann man den Ressourcenbedarf abschätzen oder verringern?
Antwort: Code-Qualität!
Code-Qualität ist ein Konzept, dass häufig diskutiert wird, sobald der wunderschöne selbsterklärende, praktisch fehlerfreie Code, sich als weder fehlerfrei noch selbsterklärend erweist. Und wenn sich der verantwortliche Stümper in weiser Voraussicht anderen Herausforderungen zugewandt hat und deshalb nicht mehr zur Verfügung steht.
Hier fehlt doch die Bildunterschrift?
Code-Qualität – Wünsche des Maintainers
Zunächst sei gesagt, dass mir die zu Beginn geschilderte Situation in etwa so widerfuhr. Die Hälfte der Zeit verbrachten wir mit der Suche nach dem Parameter, seiner assoziierten Funktion, sowie den Build-Skripten für das Projekt. Diese waren scheinbar ähnlich wie die Inhalte des Kölner Stadtarchivs über das Projekt gleich verteilt.
Nun ist recht offensichtlich, dass sich unsere Kategorisierung des Codes von der des Code-Autors unterschied. Dies kann durch die unterschiedlichen Ansprüche an den Code erklärt werden: Für Wartungsarbeiten, wünscht sich die wartende Person in der Regel einen einfachen und schnellen Eingriff. Im Idealfall öffnet man die Dokumentation, identifiziert den für das Fehlverhalten verantwortlichen Programmteil, editiert einige Zeilen Code und es treten keine Nebenwirkungen auf.
Die Wartungsperspektive unterscheidet sich also deutlich von der des Code-Autors. Vereinfacht können Sie sich, als Code-Autor, den Wartenden als eine äußerst lese- und schreibfaule Person vorstellen, welche versucht, den Kontakt mit ihrem Code zu minimieren.
Falls Ihnen diese Perspektive fremd erscheint, fragen Sie sich, wie häufig Sie oder die Personen, mit denen Sie arbeiten, sich den Sourcecode einer Bibliothek durchlesen. Meiner Erfahrung nach wird auch die Dokumentation erst verwendet, wenn sich die Bibliothek gegen einen intuitiven Nutzungsversuch sträubte.
Einen besseren Einblick in die Schwierigkeiten kann How to write unmaintainable code, liefern, welches Sie auch auf GitHub finden können.
Wo wir Fehler finden
Die Hälfte unserer Zeit verbrachten wir also mit Suchen, die andere Hälfte mit unerwartetem, unerwünschtem und undokumentiertem Verhalten.
Die unangenehmeren Fälle sind häufig das Resultat von kleineren Fehlern, welche sich tief im Inneren des Codes verbergen und meist indirekt Symptome hervorrufen, welche dann behandelt werden.
Eine solch symptomatische Behandlung ist oft nicht erwünscht, jedoch nicht zu vermeiden. Vor allem, wenn der tatsächliche Fehler in der Hardware, fremden (evtl. proprietären) Bibliotheken oder missverstandenen Feinheiten der Aufgabenstellung oder Implementierung zu finden ist.
Vielleicht haben Sie auch schon eine Person getroffen, welche davon überzeugt war, fehlerfreie Programme zu schreiben. Ich persönlich glaube, dass dies für größere Projekte unmöglich ist, da die Komplexität mit der Größe des Projekts super-linear ansteigt. Das wiederum lässt einen Versuch, dieses vollständig bis ins letzte Bit zu verstehen, ambitioniert erscheinen.
Deshalb rate ich dazu, Fehler zu erwarten und sich auf das Auftreten von Fehlern vorzubereiten.
Das Mittel der Wahl für gute Code-Qualität sind Tests: Sollte es gelingen, den ganzen Code mit Tests abzudecken, sollten wir das Auftreten eines Fehlverhaltens sofort bemerken und im Idealfall auch grob lokalisieren können.
Online gibt es zahlreiche Ressourcen, welche sich mit Testen beschäftigen, zum Beispiel The Ultimate Guide to Software Testing. Ich persönlich würde auch “Growing Object-Oriented Software, Guided by Tests” von Steve Freeman und Nat Pryce, empfehlen, allerdings steht es leider nicht frei zur Verfügung.
Die Augen der Anderen
Zu Beginn des Artikels benannte ich einen Stümper als Verantwortlichen für die geringe Code-Qualität, obwohl besagter Stümper, genau wie ich sein Handwerk durchaus beherrscht. Dass mir seine Arbeit stümperhaft erscheint, kann wohl mit unseren unterschiedlichen Perspektiven auf den Code erklärt werden.
Beschäftigt man sich für Wochen oder Monate mit einem Projekt oder begleitet dieses seit seiner Entstehung, so erlangt man eine Vertrautheit mit dem Projekt, die eine Projekt-fremde Person niemals erlangen könnte. Dies, glaube ich, erschwert es die Leserlichkeit des Codes zu beurteilen. Vereinfacht gesagt, Sie werden ohne Probleme das Salz in Ihrer Küche finden, aber vermutlich nicht in meiner und umgekehrt.
Nachdem es schwierig ist, das Projekt durch die Augen einer Projekt-fremden Person zu betrachten, da man hierfür die impliziten Erwartungen dieser kennen müsste, empfehle ich einen arbeitssparenden Umweg.
Wir bitten einfach eine Projekt-fremde Person unseren Code zu bewerten, also einen Peer Review durchzuführen. Im besten Fall hilft diese dabei, das Projekt in einen allgemein verständlichen Zustand zu versetzen und die Code-Qualität zu erhöhen, im schlimmsten Falle trägt sie eine Mitverantwortung an der Unverständlichkeit.
Zusammenfassung
Nachdem wir nun die Quellen für Code von geringer Qualität festgestellt haben, hier eine vermutlich nicht unbekannte Liste von Ratschlägen für gute Code-Qualität:
- Schreiben Sie ein Übersichts- oder Einführungsdokument.
- Dokumentieren Sie Ihren Code, sodass er im Falle einer Wartung leichter durchsucht und verstanden werden kann.
- Schreiben Sie Tests um sicherzustellen, dass Ihr Code wie gewünscht funktioniert.
- Schreiben Sie Tests, um im Falle einer Wartung unerwünschte Nebenwirkungen zu finden.
- Lassen Sie Ihren Code von einer technisch kompetenten Person auf Verständlichkeit und Lesbarkeit prüfen.
- Fügen Sie während Wartungsarbeiten Fehler in den Code von Personen ein, welche diese Anweisungen ignorieren, um diese damit über deren Vorteile aufzuklären.
Sollten Sie Probleme haben die Vorteile dieser oder andere Empfehlungen zur Verbesserung der Code Qualität zu verdeutlichen, so empfehle ich eine sechsstündige Wartung unleserlichen Codes.
