Was sind Brownfield-Projekte? Nur die allerwenigsten Software-Entwicklungsprojekte starten von Grund auf neu, also auf der sprichwörtlichen "grünen Wiese" (Greenfield). Schon aus wirtschaftlichen Gründen streben Unternehmen an, möglichst viel der bereits in der Vergangenheit entwickelten Software wiederzuverwenden bzw. ein neues Software-System auf existierenden (Legacy) Code zu errichten. Diese sogenannten Brownfield-Projekte besitzen zumeist eine gewachsene, schlecht bis gar nicht dokumentierte Architektur, geringe bis keine Testabdeckung und einen manuellen Build- und Deploymentprozess. Brownfield-Code kann durchaus alle funktionalen Anforderungen erfüllen – wartbar und erweiterbar ist er deshalb noch lange nicht. Schnell stellt sich im Projektverlauf heraus, das der ursprünglich vermutete Vorteil, nämlich: die Hoffnung, das man das bestehende Software-System schnell und kostengünstig mit ein paar kleinen Änderungen und Anpassungen für das neue Projekt wiederverwenden kann, verschwunden ist. An Stelle des erwarteten, schnellen Projektfortschritts treten nun schwerwiegende Probleme mit der inneren Code-Qualität: Änderungen führen zu unerwünschten Seiten- und Nebeneffekten, das System wird fragil. Folgen sind Zeit- und Budgetprobleme, sinkende Kundenzufriedenheit, etc. pp, eben das, was wir alle sicherlich aus eigener Erfahrung kennen…
Die Artikelserie auf heise Developer beschäftigt sich genau mit diesen typischen Problemen in herausfordernden Brownfield-Projekten und möchte zeigen, wie Entwickler ihren über die Jahre gewucherten Code wieder sauber und wartbar bekommen, indem sie die Prinzipien und Praktiken der "Clean Code Developer"-Initiative auch in diesem schwierigen Umfeld anwenden.
Bis heute sind vier der 7 angekündigten Teile der Serie erschienen:
- 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
Diese Artikelserie sei allen Entwicklern, aber auch Entscheidern, ans Herz gelegt.
