Refactoring - Der "tägliche" Wahnsinn.

Wer kennt das nicht... Ein Projekt entwickelt sich immer weiter, natürlich kommt man an einen Punkt und stellt fest, XY benötige ich jetzt schon in 2 Units, 3 Units, 4 Units... Ab wann wird es Zeit daraus ein Pattern zu machen?

 

Frühzeitig? Nach Abschluss?

 

Aber was ist, wenn ich dieses Pattern mit nur kleinen Veränderungen auch in 3-5 anderen Units verwenden könnte? Soll ich lieber eine Kopie machen oder die Veränderungen mit einem Parameter steuern? Oder übergebe ich die Funktionalität lieber als interface an das Pattern? Was sieht nicht nur schick im Source-Code aus, sondern ist dann auch praktisch in der Benutzung? Fragen über Fragen.

 

Ich habe mittlerweile eine Klasse, die hat heute zum 2. Mal einen neuen Namen bekommen und die Unit habe ich zum 3. mal renamed. Natürlich nicht ohne die Documentation, das Handbuch und alle Anwendungen die daraufhin geändert werden müssen neu zu kompilieren. War das eine gute Idee?

 

Also vielleicht erstmal ein paar "Rule of Thumbs" generieren.

 

1. Je mehr Code ich vernichten kann, weil ich eine "zentrale" Routine nutze. Desto weniger Codezeilen können einen Fehler haben.
2. Wenn meine Anwendung in der Regel "nur" Basis-Routinen aufruft und diese fehlerfrei sind, um so weniger Fehler kann meine Anwendungen haben. Voraussetzung hierfür ist natürlich die Testbarkeit. Da jedoch "zentrale" Routinen einfacher zu testen sind, ist meine Anwendung einfacher zu testen.
3. Ist die Basis-Routine Threadsave, ist es einfacher meine eigenen Routinen Threadsave zu gestalten (vereinfacht ausgedrückt). // Ach wäre doch nur die VCL/RTL Threadsave.
4. Bei der Schaffung einen neuen Basis für XY erkaufe ich mir jedoch Zwangs-Verlinkungen ein!

Lohnt es sich also zu Refrakturieren?

 

Auf jeden Fall - am besten immer so schnell wie möglich, wenn ich ein Problem erkenne. Je früher ich es behebe, desto weniger Source-Code baut darauf auf.

 

"Nur das mit der Doku ist lästig, wenn ich eine habe..."