Dein Team will ein Legacy-System neu schreiben. Wie entscheidest du?

Standard ist inkrementeller Ersatz statt eines kompletten Rewrites. Rewrites unterschätzen das Verhalten, das im alten System kodiert ist, und zwingen dich, zwei Dinge zu pflegen, während du nichts Neues lieferst. Bevorzug es, das System Stück für Stück hinter einem stabilen Interface abzuwürgen, wobei jeder Schritt für sich Wert liefert. Erwäg einen kompletten Rewrite nur, wenn die Plattform wirklich nicht mehr tragbar ist und du den Zeitplan vor Feature-Druck schützen kannst.

Mein Default ist nein, und dann versuche ich zu verstehen, was sie tatsächlich wollen, denn Rewrite ist meist ein Symptom. Manchmal ist es wirklich eine tote Plattform, und manchmal ist es, dass die Testsuite vierzig Minuten braucht und jede Änderung beängstigend ist, was ein viel billiger zu lösendes Problem ist. Wenn Ersatz richtig ist, will ich ihn inkrementell: ein Interface vor das alte System stellen, eine Fähigkeit nach der anderen dahinter verschieben und sicherstellen, dass jede Scheibe releasebar ist und für sich etwas liefert. So überlebt das Projekt eine Umpriorisierung, was ein zweijähriger Big-Bang-Rewrite nie tut. In meinem letzten Team haben wir eine Legacy-Order-Pipeline so über etwa neun Monate ersetzt, und wir haben zweimal aus geschäftlichen Gründen pausiert, ohne etwas zu verlieren. Der Fall, in dem ich einen echten Rewrite machen würde, ist eine Runtime oder ein Framework ohne Support und ohne inkrementellen Pfad, und selbst dann will ich ein explizites schriftliches Gespräch mit der Führung über den Feature-Freeze, denn der klassische Fehler ist ein Rewrite plus volle Roadmap.