Wie kann ich das Refactoring zu einer Priorität für mein Team machen?

Die Codebasis, mit der ich täglich arbeite, hat keine automatisierten Tests, inkonsistente Benennungen und jede Menge Kommentare wie "Warum ist das hier?", "Nicht sicher, ob dies erforderlich ist" oder "Diese Methode ist nicht richtig benannt" und der Code ist übersät mit "Changelogs", obwohl wir die Quellcodeverwaltung verwenden. Es genügt zu sagen, dass unsere Codebasis ein Refactoring verwenden könnte.

Wir haben immer Aufgaben, um Fehler zu beheben oder neue Funktionen hinzuzufügen, sodass wir keine Zeit dafür haben, Code zu überarbeiten, um besser und modularer zu sein, und es scheint keine hohe Priorität zu haben.

Wie kann ich den Wert von Refactoring demonstrieren, sodass es zu unseren Aufgabenlisten hinzugefügt wird? Lohnt es sich, nur umzugestalten, anstatt um Erlaubnis um Vergebung zu bitten?

"Es ist besser, um Vergebung zu bitten als um Erlaubnis" ist wahr.

Warum sich darum sorgen? Refactor nur die schrecklichsten Teile.

Sie wissen schon, was die teuersten Fehler sind, oder?

Wenn dies nicht der Fall ist, besteht Schritt 1 darin, den teuersten, komplexesten, fehleranfälligsten und fehleranfälligsten Problemcode eindeutig und eindeutig zu definieren.

Identifizieren Sie die Anzahl der Trouble-Tickets, die Anzahl der Debugging-Stunden und andere sehr spezifische, sehr messbare Kosten .

Dann behebe etwas auf dieser Liste der kostspieligen Probleme.

Wenn Sie um Verzeihung bitten müssen, können Sie auf Kostensenkungen hinweisen.

Falls Sie nicht wissen, Refactoring erfordert Einheit Tests , dass das vor-und-nach Verhaltensweisen Spiel zu beweisen. Idealerweise sollte dies ein automatisierter, codierter Test sein, zum Beispiel ein Komponententest.

Dies bedeutet, dass Sie sich für eine Sache entscheiden müssen. Schreiben Sie einen Komponententest. Repariere das eine. Sie haben zwei Verbesserungen vorgenommen. (1) schrieb einen Test und (2) korrigierte den Code.

Iteriere.

Befolgen Sie die Pfadfinder-Regel: Verlassen Sie den Campingplatz (Code) etwas besser, als Sie ihn vorgefunden haben. Ich habe noch nie davon gehört, dass jemand geschrieben wurde, um kleine Code-Verbesserungen vorzunehmen, "während er dort war".

Ich werde einen vielleicht zu zynischen Standpunkt einnehmen.

Refactoring ist so schwer zu schlucken. Sie haben die Verantwortung und die Schuld, und die Früchte Ihrer Arbeit gehen oft an jemanden, der auf Ihrer sauberen Codebasis aufbaut.

Ich würde sagen, wenn solche Ingenieurspraktiken zu einer Kultur in Ihrem Unternehmen geworden sind, müssen Sie möglicherweise auf einer höheren Ebene kämpfen. Sie kämpfen nicht wirklich für die Umgestaltung, Sie kämpfen für herausragende technische Leistungen, und das ist die Art von Veränderung, die dem Management erst dann einfällt, wenn es ihnen ins Gesicht schlägt. In diesem Szenario werden sie wahrscheinlich nach einem Best-Practice-Zaren Ausschau halten, und all Ihre großartigen Ideen werden sowieso zusammengefasst.

Erwägen Sie, einem anderen Unternehmen beizutreten, in dem die Ingenieurspraxis ernst genommen wird.

Ich bemerke, dass viele der Plakate hier davon überzeugt zu sein scheinen, dass das Problem im Management - während die Frage das nicht erwähnt.

Ich würde noch weiter gehen: Meiner Meinung nach ist eine miese Codebasis so gut wie nie direkt am Management schuld. Das Management hat diesen Code nicht geschrieben, die Entwickler (es gibt einige Ausnahmen in meinem Unternehmen, in denen ein Teil unseres aktuellen Managements tatsächlich die ursprüngliche Codebasis geschrieben hat). Daher liegt das Kulturproblem bei den Entwicklern - wenn sie möchten, dass sich die Kultur ändert, müssen sie sich selbst ändern.

Ich versuche, diese Erkenntnis und Einstellungsänderung auch "meinen" Entwicklern zu vermitteln. Immer wenn sie mich fragen "Wann haben wir Zeit für eine Umgestaltung?", Reagiere ich überrascht und antworte "Sie sollten schon die ganze Zeit umgestalten!". Ich glaube, Sie können eine Codebasis nur in dreifacher Hinsicht erhalten:

1. Fügen Sie immer nur fehlerfreien Code hinzu.
2. Korrigieren Sie nicht so fehlerfreien Code immer, sobald Sie ihn sehen.
3. Wenn Sie aus Fristengründen 1 oder 2 nicht ausführen können, haben Sie immer eine Liste mit Problemen, die sofort nach Ablauf der Frist behoben werden müssen, und akzeptieren Sie keine Entschuldigungen, wenn Sie diese Liste nach Ablauf der Frist nicht mehr durcharbeiten.

Ausnahmslos lautet die nächste Bemerkung der Entwickler: "Aber wie bekommen wir Zeit dafür - wir haben jetzt keine Zeit?". Die einzig richtige Antwort (wieder IMHO) lautet: "Sie haben nicht die Zeit, dies NICHT zu tun." Wenn Sie die Codebasis nicht in Ordnung halten, werden die Bearbeitungszeiten immer länger, die Zeitpläne unvorhersehbarer, die Fehler immer unangenehmer und der Wert immer geringer.

Die größte Einstellungsänderung, die Sie im Entwicklungsteam vornehmen müssen, ist, dass "Qualität" nicht zu einem bestimmten Zeitpunkt ("wenn wir Zeit zum Umgestalten haben") durchgeführt wird, sondern dass Sie dies die ganze Zeit tun müssen.

Zum Schluss eine Geschichte der Warnung. Wenn gedrückt, werde ich leugnen, dass dies jemals passiert ist. In einem Unternehmen, für das ich gearbeitet habe, gab es eine langjährige Anwendung mit einer großen, älteren Codebasis, die vor über 10 Jahren erstellt wurde. Viele Entwickler, darunter auch ich, waren der Meinung, dass diese alte Codebasis schlecht oder zumindest veraltet und nicht auf dem neuesten Stand ist. Also haben wir uns erfolgreich für ein großes Refactoring-Projekt eingesetzt und das Rewrite-Projekt gestartet, nach dem wir geglaubt haben, dass alles besser werden würde.
Wir haben lange und hart daran gearbeitet, fast alles auf eine neue und moderne Weise zu implementieren, indem wir neue Bibliotheken und neue Sprachfunktionen verwendet haben. Gegen Ende haben wir uns sehr bemüht, alles zusammenzubringen, um ein neues Release der langjährigen Anwendung mit der neuen und verbesserten Codebasis zu ermöglichen.
Wie erwartet hatte die neue Version einige Startschwierigkeiten aufgrund der neuen Bibliotheken, mit denen wir noch nicht so vertraut waren, und einiger Interaktionen in unserem Code, die wir nicht vorausgesehen hatten. Wir haben es jedoch endlich geschafft, die Veröffentlichung auf den gleichen Standard wie unsere vorherigen Veröffentlichungen zu bringen. Wir atmeten erleichtert über unseren "Erfolg" auf. Dann wandte sich eine Untergruppe von Entwicklern wieder an das Management und bat um ein neues Refactoring-Projekt, da unser neuer Code nicht ganz die Silberkugel war, die sie erwartet hatten, und sie sahen einige Möglichkeiten, einige Dinge komplett neu zu schreiben ...

Moral der Geschichte: Oft sind die Dinge nicht annähernd so kaputt, wie sie scheinen, und 'von vorne anfangen' bedeutet normalerweise, dass Sie eine bekannte Reihe von Problemen mit einer zumindest so haarigen unbekannten Reihe von Problemen tauschen. Refactor ein Teil nach dem anderen!

Jemand hat mir einmal gesagt, wenn ich zu einem Vorstellungsgespräch gehe, darf ich nicht vergessen, dass ich auch das Unternehmen interviewe. Ist es ein Ort, an dem ich arbeiten möchte? Führen sie Codeprüfungen durch? Haben sie automatisierte Integrationstests? Unit-Tests? Was halten sie von Pair Programming? Persönlich würde ich einen anderen Job finden und diesmal auch einige Fragen stellen.

Finden Sie ehrlich gesagt eine andere Firma. Derartige Verbesserungen des Entwicklungsprozesses erfordern große kulturelle Sprünge, die erhebliche Zeit in Anspruch nehmen, bis alle auf der gleichen Seite sind und Sie sich dann weniger darum kümmern.

Wenn Sie das Gefühl haben, immer noch einen Kampf in sich zu haben und noch nicht untergegangen zu sein, dann versuchen Sie es noch einmal. Versuchen Sie, von gleichgesinnten Teammitgliedern so viel Unterstützung wie möglich zu erhalten, Ihre Erschöpfung den Vorgesetzten mitzuteilen, die sich um Ihr Wohlergehen kümmern, und alle zu umgehen und zu distanzieren, die sich möglicherweise Ihren Überzeugungen widersetzen Projekte / Funktionen.

Wenn Sie eine Leidenschaft für das haben, was Sie tun und sich für Ihr Unternehmen interessieren, wäre dies eine lobenswerte Anstrengung für Sie. Wenn es nicht geschätzt wird, dann respektiere dich selbst und steige aus, bevor du dich in einen hohlen Programmierer verwandelst.

Wenn ich eine Übung einführen müsste, um die Dinge in einem solchen Kontext besser zu machen, dann wäre das eine Codeüberprüfung. Code Reviews sind

• Im Allgemeinen wird es von Entwicklern intuitiv als Faktor für besseren Code, weniger Fehler usw. akzeptiert.
• kollaborativ und demokratisch
• nicht zu zeitaufwändig, wenn Sie sie richtig timeboxen
• Ein guter Ort zum Refactoring, wenn Sie während der "normalen" Entwicklung keine Zeit dazu haben
• ein ziemlich effektives trojanisches Pferd, um schrittweise alle Arten von Best Practices in Bezug auf Code-Design, Unit-Tests einzuführen ...

Sie müssen Codeüberprüfungen nicht systematisch durchführen, nur wenn Sie zuerst große / komplexe Codeteile festschreiben.

Wenn Sie der Meinung sind, dass Sie eine offizielle Bestätigung benötigen, bevor Sie Codeüberprüfungen einführen, müssen Sie Ihren Chef möglicherweise zuerst davon überzeugen, dass die Codebasis wahrscheinlich zusammenbrechen wird, wenn die Dinge so bleiben, wie sie sind.

Hier ist, was ich in solchen Situationen mache (in den 15 Jahren meiner Karriere als Entwickler bin ich fast täglich auf solchen Code gestoßen)

1. Mit gutem Beispiel vorangehen - Ich achte darauf, den von mir berührten Code neu zu faktorisieren. Ich lösche rücksichtslos alten auskommentierten Code und große Absätze von Kommentaren.
2. Bitten Sie mich, jedes Mal, wenn ich gebeten werde, eine Codeänderung zu überprüfen, ohne die ich die Codeüberprüfung nicht genehmige, um eine Neufaktorisierung.
3. Langsam sehen die Leute die Veränderung, wenn der Code schlanker, lesbarer und dadurch weniger fehlerbehaftet wird. Es braucht Zeit, aber langsam schätzt und übernimmt das gesamte Team die Praxis.

Das Management nimmt sich nie Zeit für die Umgestaltung von Code (es hat nie genug Ressourcen!). Daher ist es ein richtiger Ansatz, langsam und stetig vorzugehen.

Lassen Sie das Management zu "technischen Schulden" recherchieren. Verweisen Sie auch auf die "Broken Window Theory". Beide Effekte wirken sich direkt auf Effizienz, Qualität und Moral aus.

"Eine saubere Baustelle ist eine sichere und produktive Baustelle", und jeder Beitrag zu einem Durcheinander setzt das Durcheinander auf exponentielle Weise zusammen, nicht auf lineare Weise.

Wenn die Situation nicht gelöst wird, werden Sie irgendwann einen Punkt ohne Wiederkehr überschreiten, an dem es wirtschaftlich nicht mehr machbar ist, indem Sie schrittweise damit umgehen, bevor dies eintritt. Die Vorteile erholen sich und geben Ihnen mehr Treibstoff, um das Problem im Laufe der Zeit zu lösen.

Es hört sich so an, als wären Ihre Probleme allgemeiner.
Das Refactoring-Problem ist sowohl ein Symptom als auch eine potenzielle Linderung eines Teils des Problems.

Der Software-Leiter und das Team teilen die Zeit des Teams ein

Aus meiner Erfahrung denke ich, dass Sie auf ein Problem stoßen, das ich "Jeder ist ein Software-Manager" nenne. Produktmanager, Projektmanager und manchmal Systemingenieure und Tester können dafür berüchtigt sein, Entwickler, die wahrscheinlich bereits einen erfahrenen Software-Manager haben, mit Mikromanagement zu beauftragen. Möglicherweise haben Sie sogar ein paar Mitglieder in Ihrem Team, die glauben, dass es ihre Aufgabe ist, das Management zu übernehmen.

Wenn Sie der Software-Manager sind, nehmen Sie Aufträge für das gewünschte Refactoring vor oder lassen Sie sich von Ihrem Team das Refactoring zur Genehmigung vorschlagen. Um keine Mikromanage durchzuführen, müssen möglicherweise Richtlinien zu Alter / Autor / Größe / Kontext des Codes überarbeitet werden, die frei überarbeitet werden können, anstatt dass eine Genehmigung erforderlich ist. Wenn ein Mitglied Ihres Teams vier große Klassen komplexer alter Codes, die er nicht geschrieben hat und die nicht zu seinem Feature gehören, massiv überarbeiten möchte, ist seine zweiwöchige Umleitung Ihr Problem. Sie müssen also die Chance haben, Nein zu sagen.

Sie können herumschleichen, aber ich denke, es ist besser, Ihre Schätzungen sorgfältig mit der Zeit für Analyse, Design, Codierung, verschiedene Testformen (zumindest Einheit und Integration), Refactoring und Risiko zu erstellen Erfahrung oder Klarheit im Zusammenhang mit der Aufgabe. Wenn Sie zu offen über die Arbeitsweise Ihres Teams waren (oder wenn Mitglieder in Ihrem Team sind), ist es möglicherweise ratsam, die Kommunikationskanäle so einzuschränken, dass sie Sie durchgehen und Ressourcen und Ergebnisse diskutieren, nicht Methoden.

Frühe Projektentscheidungen Erstellen Sie einen Teufelskreis für das Refactoring

Die Software-Wartung ist schwierig. Es ist doppelt schwer, wenn andere in der Organisation Entscheidungen auf Ihre Kosten treffen. Das ist falsch, aber es ist nicht neu. Es wurde von Barry Boehm angesprochen, einem unserer großartigen Software-Autoren, der ein Management-Modell vorschlägt, das er als Theorie W bezeichnet.

http://csse.usc.edu/csse/TECHRPTS/1989/usccse89-500/usccse89-500.pdf

Oft werden Softwareentwickler gezwungen, nach dem Theory-X-Management-Ansatz zu produzieren, der besagt, dass Mitarbeiter im Grunde genommen faul sind und nur dann Leistung erbringen, wenn sie zur Einreichung gezwungen werden. Boehm fasst sein vorgeschlagenes Modell wie folgt zusammen und kontrastiert es:

"Anstatt einen Manager als Autokraten (Theorie X), als Coach (Theorie Y) oder als Moderator (Theorie Z) zu charakterisieren, charakterisiert Theorie W die primäre Rolle eines Managers als Verhandlungsführer zwischen seinen verschiedenen Wahlkreisen und als Paketierer von Projektlösungen mit Gewinnbedingungen für alle Parteien. Darüber hinaus ist der Manager auch ein Zielsetzer, ein Monitor des Fortschritts in Richtung Ziele und ein Aktivist bei der Suche nach alltäglichen Gewinn-Verlust- oder Verlust-Verlust-Projektkonflikten, mit denen er konfrontiert wird. und sie in Win-Win-Situationen zu verwandeln. "

Schnell und dreckig ist oft nur dreckig

Boehm führt weiter aus, warum es Entwicklern im Wartungsteam so schlecht geht.

"Ein schnelles und schlampiges Produkt zu bauen, mag für den Softwareentwickler und den Kunden ein kostengünstiger, kurzfristiger" Gewinn "sein, aber es wird für den Benutzer und den Betreuer ein" Verlust "sein." Bitte beachten Sie, dass der Kunde in Böhms Modell eher ein Vertragsadministrator als ein Endbenutzer ist. Stellen Sie sich den Produktmanager in den meisten Unternehmen als Ersatz für den Kunden vor, oder vielleicht als die Person, die das Produkt für seine Featureliste kauft.

Meine Lösung wäre, das ursprüngliche Entwicklungsteam (oder zumindest den ursprünglichen Lead) erst freizugeben, wenn der Code überarbeitet wurde, um zumindest die Codierungsstandards zu erfüllen.

Für den Kunden halte ich es für vernünftig, den Produktmanager als Ersatz für den Kunden zu betrachten, und die Gruppe von Personen, die für die schnelle und schmutzige Lieferung belohnt wird, kann durchaus erweitert werden.

Refactoring ist nicht verhandelbar

Bitte geben Sie Ihre Rolle als Software-Manager nicht auf. Sie sollten die Autorität und Diskretion haben, die Zeit Ihres Teams für Prozess- und Produktverbesserungen zu nutzen. In dieser Rolle müssen Sie möglicherweise Ihre Entscheidungen aushandeln, um Ihr Team professioneller zu machen. Bezüglich des Prozesses sollten Sie jedoch nicht mit dem Marketing verhandeln, da dies meiner Erfahrung nach ein Verlustspiel ist. Verhandeln Sie mit dem Engineering Management. Es zeigt, dass Sie eine Vision haben. Der Aufbau eines professionellen Softwareteams ist eine Erweiterung ihrer Rolle und wird eher als eine Win-Win-Situation angesehen.

Man konnte es immer nur abwarten. Irgendwann wird das Team genug Fristen verpassen und Software produzieren, die fehlerfrei genug ist, damit das Management seine Hände in die Luft wirft und sagt, dass sich bei Gott etwas Besseres geändert hat!

Okay, das ist ein riskantes Unterfangen. Aber genau das geschah vor einigen Jahren in unserem Geschäft (ein Teil der Schwierigkeit bestand darin, mit dem Management über Fristen zu kommunizieren , aber das ist eine andere Geschichte). die Freiheit der Umgestaltung, die Bereitschaft, toten Code zu löschen, und die qualitativ hochwertigsten Veröffentlichungen, die wir je hatten.

Am erstaunlichsten ist vielleicht, dass niemand seinen Job verloren hat - etwas, das ich unserem Chef zu verdanken habe, der gekommen ist, um für uns zu kämpfen, und einem Berater, der sich für eine Umgestaltung und kontinuierliche Integration in unserem Namen aussprach. Es klingt immer überzeugender, wenn es jemand von außen sagt.

Ich denke, die Antwort darauf, wie man Zeit findet, hängt davon ab, warum Sie Code umgestalten möchten.

Wenn es funktioniert, ist kein spezieller Refactor erforderlich, und Sie können dies tun, wenn Sie diesen Teil des Codes berühren. Dafür braucht man keine besondere Zeit.

Wenn es Ihre Teamentwicklung verlangsamt, müssen Sie mit dem Teamleiter darüber sprechen und eine spezielle Aufgabe für das Refactoring erstellen, damit Sie Zeit haben.

Gleiches gilt für die Laufgeschwindigkeit und andere Fälle, in denen Refactor nicht nur das "gute Aussehen" des Codes oder Ihre Meinung dazu verbessern kann, wie Code aussehen und echten Nutzen bringen sollte, Aufgaben erstellen oder mit jemandem sprechen kann, der dafür verantwortlich ist.

Ich habe ein bisschen darüber gelacht, wie Sie die Dinge beschrieben haben, denn das klingt ziemlich ähnlich wie die Codebasis, an der ich arbeite, und ich denke, dass unsere Situationen ziemlich ähnlich sind. Zum Glück habe ich in meiner Situation einen vorausschauenden Manager, der entschieden hat, dass die Codebasis am besten durch Modularisierung mithilfe eines modernen Webentwicklungsframeworks verbessert werden kann, anstatt nur die gesamte Codebasis zu überarbeiten. Auf diese Weise können die störenden Stellen der Hauptanwendung als separate Module neu geschrieben und dann in die Hauptanwendung integriert werden (sie sind jedoch im Wesentlichen unabhängig). Dies ist möglicherweise ein Ansatz, den Sie ansprechen möchten, da nicht die gesamte (vermutlich große?) Codebasis, mit der Sie arbeiten, überarbeitet werden müsste.

Natürlich kann es sein, dass ich etwas von dem abweiche, was Sie sagen, da Ihre Codebasis möglicherweise nicht so schlecht ist wie die, mit der ich arbeite. In diesem Fall würde ich sagen, warum Sie keine kleinen Optimierungen vornehmen, während Sie fortfahren. Die Entwickler in meinem Team haben kein Problem damit, dumme oder veraltete Kommentare und Dinge dieser Art zu entfernen, und ich denke nicht, dass dies etwas ist, das Eingaben vom Management erfordern sollte, da Entwickler normalerweise die Befugnis erhalten, Dinge nach Bedarf zu optimieren.

Wenn die Codebasis wirklich zerbrechlich ist, müssen Sie vorsichtig sein, und aus diesem Grund möchten sie möglicherweise keine größeren Umgestaltungen vornehmen, da dies zu einem monatelangen Projekt werden kann und wahrscheinlich die Verzweigung eines Projekts und das Anlegen von Entwicklern erforderlich machen würde Projektieren und Entfernen von anderen Entwicklungsaufgaben, z. B. sofortige Fehlerkorrekturen, die dazu führen können, dass Kunden verloren gehen, usw

Alles in allem hängt es davon ab, wie das Management die Dinge sieht. Wenn sie die Situation verstehen und erkennen, warum manche Dinge länger dauern können, als sie optimal sollten, können die Dinge in Ordnung sein Was das Arbeitsumfeld angeht, kann dies mit der Zeit nachteilig werden, wenn Sie ständig über einen Arbeitsstau belästigt werden. Ich habe das Glück, ein Management zu haben, das im Grunde erkennt, dass die Anwendung ein Miststück ist, aber viele Kunden hat und Geld einbringt. Es ist also immer noch wertvoll und es lohnt sich, Fehler zu beheben, auch wenn dies nur für kurze Zeit gilt .

Ihr Hauptproblem ist, dass die Codes nicht ausreichend sichtbar sind.

Ich schlage vor, ein kontinuierliches Integrationstool wie Jenkins und ein darin integriertes statisches Code-Analyse-Tool zu verwenden, das die zyklomatische Komplexität, Namensstandards, Codelänge usw. misst.

Wenn ein Programmierer eine Änderung festlegt, führt Jenkins die Einheitentests durch, führt das statische Code-Analysetool darauf aus und generiert einen Webbericht, den jeder sehen kann, mit einem ampelähnlichen Farbstatus.

Wenn die Codequalität für alle sichtbar ist (insbesondere für den Teamlider und den Chef) und die Versionskontrolle und Unit-Tests zur Verfügung stehen, fühlen sich die Leute zur Umgestaltung ermutigt.

Der Code kam auf diese Weise langsam über viele kleine Änderungen hinweg. Es muss auch so behoben werden.

Sie können dies zunächst nach und nach tun. Erhöhen Sie alle Schätzungen um 10%, um Code-Verbesserungen und langfristige Wartungsarbeiten zu ermöglichen. Wenn sich jemand beschwert, fragen Sie sie, ob es besser ist, das Öl in einem Automotor jede Woche zu überprüfen oder zu warten, bis der Motor vollständig zum Stillstand gekommen ist.

Treffen Sie sich und bestimmen Sie einheitliche Kodierungsstandards.

Führen Sie grundlegende Regeln ein, die Sie auf Ihrem Weg anwenden sollten:

Immer wenn ein neuer Code in eine Klasse eingeführt wird, müssen automatisierte Tests geschrieben werden, um zu beweisen, dass die Klasse funktioniert (nicht nur der neue Code).

Wenn ein Fehler behoben ist, müssen automatisierte Tests geschrieben werden, um zu beweisen, dass die Klasse funktioniert (nicht nur der feste Code).

Wenn ein Programmierer eine Datei ändert, muss er alle Compiler-Warnungen in dieser Datei korrigieren und den Code aktualisieren, damit er den neuen Codierungsstandards entspricht.

Nach einer Weile ist der am häufigsten verwendete Code auf dem neuesten Stand und wird durch automatisierte Tests abgedeckt. Der ältere Code wird aktualisiert, wenn er geändert wird. Wenn er nie geändert wird, müssen Sie sich darüber keine Gedanken machen.

Das Wichtigste ist, diese Gewohnheiten in die Standard-Codierungsaufgaben zu integrieren, damit keiner von ihnen viel Zeit für die „echte“ Arbeit in Anspruch nimmt, aber alle bieten echte Vorteile. Versuchen Sie nicht, aus der Überarbeitung von altem Code ein Projekt zu machen, es ist ein schrecklicher, langweiliger, fummeliger Schmerz, der aussieht, als würde viel Zeit an Nicht-Technik verschwendet werden!

Der Weg, um die Ressourcen (Zeit) zu erhalten, die Sie benötigen, besteht darin, sich darauf zu konzentrieren, Fähigkeiten und Wünsche in Einklang zu bringen. Ihr Chef wird von Zielen bestimmt (in der Regel Gewinne oder Lieferzeiten für neue Funktionen) und sieht Refactoring als Verschwendung von Zeit durch Ingenieure und das Einhalten dieser Ziele. Sie müssen einen Weg finden, ihn davon zu überzeugen, dass die Ziele erreicht und übertroffen werden, wenn Sie Zeit für die Umgestaltung aufwenden.

Der erste Schritt ist also herauszufinden, welchen Schmerz Ihr Chef empfindet. Identifizieren Sie, was seine größten Probleme sind. Erarbeiten Sie dann, wie sich das, was Sie tun möchten, an der Behebung seiner Probleme ausrichtet, und präsentieren Sie ein starkes Geschäftsmodell dafür. Verwenden Sie Fehlerverfolgungs- und Projektierungssysteme (Zeitüberschreitungen), um nachzuweisen, wo Probleme liegen. Sie brauchen Fakten, keine Gefühle. Ohne Metriken (Anzahl der Fehler / Modul, Kosten für die Behebung dieser) ist das Refactoring nur ein Programmierer, der ein Spiel auf Kosten anderer hat. Ihr Chef wird Ihnen nur dann die erforderlichen Ressourcen zur Verfügung stellen, wenn Sie ein starkes Geschäftsmodell dafür vorweisen können.

Mist-Code ist in der Regel zu teuer, um ihn zu reparieren. Ohne automatisierte Regressionstests sind die Kosten für das Testen von überarbeitetem Code extrem hoch.

Die meisten Male, in denen ich fehlerhaften Code gesehen habe, der dringend überarbeitet werden muss, gab es eine große Anzahl von undokumentierten Funktionen und eine große Komplexität der Anforderungen, die von Anfang an nicht verstanden werden können. Es ist keine Kleinigkeit, und meiner Erfahrung nach ist es um ein Vielfaches schwieriger, die Kosten eines Refactoring-Auftrags abzuschätzen, als ein neues Feature hinzuzufügen.

Ich würde nicht weitermachen und es hinter deinen Chefs zurück tun (Wenn es nicht kaputt war und du es kaputt gemacht hast, wie sieht das aus) - Code reparieren, der sowieso geändert werden muss, aber wenn es nicht kaputt ist, dann es nicht reparieren.

Seltsamerweise erwähnt niemand dies:

Machen Sie es sich einfach, damit die Dinge Priorität haben: Holen Sie sich ein gutes Refactoring-Tool.

Es gibt hervorragende Refactoring-Tools (zumindest für .NET afaik). Oh, und vergessen Sie nicht, vorher Komponententests zu schreiben (wie andere bereits betont haben).

Viel Glück!