ragtek

Auf div. Seiten und Büchern liest man zum Thema Refaktoring, dass man entweder den Reafktoring Hut, oder den Entwicklungs Hut aufhat.

Wieso nicht beides auf einmal?
Wenn ich ein ins Jahre gekommenes Feature betrachte, habe ich:
1. Denn Wunsch, dass Feature an die neue Architektur anzupassen (zB an die restliche mvc architektur anzupassen, anstatt der "unsauberen" bridge, die man bisher hat
ABER man hat auch
2."user stories" bzw die Todo Liste, mit den Verbesserungswünschen bzw nötigen Änderungen am Design und den Funktionen.

Wie bringt man diese 2. Sachen unter einen Hut (Stichwort Refaktoringhut & Entwicklerhut, aber man hat nie beide gleichzeitig auf) (wieso eigentlich? )

Ich weiß, was für Anforderungen ich an meine Applikation stelle, ich weiß was alles am "Ende" da sein muss, wieso kann ich dann wärend ich refaktoring betreibe, nicht die neuen Sachen schon im Hinterkopf behalten und den Code dahingehend anpassen?

Mister Ad

Flor1an

Refaktoring betreibst du doch immer gerade deswegen um den Code einfacher/übersichtlicher/mächtiger zu machen was wiederum weiteren Features und "Todos" entgegen kommt. Du veränderst den Code ja dahingehend das er später besser zu erweitern ist. Was die mit dem Hut meinen ist wohl eher: Entweder fügst du neue Funktionalität hinzu (Entwickler) oder du schreibst bestehenden Code um (Refaktoringhut).

elise

wo liest du das?

Typischerweise gehen Leute wie Martin Fowler oder der Mitbegründer(-denker) der agilen Programmierung Kent Beck davon aus, dass immer und sofort (und das genau im Entwicklungs-/Implementierungsprozess), wenn du in der konkreten Entwicklungsphase 'Code Smells' (entstanden aus einer Geschichte der Großmutter von Kent Beck) findest (riechst), der Umstrukturierungsprozess erfolgen soll. Also existiert keine Trennung von Entwicklung und Refaktorisierung. Auch nicht zeitlich.
Nicht umsonst gibt es heute die -zumindest für typgeprüfte Sprachen- schon gut funktionierenden Refaktorisierungstools, in Eclipse oder Netbeans u.a., die helfen sollen, den Code zu einem besseren Design zu verhelfen, ohne seine Bedeutung, seine Semantik zu verändern.
Genau diese Code Smells sind es ja, die nach Meinung von Beck und Fowler die neu geforderten Features des Kunden im nachhinein schwer integrieren lassen.
Man kann streiten, ob der Ansatz (vor allem verwirklicht in der agilen Programmierung, die ja in einigen Büros heute betrieben wird) ausreicht und in welchen Zusammenhängen er wirklich greift. M.E. vor allem genau im Webbereich, in dem der Kunde gerne mal eben "alles umwirft", weil er gerade "was viel besseres" gesehen hat. In großen Firmen, in denen alles nach ISO Norm dingdsa007 abgesichert sein muss, versucht -meiner Erfahrung nach- heute oft der einzelne/die einzelne Programmier/in zwar, diesen Ansatz von Fowler zu verwirklichen, jedoch ist man/frau da verstrickt in einen noch vollständig anderen Denkansatz von Planen, Entwickeln, Testen, Ausliefern, der wenig Spielraum zulässt.

__________________
OSL♥