Viele Entwickler in unserem Team vermeiden Refactoring. Die Diskussion dieser Situation ergab die folgenden Gründe.
Warum viele nicht umgestalten
beängstigend, bestehende Funktionen zu brechen
zeitaufwändig: Wenn sich der Code, den Sie umgestalten, ändert, wird das Zusammenführen (mehrmals) aus dem Hauptzweig zu einem Problem
Es besteht die Gefahr, dass Sie nicht rechtzeitig zum Stichtag der Aufgabe erscheinen
Gleichzeitig ist das Refactoring fast ein wesentlicher Bestandteil des Entwicklungsprozesses. Sein Bedarf ist mit folgenden Voraussetzungen verbunden:
Die anfänglichen Anforderungen sind fast nie vollständig und die Entwicklung erfolgt nach bestimmten Annahmen, von denen sich einige später als falsch oder ungenau herausstellen
Oft müssen Sie schnelle Änderungen vornehmen, damit es hier und jetzt funktioniert, ohne weitere Unterstützung in Betracht zu ziehen
Wenn Refactoring gerechtfertigt ist (erforderlich)
Ich sehe die folgenden Gründe für die Änderung der Struktur des Codes:
doppelter Code
Es gibt nur wenige Gründe für doppelten Code. Meistens muss er entfernt werden
Universalisierung
Um Ihren Code verständlicher zu machen und Betriebsprobleme zu reduzieren, können Sie häufig eine Abstraktion erstellen, die ähnlichen Code kombiniert. Es ist wichtig, mindestens 3 Prototypen für diese Abstraktion zu haben, da sie sonst möglicherweise nicht genau ist
, GooglePay. , ApplePay SamsungPay . VendorPay
,
/
, 50 500 ,
: , , .
, . , , , , . , () , .
?
, , :
(unit )
-
, -
feature- master' .
, , , . , , , . , , .
- (- + ) , , ( master'), - - .
, master rebase - master.
Dieser Ansatz ist mit einem gewissen Aufwand verbunden, verringert jedoch die Hauptprobleme bei der Umgestaltung:
Das Überprüfen und Zusammenführen von Refactoring ist nicht so beängstigend, da es im Grunde keine funktionalen Änderungen mit sich bringt oder diese funktionalen Änderungen in einer kleinen Pull-Anfrage deutlich sichtbar sind
Änderungen anderer Entwickler müssen nicht unterstützt werden, da die Änderungen fast sofort in den Hauptzweig übernommen werden
Wenn die Fristen verlängert werden, können Sie das Refactoring nach dem nächsten Zyklus von zwei bis drei Tagen einstellen