Wie rechtfertige ich die Code-Refactoring-Zeit?

Habe ein sehr großes Projekt über 70k LOC.

Das Projekt benötigt definitiv einige Code-Umgestaltungen in Core Framework und auch in anderen Teilen. Zu Beginn des Projekts wurde KEINE Zeit für das Refactoring festgelegt. Mit der Zeit schlossen sich jedoch mehr als 40 Entwickler zusammen und verließen das Projekt. Aus meiner Sicht ist unverzichtbar.

Was wären Ihre wichtigsten Punkte bei der Argumentation und Verteidigung eines ordnungsgemäßen Softwareentwicklungsprinzips?

Wenn Sie an einer Alt- oder Industrieanwendung arbeiten, ist es verlockend, einen "Frühjahrsputz" durchzuführen, um das Ganze wieder in Form zu bringen. Das ist in keiner Weise gerechtfertigter Ressourceneinsatz. Wie kann man die Entwicklung von funktionierender Software stoppen (nur funktionierender Code kann überarbeitet werden)? Können Sie garantieren, dass sich die für die Big Refactoring-Phase aufgewendete Zeit später auszahlt und keine Degeneration des Projekts verursacht?

Wie isst du einen Elefanten? Ein Bissen nach dem anderen. Wann immer Sie eine neue Funktion implementieren oder einen Fehler beheben müssen, sehen Sie, ob dieser Teil verbessert werden muss. Wie die Pfadfinderregel sagt: "Verlassen Sie den Campingplatz immer sauberer, als Sie ihn vorgefunden haben." Refactoring sollte keine separate Phase sein, es ist Teil der täglichen Entwicklung.

Wenn Sie diese Qualitätskultur in das Entwicklungsteam einbringen, wird sich die Qualität verbessern. Danach ist dem Management nichts mehr zu rechtfertigen.

Im Allgemeinen sollte das Refactoring durchgeführt werden, um eine weitere Änderung am Code zu ermöglichen, oder als natürlicher Bereinigungsschritt, nachdem eine Änderung am Code vorgenommen wurde. In diesem Fall gibt es nichts zu rechtfertigen. Refactoring ist einfach Teil des Prozesses der Arbeit am Projekt. Die Zeit wird für die Aufgabe abgerechnet, an der Sie beim Refactoring gearbeitet haben.

Wenn es nicht in kleinen Schritten gemacht wird, dann ist es nicht wirklich umgestalten, nicht wahr?

Alles gute Antworten hier - aber darf ich dem noch eine geschäftliche Dimension hinzufügen? Lass mich dich fragen, WARUM / SO-WAS? (Denk an deinen spitzen Haarboss (PHB) :)

PHB: warum?
Sie: Es macht die Reparatur einfacher
PHB: Na und?
Sie: Es erhöht den Durchsatz - wir bringen neue Gebäude schneller auf den Markt?
PHB: Na und?
Sie: Äh ... Glückliche Kunden?
PHB: WTF?
Sie: Ich meine erhöhte Empfehlungen, größere Zufriedenheit, 
     Mehr Gewinn früher durch geringen Turnaround
PHB: Oh! Klingt gut. Aber es "klingt" nur schön, kann ich es sehen?
Sie: WTF?
PHB: Zeig mir das Geld! (zB Zahlen bitte)
Sie: Oh! Brb ... (Schreiben Sie ein paar Zahlen in eine einfache Tabelle, um Ihren Fall zu klären)

Grundsätzlich müssen Sie ein Geschäftsmodell erstellen. Führen Sie einige Zahlen aus, um Ihren Denkprozess zu klären, und lassen Sie die Zahlen den "Nutzen" objektiv widerspiegeln. Sie werden auch wissen, wie viel Zeit es dauern wird, wie hoch die Kosten sind usw. Es sollte Sinn machen. Wenn es sich lohnt, bekommen Sie das grüne Signal und leiten vielleicht auch die Initiative :)

Wenn Sie denken, wie kann ich alles messen, probieren Sie dieses Buch

Refactoring muss wie jede andere Aktivität ein klares Ziel haben. Sobald dieses Ziel klar ist, würden Sie den aktuellen Projektstatus und den Lebenszyklus berücksichtigen. Bei einem Entwicklungsprojekt, das zu 80% abgeschlossen ist und 30% hinter dem Zeitplan zurückliegt, sollten Sie den Refactoring-Aufwand auf der Grundlage des zuvor festgelegten Ziels rechtfertigen. In diesem Beispiel ist es schwierig, das Refactoring zu rechtfertigen, wenn die Codeteile einem Komponententest unterzogen wurden und in einer Entwicklungsumgebung einwandfrei funktionieren.

Die Tatsache, dass 40 Entwickler übrig sind, mag nicht so dramatisch sein, wie es sich anhört. Ich würde erwarten, dass diese Entwickler Arbeitscode geliefert haben, der überprüft und getestet wurde. Sofern in diesem Code keine Probleme bekannt sind, lasse ich ihn unverändert. Die Idee ist, dass ich in einem großen Projekt wie Ihrem erwarten würde, dass es Standards und Verfahren gibt und dass der Code kein vollständiges Durcheinander ist.

Denken Sie daran, dass das Refactoring viele, wenn nicht alle Tests wiederholt werden. Da die Umgestaltung dieser Größe nicht von einem oder zwei hochrangigen Mitgliedern durchgeführt werden kann, kann die Umgestaltung zu Problemen führen, die nicht vorhanden waren. Dieses Risiko sollte nicht vernachlässigt werden.

Allerdings ist es nicht ungewöhnlich, einem Projekt Aufgaben hinzuzufügen, wenn das Unvorhergesehene eintritt. Wenn die Entwickler aus irgendeinem Grund verschwunden wären, wäre dies ein Ereignis besonderer Art und es müssten Maßnahmen ergriffen werden, um Abhilfe zu schaffen. Es würde wie ein Feuer oder ein Erdbeben usw. behandelt werden.

Zusammenfassend lässt sich sagen, dass ich großen Arbeitscode in einem großen Projekt nicht ohne soliden technischen Grund umgestalten würde, insbesondere weil wir alle wissen, dass sich die meisten Projekte normalerweise in einem späten Status befinden.

Stellen Sie sich vor, Sie stehen vor einer langen und riesigen Mauer. Sie müssen auf die andere Seite gehen.

Entweder baust du die Mauer um, um eine Tür zu bauen, oder du gehst um sie herum.

Schätzen Sie die Zeit für beide Lösungen ein und Sie erhalten eine Begründung für das Refactoring.

Vergessen Sie nicht, die Zeit in der zweiten Lösung mit der Anzahl der Personen zu multiplizieren, die auf die andere Seite der Wand gehen müssen.

Während ich in einer der anderen Antworten lese, esse ich diesen Elefanten beißweise. Ich bin an der Prüfung eines großen internationalen Projekts beteiligt, bei dem die Teammitglieder geografisch verteilt sind. Nach der Erstellung der ersten beiden Versionen der Software stimmte das Team darin überein, dass die Ansätze, der Codierungsstil und die Erstellung von Lösungen inkonsistent sind. Sie einigten sich darauf, neue Teile der Anwendung gemäß den neuen Regeln und Konventionen zu schreiben, und wenn (und nur dann) sie einen Teil des alten Codes ändern müssen, überarbeiten sie diesen zuerst, um der neuen Konvention zu entsprechen. Alles funktioniert ganz gut. Der Refactoring-Prozess ist fast in seinem fünften Monat, einige der Codes sind refactored, andere noch nicht. Neue Funktionen werden rechtzeitig eingeführt, Kunden sind glücklich, Entwickler sind glücklich, das QA-Team ist auch glücklich. Eine win-win Situation :)

Hauptziel des Refactorings ist es, die Dinge in Zukunft einfacher zu machen. Sie können keine Refactoring-Gewinne erzielen, wenn Sie nicht mehrere langfristige Projekte vergleichen, von denen nur wenige mit und nur wenige ohne ständiges Refactoring durchgeführt wurden. Entwickler sind sich einig, dass Refactoring die Kosten für die Wartung und Implementierung von Änderungen senkt, die sich jedoch aus geschäftlicher Sicht nur schwer nachweisen lassen. Der Hauptgrund für die Implementierung von Refactoring ist die Reduzierung der technischen Schulden .

Außerdem sollte das Refactoring ein kontinuierlicher Prozess sein und der Zeitaufwand für das Refactoring sollte in die eigentliche Entwicklungsaufgabe einbezogen werden. Eine spezielle "Refactoring-Aufgabe" ist keine gute Idee.