WerdenWirNichtBrauchen wird also nicht auf CodeRefactoring angewendet - solch ein Verhalten wäre ein Beispiel für DunklesYagni.

Diskussion

WerdenWirNichtBrauchen gilt nur für Funktionalität, aber die Devise, Zeit für das wichtigste zu nutzen, sollte immer gelten. Mir ist aber nicht klar, wieso ich nach statt vor der Implementierung der Anforderungen refaktorieren sollte. -- gR

Wenn Du testgetrieben entwickelst, refaktorierst Du genaugenommen während der Implementierung von Anforderungen - immer zwischen zwei Implementierungsschritten. Bei Implementierungsschritten von der Länge weniger Minuten macht die Frage nach dem "davor oder danach" eigentlich kaum noch Sinn, so scheint es mir. -- IljaPreuß

Refaktorisierst Du, nachdem alle Tests laufen und alle Anforderungen umgesetzt wurden? -- gR

Zum Zeitpunkt von Refactorings aus nicht agiler bzw. klassischer Sicht:

• Ich refaktorisiere dann, wenn für die Änderung, die ich machen will, im Code "keinen Platz frei ist", d.h. wenn z.B. vor lauter Abhängigkeiten die Stelle nicht zu sehen ist, wo der Code hinkommt (natürlich stammt solch ein Code niemals von mir, ist klar, oder? :-). Das ist deshalb meistens "vorher".
• Außerdem refaktorisiere ich am Ende einer größeren Geschichte, wenn ich will, dass ich mich mit diesem Code als @author auch "sehen lassen kann". :-)
• Noch ein Aspekt: Ich habe mal versucht, einen Manager dazu zu überreden, das Projekt brauche jetzt Zeit zum Aufräumen. Keine Chance. Daher: Refaktorisieren, wenn das Management gerade Zeit für ein neues Feature freigegeben hat! Das ist also auch meistens "vorher".
• Ich stimme aber Ilja zu, dass "vorher" oder "nachher" kein Prinzip sein darf. -- MatthiasBohlen

• Da es GemeinsameVerantwortlichkeit gibt, existiert soetwas wie mein Code oder dein Code nicht, sondern lediglich unser Code wird gepflegt. Wenn ich vorhandene UnitTests erfüllt habe oder CodeReviews? durchführe, refaktorisiere ich.
• Da ich DokumentationImQuelltext praktiziere und, viel wichtiger, da es ein CollectiveCodeOwnership? gibt (siehe auch GemeinsameVerantwortlichkeit), ist mir ein @author egal. Wen etwas an von wem auch immer produzierten Code und aus welchen auch immer gearteten Gründen stört, der möge seinerseits refaktorisieren. Eine gute Kommunikation der Beteiligten verhindert ein stetes HinUndHerRefactoring?.
• Refactoring (mit Ausnahme von grossenRefaktorisierungen) erfolgt stetig innerhalb eines Testzyklus, d.h. im 10-Minuten-Takt. Verglichen mit einer Werkstatt, in der nach jedem Arbeitsschritt aufgeräumt wird, da ansonsten der Platz zum Arbeiten fehlt und die Werkzeuge nicht oder schlecht benutzt werden können, sollte Refactoring einen hohen Stellenwert bei der Entwicklung erhalten. Das Management davon zu überzeugen, aufräumen zu müssen, sollte durchführbar sein. -- bs

Wenn nichts schiefgegangen ist, nicht länger als fünf Minuten. Aber natürlich ist das situationsabhängig. Ich habe das Gefühl, dass die Frage damit nicht wirklich beantwortet ist. Ich bin mir noch nicht mal sicher, ob ich genau verstanden habe, was die Frage ist. Was ist die Frage? -- ip