Refactor vor oder nach der Auslieferung?

Question

In einer Welt, in der die meisten Liefertermine von geschäftlichen Erfordernissen diktiert werden, liefern Programmierer in der Regel Code, der funktioniert. Wenn man weiß, dass der Code funktioniert, spielen Struktur und Effizienz des Codes oft keine Rolle mehr. Sofern keine Produktionsqualität vorgegeben ist (z. B. API für einen Algorithmus), ist bei Code, der nur wenige hundert Zeilen lang ist, lieferbarer Code gleichzusetzen mit Code, der funktioniert.

Meine Frage ist folgende: Würden Sie so lange programmieren, bis das Feature funktioniert, und dann fertig sein, wenn Sie ein ETA für ein Feature angeben? Oder würden Sie es so schnell wie möglich zum Laufen bringen und für die Release-Qualität überarbeiten?

Ich tendiere zu Letzterem, obwohl es nach mehr Arbeit klingt. Wenn Code, der funktioniert, auf algorithmische Effizienz und Muster hin zerlegt wird, ist es eine freudige Erfahrung, ihn wieder zusammenzusetzen. Außerdem bekommt es all die nicht-funktionale Liebe - weniger Bugs, performant, erweiterbar, sicher. Ich glaube nicht, dass ich gut darin bin, beim ersten Mal den besten Code zu schreiben. Daher funktioniert dieser Ansatz gut für mich.

Ich würde gerne wissen, welche Methode bevorzugt wird und warum? Ich bin nicht auf der Suche nach einem branchenweiten Ansatz, sondern nur nach individuellen Neigungen, damit ich die Ähnlichkeit der Gedanken beurteilen kann.

Answer 1

Ich bevorzuge Refactoring vor und nach dem Versand.

Eine Überarbeitung bis nach der Veröffentlichung zu verschieben, klingt sehr danach, dass Sie wahrscheinlich niemals tatsächlich zu tun (meistens kommt etwas Wichtigeres dazwischen). Aber selbst wenn Sie es vor der Auslieferung tun, ist es nicht so, dass Ihr Code perfekt ist und Ihnen die Dinge ausgehen, die Sie verbessern können. Das gilt auch für die Zeit danach (sofern der Code in irgendeinem Umfang gepflegt wird).

Für mich ist das Refactoring von Code zu etwas Einfacherem und Saubererem ein kontinuierlicher und natürlicher Teil jeder Softwareentwicklung.

Edit: Natürlich müssen Sie bei Ihrer Entscheidung auch geschäftliche Zwänge berücksichtigen. wie viel und wie lange Sie refaktorisieren zu einem bestimmten Zeitpunkt.

Edit 2: Zur Frage "Wie überzeuge ich meinen Vorgesetzten vom Refactoring?" (siehe Kommentare) gibt es hier einige Ressourcen, die helfen könnten:

• Refactoring dem Management erklären bei InfoQ
• Martin Fowlers bahnbrechendes Buch Refaktorierung ( in vollem Umfang online verfügbar ) hat einen Abschnitt mit dem Titel " Was soll ich meinem Vorgesetzten sagen? ". Ich empfehle auf jeden Fall, die ersten beiden Kapitel des Buches zu lesen, da sie die grundlegenden Ideen zum Refactoring klarer erklären als alles andere, was ich kenne.

Answer 2

Wenn Sie testgetriebene Entwicklung betreiben. Oft schreibt man zuerst das Einfachste, was funktioniert, und refaktorisiert dann, wenn zusätzliche Funktionalität hinzukommt (AKA Red, Green, Refactor).

In dieser Frage gibt es natürlich eine große Grauzone. Wenn Sie ein unwartbares Chaos ausliefern, sollten Sie vielleicht überdenken, wie Sie den Code überhaupt schreiben. Refactoring sollte zu einem bestimmten Zweck durchgeführt werden - um den Code flexibler zu machen, um zum Beispiel eine neue Art von Produkt zu ermöglichen. Refaktorieren Sie nicht einfach, weil Sie meinen, dass Sie es sollten.

Answer 3

In unserem Team betrachten wir nicht refaktorisierten Code als nicht "fertig". Mit anderen Worten: "Code wurde überarbeitet" ist Teil unserer Definition von Erledigt Das ist eines unserer Kriterien für versendbaren Code.

Answer 4

Das Problem ist, wenn Sie dazu neigen, nur nach dem Versand zu überarbeiten, werden Sie es nie tun ;)

Ich neige dazu, unter "fertig" auch gut durchdachten Code zu verstehen.

Es gibt Ausnahmen von dieser Regel, wenn es sich um ein sehr umfangreiches Refactoring handelt, das einen hohen Aufwand erfordert. Um eine Frist einzuhalten, könnten Sie die nächste Entwicklungsiteration verschieben.

Answer 5

Ich würde es vorziehen, vor der Auslieferung eine Überarbeitung vorzunehmen. Sie haben Recht, mein erster Code ist oft nicht der beste Entwurf. Aber wenn Sie einen erfolgreichen Test für den Code haben, sollte es wenig Risiko geben, direkt danach zu überarbeiten.

Und das Problem, es später zu tun, ist einfach "nach der Freigabe, wenn vor der Freigabe". Meiner Erfahrung nach gibt es keinen Grund, darauf zu hoffen, dass nach der Freigabe noch Zeit zum Aufräumen bleibt.