Ich hatte vor ein paar Wochen eine Diskussion mit einigen Kollegen über Refactoring, und ich scheine zu einer Minderheit zu gehören, die glaubt, dass "Refactor early, refactor often" ein guter Ansatz ist, der verhindert, dass der Code unordentlich und unwartbar wird. Einige andere meinten, dass dies nur in die Wartungsphasen eines Projekts gehört.
Wenn Sie eine Meinung haben, verteidigen Sie diese bitte.
Wie Sie schon sagten: Refaktorieren Sie früh, refaktorieren Sie oft.
Frühes Refactoring bedeutet, dass die notwendigen Änderungen noch frisch in meinem Kopf sind. Häufiges Refactoring bedeutet, dass die Änderungen eher kleiner ausfallen.
Eine Verzögerung der Umstrukturierung führt nur zu einem großen Durcheinander, das die Umstrukturierung noch schwieriger macht. Aufräumen, sobald ich das Chaos bemerke, verhindert, dass es sich aufbaut und später zu einem Problem wird.
Ich überarbeite den Code, sobald er funktionsfähig ist (alle Tests bestehen). Auf diese Weise bereinige ich ihn, während er noch frisch in meinem Kopf ist und bevor jemand anderes sieht, wie hässlich die erste Version war.
Nach dem ersten Check-in führe ich in der Regel jedes Mal ein Refactoring durch, wenn ich einen Teil des Codes berühre. Refactoring ist nichts, wofür man sich extra Zeit nehmen sollte. Es sollte etwas sein, das man einfach nebenbei macht.
Sie schreiben Code mit zwei Hüten auf. Die einfach-alles-zum-Laufen-bringen Hut und der Ich-muss-das-morgen-verstehen Hut. Der zweite Hut ist natürlich das Refactoring. Sie führen also jedes Mal ein Refactoring durch, wenn Sie etwas zum Laufen gebracht haben, aber (unvermeidlich) Gerüche wie doppelten Code, lange Methoden, anfällige Fehlerbehandlung, schlechte Variablennamen usw. eingeführt haben.
Refactoring, während man versucht, etwas zum Laufen zu bringen (d.h. beide Hüte zu tragen), ist für nicht-triviale Aufgaben nicht praktisch. Aber das Refactoring auf den nächsten Tag/die nächste Woche/die nächste Wiederholung zu verschieben, ist sehr schlecht, weil man dann den Kontext des Problems nicht mehr im Kopf hat. Wechseln Sie also so oft wie möglich zwischen den Hüten, aber kombinieren Sie sie nie.
Ich refaktorisiere bei jeder sich bietenden Gelegenheit, weil ich dadurch meinen Code so gut wie möglich verbessern kann. Ich tue dies sogar, wenn ich aktiv entwickle, um zu verhindern, dass ich von vornherein unwartbaren Code erstelle. Außerdem kann ich so oft eine schlechte Designentscheidung korrigieren, bevor sie nicht mehr zu beheben ist.
Drei gute Gründe für ein Refactoring:
Drei gute Gründe, nicht zu refaktorisieren:
"Unordentlich" ist umstritten - es gibt ein stichhaltiges Argument, das als "Reparieren von kaputten Windows" oder "Codehygiene" bezeichnet wird und besagt, dass man, wenn man kleine Dinge schleifen lässt, auch große Dinge schleifen lassen wird. Das ist in Ordnung und eine gute Sache, die man im Hinterkopf behalten sollte, aber denken Sie daran, dass es eine Analogie ist. Sie entschuldigt nicht, dass man auf der Suche nach einer möglichst sauberen Lösung endlos herumhantiert.
Wie oft Sie Refactoring durchführen, sollte davon abhängen, wie oft die guten Gründe dafür auftreten und wie sicher Sie sind, dass Ihr Testprozess Sie vor der Einführung von Fehlern schützt.
Refactoring ist nie ein Ziel an sich. Aber wenn etwas nicht funktioniert, muss es behoben werden, und das gilt für die Erstentwicklung ebenso wie für die Wartung. Bei nicht-trivialen Änderungen ist es fast immer besser, zu refaktorieren und die neuen Konzepte sauber einzubauen, als an einer einzigen Stelle einen großen Haufen Schrott zu flicken, um Änderungen an anderer Stelle zu vermeiden.
Ich halte nichts davon, eine Schnittstelle zu ändern, wenn ich weiß, wofür sie verwendet wird, und wenn der Umfang der Änderung überschaubar ist.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
