Gutachten: Java Code Review

Code Review

"Viele Programmierer wechseln nach zwei Jahren den Arbeitgeber, da sie ihren eigenen Code nicht mehr lesen können. Dafür übernehmen sie ein Projekt, von einem anderen Programmierer, der gerade gekündigt hat, da er ebenfalls den Code nicht mehr lesen kann. Nach einigen Wochen oder Monaten überzeugt der Programmierer in seiner neuen Stelle seinen Chef, den Code seines Vorgängers zu verwerfen und neu zu beginnen. Nach zwei Jahren wiederholt sich die Geschichte."

Die obige Geschichte wiederholt sich leider permanent mit leichten Abweichungen und Variationen. Durch Maßnahmen wie Code Reviews oder Refactorings können solche Geschichten vermieden werden. Wiederholung wird zum einen dadurch begünstigt, dass viele Vorgesetzte es nicht gerne sehen, wenn nicht permanent neue Features und sichtbare Verbesserungen an der fertigen Software entstehen. Codepflege und Codereviews tragen zu nächst nichts zu neuen Features und damit zum Wohl der Abteilung und des Unternehmens bei. Ein weiterer Grund für die Wiederholung ist bei den Programmierern selbst zu suchen:

"Neue Funktionalität zu codieren ist cooler als alten Code zu verbessern."

Wer sich intensiver mit Code Reviews beschäftigt wird schnell feststellen, dass gerade Code Reviews von objektorientierter Software eben doch unheimlich cool sind. Es macht Freude:

Einbeziehung in den Entwicklungsprozess

Code Reviews können als fester Bestandteil in den Entwicklungsprozess aufgenommen werden. Nach der Implementierungsphase oder vor dem Erstellen eines Releases ist die Durchführung von Code Reviews sinnvoll.

Durchführung durch Interne oder Externe

Die Ergebnisse eines Reviews sind oft hart und direkt. Im Gegensatz zum Design- und Architekturreview ist es für die betroffenen Entwickler schwerer zu argumentieren und sich zu verteidigen.

"Ein Review ist nicht als Angriff auf die Entwickler, sondern als Hilfe gedacht!"

Die meisten Entwickler würden selbst auf mehr Code Qualität achten, wenn sie die Zeit dazu hätten. Starker Termindruck läßt oft keinen Freiraum für Reviews und Refactoring.

Externe Berater können diese Situation entspannen, da die "Kritik" nicht vom Kollegen sondern von einem Fremden kommt. Gerade beim Programmieren schleichen sich nach der Zeit Gewohnheiten ein, die ein Außenstehender ohne Betriebs- oder Teamblindheit leichter erkennt.

Code Review oder Refactoring

Beim Code Review wird bestehender Code analysiert und das Ergebnis festgehalten. Im Ergebnis wird die Qualität des Codes dokumentiert und gegebenfalls weitere Massnahmen vorgeschlagen. Beim Refactoring wird davon ausgegangen, daß man den Code erst richtig versteht, indem man ihn schrittweise verbessert. Sich in den Code hineinzuversetzten und die Verbesserung des Codes erfolgt gleichzeitig.

Beim Refactoring werden die durchgeführten Verbesserungen anhand von Tests überprüft. Das Testen erfordert meist ein gewisses Mass an Infrastruktur. Soll für eine Anwendung, die mit Enterprise JavaBeans und Servlets realisiert wurde, ein Refactoring durchgeführt werden, so müssen die entsprechenden Server bereitgestellt werden. Automatisierte Unittests z.B. mit JUnit erleichtern das Testen erheblich. Diese Tests werden leider nicht für jede Anwendung erstellt.

Ist die notwendige Infrastruktur und genügend Zeit vorhanden, könnte anstatt eines Code Reviews gleich ein Refactoring durchgeführt werden. Sind diese Vorraussetzungen nicht gegeben, kann ein Code Review ein erster Schritt sein, um Potentiale für ein zielgerichtetes Refactoring aufzuzeigen.

Ansprechpartner:

Dirk M. Sohn
Tel.: (0621) 71839-42
sohn@<spamschutz>oio.de (Hinweis: <spamschutz> bitte aus E-Mail Adresse löschen.)

Zum Geschaeftsbreich Competence Center