Gerade eines der Urgesteine – Delphi – macht es Entwicklern leicht, Code zu schreiben, der sich nur mit Mühe refactoren lässt. Was hier zu beachten ist, wenn man die Sanierung seines Codes angeht, zeigt Bernd Ua auf dem Delphi Code Camp in seinem mittlerweile ausgebuchtem Workshop Softwaresanierung und Refactoring. Wir haben die Zeit genutzt, um mit ihm über die typischen Stolperfallen in der Entwicklung in Delphi zu sprechen.

Refactoring in Delphi

Herr Ua, warum ist es gerade in Delphi so „einfach“, Code zu schreiben, der Tests und ein vernünftiges Refactoring erschwert?

Bernd Ua: Der RAD-Ansatz, den die IDE ermöglicht und fördert, steht in der Regel klaren Konzepten und der späteren Wartbarkeit entgegen. Es ist eben furchtbar leicht und schnell, „mal eben“ eine Anwendung mit Komponenten zusammen zu klicken. Und da erfordert es Disziplin, in den Ereignishandlern, die man so schön schnell erstellt und über den Objektinspektor erreicht, nicht ebenso schnell und leichtfertig GUI-Code und Datenlogik zu mischen. Da das Komponentenstreaming und Formularstreaming der IDE auch noch auf öffentlichen Methoden und Eigenschaften beruht, muss man sich auch hier beherrschen, nicht alles zu verwenden, was man verwenden könnte.

Das ist manchmal schon ein bisschen wie der Versuch auf Süßes zu verzichten, während man vor einem Berg Schokolade sitzt.

Was sind Ihrer Erfahrung nach die häufigsten Fehler, die Entwickler begehen?

Bernd Ua: Zu enge Kopplung der Komponenten und Schichten einer Anwendung ist eines der Hauptprobleme. Da sind Formulare und Datenmodule untereinander so eng gekoppelt, dass man nichts separat ersetzen oder testen kann. Oder es sind die Schichten bis zur Unkenntlichkeit miteinander verwoben oder nicht existent, so dass der Businesscode nicht ohne GUI getestet werden kann oder GUI-Komponenten nicht ausgetauscht werden können, ohne Businesscode anzufassen.

Ist es nicht beinahe unmöglich, ein solches System zu sanieren?

Bernd Ua: Es ist schwer, aber nicht unmöglich.

Aber die Frage ist auch schwer pauschal zu beantworten, dafür sind Softwaresysteme zu unterschiedlich. Wenn es zum Beispiel gar kein Schichtenkonzept in einer Anwendung gibt, ist es fast unmöglich, so ein Schichtenkonzept ausschließlich im Rahmen kleiner Refakturierungs-Schritte einzuführen, während eine zu enge Kopplung zwischen Formularen sich schon eher schrittweise lösen lässt.

Gibt es dafür ein Patentrezept? Oder Schritte, die es zu beachten gilt?

Bernd Ua: Ein Patenrezept sicher nicht. Aber man kann versuchen, das Programm mit jeder Änderung zu verbessern, statt es mit jeder Änderung mehr und mehr degenerieren zu lassen. Besonderes wenn Sie App entwickeln lassen möchten gibt es noch wichtige Sache. Eine wichtige Leitlinie ist dabei die Testbarkeit der Änderungen. Wenn man eben nicht jede globale Variable oder statische Referenz als Ausrede hernimmt, warum denn die letzte Änderung nicht mit Tests abgesichert werden konnte, sondern stattdessen konsequent versucht jeweils so zu refakturieren, dass die Änderung testbar wird, ist man zumindest auf einem besseren Weg.

Auf dem Delphi Code Camp werden Sie sich genau mit diesem Thema beschäftigen. Auf welche Gesichtspunkte werden Sie dabei ein besonderes Augenmerk richten?

Bernd Ua: Mir sind zum einen praxisnahe Tipps und Rezepte wichtig, welche die Teilnehmer auf eigene Softwareprojekte anwenden können und die sich an den spezifischen Möglichkeiten und Problemen der Sprache orientieren, aber daneben auch grundlegende Konzepte, wie die SOLID-Prinzipien oder Entwurfsmuster.