Wartbarkeit von Programmen

Zur Zeit arbeite ich mich mal wieder in ein neues Projekt ein. Unter den Anfoderungsdokumenten fiel mir eins auf über nichtfachliche Anforderungen. Ein Punkt, der dort aufgeführt ist, ist die Wartbarkeit der zu erstellenden Software. Das genannte Kriterium ist, daß sich jemand innerhalb einer Woche so weit in den Programmcode einarbeiten können soll, daß er in der Lage ist, Änderungen vorzunehmen. Was kann das bedeuten außer nicht furchtbar unstrukturierten Code zu schreiben in einer kryptischen und nicht konsequent durchgehaltenen Architektur?

Aufteilung in autonome Komponenten

Zuerst einmal stellt sich die Frage, was der neue Mitarbeiter über das System wissen muß, damit er loslegen kann. Bei einem hinreichend komplexen System, ist es in einer Woche nicht möglich, alle Komponenten kennen zu lernen. Es muß reichen, den Gesamtzusammenhang zu kennen, um dann eine Komponente identifizieren zu können, in der die Änderung gemacht werden muß. Wenn die Komponenten klare Zuständigkeiten haben, die sich möglichst auch in ihren Namen wiederspiegeln, so ist das machbar. Dann muß die zu ändernde Komponente so gut abgeschlossen sein, daß sichergestellt ist, daß die Änderung keine Rückwirkung auf andere haben kann. Bis hier ist die Sache noch recht klar.

Programmierstil

Was schlechter Programmierstil ist, kann jeder von uns wohl erkennen. Was aber ist ein guter Stil, insbesondere in Hinsicht auf das hier betrachtete Ziel? Ich kenne Projekte, die verbieten bestimmte fortgeschrittene Möglichkeiten der verwendeten Programmiersprachen. Dies erleichtert es, Mitarbeiter in das Projekt zu bringen, die mit dieser Programmiersprache nicht so gut vertraut sind. Allerdings bedeutet es, daß der Code dann entsprechend aufgeblasen wird. Statt einer kurzen Formulierung, die für denjenigen, der den Hintergrund kennt, sehr elegant ist, wird eine Menge Code geschrieben, dessen Ziel von dem Leser mühsam entschlüsselt werden muß. Dasselbe gilt für die Verwendung von APIs. Verwendung von Konstrukten, die eine höhere Abstraktion bewirken, sind für den Kenner wesentlich einfacher zu verstehen, während der Anfänger verständnislos davor steht.

Meine persönliche Ansicht hier ist die, daß alle Methoden erlaubt seien sollten, Code so knapp und klar zu machen, wie irgend möglich. Es zahlt sich immer aus, einen höheren technischen Kenntnisstand zu erwarten. Erstens ist es billiger, die Mitarbeiter einmalig zu schulen, wie jedesmal wenn der Code gelesen wird, zusätzliche Zeit aufzuwenden. Der zweite Grund ist, daß es für Leute, die die besten Methoden, ein Problem zu lösen, kennen, stattdessen eine weniger geeignetere wählen zu müssen. Im Zweifelsfall erfinden sie dann die gewünschte Technik neu, so daß sie für andere nicht mehr mit einem Lehrbuch erkennbar ist. Oder sie suchen sich ein fortschrittlicheres Team und das allgemeine Niveau des Projekts sinkt.

Verwendete Technologie

Zuerst einmal eine klare Erkenntnis: Jede zusätzliche verwendete Technologien, bedeutet zusätzlichen Einarbeitungsaufwand. Trotzdem kommt es immer wieder vor, daß Projekte mit der Zeit für dasselbe Problem unterschiedliche Lösungen verwenden. Dies kann z.B. daran liegen, daß eine Komponente zuerst gute Dienste geleitet hat. Dann aber für eine etwas unterschiedliches Problem eine zweite verwendet wurde. Wenn diese zweite daneben auch den Anwendungsbereich der ersten mit abdeckt, so könnte die erste entfernt werden. Der Aufwand wird aber häufig gescheut.

Eine andere Frage, die man betrachten muß, ist die Verbreitung der Technologie. Wenn jemand heutzutage versuchen würde, ein Projekt mit z.B. Lisp oder Scala starten würde, müßte er sich darüber im klaren sein, daß es auf dem Markt nicht sehr viele Leute gibt, die diese Technologien beherrschen. Wenn man die entsprechenden Spezialisten hat, kann man aber unter Umständen einen deutlichen Vorteil gegenüber Konkurrenten haben, der auf eine verbreitete Sprache wie Java setzt, die auch deshalb so weit verbreitet ist, weil sie für alles zu gebrauchen ist, für kaum aber wirklich ideal ist.