Herausforderung Brownfield, Teil 2: Das Sicherheitsnetz aufspannen

Inhaltsverzeichnis

Um Brownfield-Projekte gemäß den Prinzipien der "Clean Code Developer"-Initiative zum Erfolg zu führen, ist es wichtig, ein Sicherheitsnetz für Softwareentwickler aus Versionskontrollsystem und Continuous Integration zu spannen. Nur so nimmt man ihnen die Angst, etwa Code zu verlieren, und ermöglicht ihnen, auf Fehler angemessen zu reagieren.

Dass etwas verloren gehen könnte, ist eine große Angst bei der Entwicklung von Software. Das zeigt sich beispielsweise in Codebereichen, die auskommentiert sind. Oft werden nicht mehr benötigte Abschnitte nicht entfernt, sondern durch Kommentare nur inaktiv geschaltet. Schaut man sich den Code genauer an, stellt man häufig fest, dass er so trivialer Natur ist, dass ein Entwickler ihn jederzeit wieder neu schreiben könnte. Dahinter mag die latente Absicht liegen, effizient zu arbeiten. Schließlich möchte man Code nicht zweimal entwickeln. Also erscheint es ihm ressourcenschonend, ihn nur auszukommentieren, um ihn bei Bedarf wieder hervorzuholen.

Mehr Infos

Herausforderung Brownfield

Im Rahmen einer Artikelserie beleuchten die Initiatoren der "Clean Code Developer"-Initiative, Stefan Lieser und Ralf Westphal, die Herausforderungen an Clean Code Developer in Brownfield-Projekten.

• Teil 1: Was sind die Probleme?
• Teil 2: Das Sicherheitsnetz aufspannen
• Teil 3: Das Sicherheitsnetz erweitern
• Teil 4: Komplexität bewältigen durch Partitionierung
• Teil 5: Explizite Architektur als Ziel für Refaktorisierungen
• Teil 6: Partitionen durch Refaktorisierung evolvierbar machen
• Teil 7: Alle Veränderung in kleinen Schritten durchführen

Manchmal trauen sich zudem Entwickler nicht, einen Codeabschnitt zu löschen, weil sie nicht genau verstehen, was der Code ausführt. Deswegen löschen sie ihn nicht, sondern kommentieren ihn, in der Hoffnung, mit der Information irgendwann noch mal etwas anfangen zu können.

Trotz aller guten Absichten ist ein Manko an auskommentiertem Code, dass er letztlich eher hinderlich ist, als dass er hilft. Code, der auskommentiert ist, spielt zur Laufzeit keine Rolle, schließlich beachtet ihn nicht einmal der Compiler. Aber offensichtlich scheint er trotzdem eine gewisse Rolle zu spielen, sonst hätte der Entwickler ihn entfernt.

Stößt ein Programmierer auf auskommentierten Code, muss er ihn dennoch lesen und interpretieren. Da der Compiler den Code aber nicht mehr beachtet und ihn auch die Entwicklungsumgebung nicht interpretiert, ist die Herausforderung viel höher, ihn zu verstehen. Schon die fehlende Einfärbung syntaktischer Einheiten gestaltet es schwieriger, den Code zu lesen. Tooltips und andere Analysen stehen gar nicht zur Verfügung. Das andere Problem hängt mit der Tatsache zusammen, dass der Compiler den Code nicht mehr berücksichtigt. Das führt dazu, dass der Code unverändert stehen bleibt, während die Umgebung, in die der Code eingebettet war, sich womöglich verändert. Bereits das Umbenennen von Bezeichnern führt dazu, dass der auskommentierte Code nicht mehr mit dem Rest synchronisiert ist. So gestaltet es sich immer schwieriger nachzuvollziehen, wozu der Code ursprünglich diente.

Schließlich sorgen die Kommentare dafür, dass der Code unleserlich und damit unverständlich wird. Man erreicht das Gegenteil von dem, wozu Kommentare dienen sollen, nämlich schwer verständliche Codebereiche zu erläutern. Da die oben beschriebenen Ängste letztlich unberechtigt sind, sollten Entwickler den auskommentierten Code entfernen. Damit das in einem Team von Entwicklern nicht zu Verwirrungen führt, ist darüber vorher im Team zu sprechen.