Wenn ein umschreiben einer code-Basis von Grund auf
Ich denke zurück an Joel Spolsky ' s Artikel über nie umschreiben von code von Grund auf neu. Zusammenfassend sein argument: Der code nicht rostig, und während es vielleicht nicht hübsch Aussehen, nach vielen releases, wenn es funktioniert, es funktioniert. Der Endbenutzer ist nicht egal, wie schön der code ist.
Können Sie den Artikel hier Lesen: Dinge, Die Sie Nie Tun Sollten
Ich habe vor kurzem übernommen, ein Projekt, und nach einem Blick durch Ihren code, es ist ziemlich schrecklich. Ich dachte sofort an Prototypen, die ich gebaut hatte, bevor, und ausdrücklich erklärt, dass es nicht für jede Produktionsumgebung. Aber natürlich, die Menschen nicht hören.
Code ist aufgebaut wie eine website, ist keine Trennung, keine unit-Tests und code-Duplizierung überall. Keine Daten-layer, keine wirkliche business-Logik, es sei denn, Sie zählen eine Reihe von Klassen im App_Code.
Ich habe die Empfehlung an die Aktionäre, dass, während wir sollten halten Sie den vorhandenen code, und tun bug-fix-releases, und einige kleinere feature-releases, wir beginnen sollten, schreiben Sie es sofort mit Test-Driven Development im Geist und mit der klaren Trennung von Bedenken. Ich bin am überlegen zu gehen ASP.NET MVC-route.
Meine einzige Sorge ist natürlich, die Länge der Zeit, die es dauern könnte zu umschreiben, von Grund auf. Es ist nicht ganz komplizierte, ziemlich Lauf von der Mühle-web-Anwendung, mit der Mitgliedschaft, etc..
Haben alle von Ihnen verfügen über ein ähnliches problem? Irgendwelche besonderen Schritte Sie genommen haben?
UPDATE:
Also.. Was habe ich am Ende der Entscheidung zu tun? Nahm ich Matt ' s Ansatz und beschlossen, umgestalten vielen Bereichen.
- Seit App_Code war immer ziemlich
große und dadurch verlangsamt sich das bauen
Zeit, die ich entfernt viele der Klassen
und konvertiert Sie in eine Klasse
Bibliothek. -
Ich erstellte eine sehr einfache Daten-Zugriff
Schicht, die enthielt alle ADO
Anrufe und erstellt ein Objekt SqlHelper
zur Ausführung dieser Anrufe. -
Implementiert habe ich eine cleaner-Protokollierung
Lösung, die sehr viel präziser.
Während ich nicht mehr an diesem Projekt arbeiten [Finanzierung, Politik, bla bla], ich denke, es gab mir einen enormen Einblick, wie schlecht einige Projekte geschrieben werden können, und Schritte, die ein Entwickler nehmen können, um Dinge zu machen, viel sauberer, lesbarer und nur flat out besser mit kleinen Schritten über die Zeit.
- ein weiterer Schraubenschlüssel in den Werken, Plattform - / stack-änderungen
- Sie haben bereits festgestellt, dass der code ist ziemlich schrecklich. Anstatt zu versuchen, zu korrigieren, einen code, der im sterben liegt, wäre es besser, den code neu schreiben. Wenn Sie gelesen haben das Buch "the Apple Way" von Jeffrey L. Cruikshank", es sagt "Wenn du nicht enthüllen, dann Dribbeln" Gleiches könnte gelten für den älteren code, bis Sie enthüllen den neuen code, Dribbeln den alten code.
- Es ist nicht immer unangemessen umschreiben von Grund auf. Es kann es Wert sein, wenn der alte code hat definitiv keinen Wert. Funktionierenden code hat einen Wert, und sollten nicht von Grund auf neu geschrieben. Aber wenn Sie reden über ein Projekt, das nie gearbeitet hat, ist es möglich, dass das umschreiben könnte eine bessere Idee, als zu versuchen, um Sie zu retten. Selbst dann, sollten Sie sehen, ob irgendwelche Teile des alten Projekts haben Wert und können herausgehoben werden und verwendet werden.
- Schätzen Sie die Umsetzung dieses zusammen und detailliert Sie Ihren plan des Angriffs. Ich befinde mich in der GENAU GLEICHEN situation. Und ich werde deinen Ansatz, um die zugrunde liegenden änderungen in der Architektur, ohne dabei eine komplette Neuentwicklung
Du musst angemeldet sein, um einen Kommentar abzugeben.
Nur, weil es alle diese Probleme jetzt bedeutet nicht, es muss weiter um Sie zu haben. Wenn Sie finden, sich selbst einen konkreten bug-fix in das system, die davon profitieren könnten, sagen, Sie eine neue Daten-Schicht, erstellen Sie eine neue Daten-Schicht. Nur weil die ganze Website nicht verwenden, es bedeutet nicht, Sie können nicht starten mit einer. Umgestalten, wie Sie benötigen, um während Ihres bug-fixes. Und stellen Sie sicher, dass Sie genau verstehen, was der code tut, bevor Sie es ändern.
Problem mit code-Duplizierung? Ziehen Sie es heraus in einer Klasse oder utility-Bibliothek, in zentraler Lage, neben der Zeit, die Sie haben, um einen Fehler zu beheben in der duplizierten code.
Und, wie bereits erwähnt von anderen-Responder - start schreiben von tests nun. Es kann schwierig sein, wenn der code ist gekoppelt, wie es klingt, aber man kann wohl irgendwo anfangen.
Gibt es keinen guten Grund, neu zu schreiben, funktionierenden code. Allerdings, wenn Sie bereits einen Fehler zu beseitigen, es gibt keinen Grund Sie können nicht Nacharbeiten, die einen spezifischen Teil des Codes mit einem "besseren" design.
Joel ' s Artikel sagt eigentlich alles.
Grundsätzlich nie.
Als Joel Punkte aus: Sie werden einfach zu viel zu verlieren, es zu tun, von Grund auf. Es wird wahrscheinlich viel länger als du denkst, und was ist das Ergebnis? Etwas, dass im Grunde genommen die gleiche Sache. Also, was ist die business case, es auch zu tun?
Das ist ein wichtiger Punkt: es kostet Geld, etwas zu schreiben, von Grund auf. Wie werden Sie schöpfen das Geld? Viele Programmierer ignorieren Sie diesen Punkt einfach, weil Sie nicht wie die code-manchmal begründet, manchmal nicht.
Buch Fakten und Irrtümer Des Software-Engineering Staaten diese Tatsache:
"Veränderung des wiederverwendeten Codes ist besonders fehleranfällig. Wenn mehr als 20 bis 25 Prozent eines Bauteils ist, um revidiert zu werden, ist es effizienter und effektiver, neu zu schreiben."
Die zahlen kommen vom statistischen Studien über das Thema. Ich denke, die zahlen variieren aufgrund der Qualität der code-Basis, also in deinem Fall, scheint es zu mehr Effizienz und Effektivität neu zu schreiben, indem man die Aussage berücksichtigt.
Habe ich so eine Anwendung, und schreiben, war sehr lohnend. Allerdings sollten Sie versuchen zu aviod die "Verbesserung" Falle.
Beim umschreiben alles, es ist sehr verlockend, um neue Funktionen hinzuzufügen und zu beheben einige langjährige Probleme, die Sie hat nicht den Mut haben, Sie zu berühren. Dies kann dazu führen, feature creep und verlängern auch die Zeit die benötigt wird, umschreiben enorm.
Stellen Sie sicher, Sie entscheiden, was genau geändert wird und was nur umgeschrieben werden - im Voraus.
Ich bin nicht einverstanden mit diesem Artikel etwas. Für die meisten Teil Joel ist richtig, aber es gibt Gegenbeispiele, die zeigen, manchmal (wenn auch selten) ein umschreiben ist eine gute Idee. E. g.,
Glaube ich, dass Joel ' s argument basiert vor allem auf relativ gut geschriebenen code in der vorhandenen version, die verbessert werden könnten rückblickend. Mit allen Mitteln, wenn der code, den Sie geerbt ist wirklich schlecht, push für einen rewrite--da gibt es einige scary stuff gibt. Wenn es überhaupt erträglich und funktioniert auch Recht gut, die phase, in der neue Sachen, die in einem langsameren Tempo.
Wurde ich Teil eines kleinen, engagierten team, dass hat umgeschrieben code von Grund auf neu, einschließlich reverse-engineering von business-Regeln der frühere code. Die ursprüngliche Anwendung war web service in C++ geschrieben (mit regelmäßigen Abstürzen und schweren Speicher-Lecks) und eine ASP.Net 1.0-web-application und der Ersatz war in einer C# 2.0 asmx-basierten web-service und ein ASP.Net 2.0 web-Anwendung mit Ajax. Das sagte, einige der Dinge, die das team hat und erklärt, management
Das Projekt war sehr erfolgreich. Es war sehr stabil und viel besser durchführen. Später wurde es einfacher neue Funktionen hinzuzufügen.
Also ich glaube, dass code umschreiben kann erfolgreich durchgeführt werden, gegeben richtigen Ressourcen und Umstände.
Nur eine quasi-legitimen Grund in den Sinn kommt: Politik.
Ich habe zum umschreiben einer Codebasis aus dem nichts, und es hatte zu tun mit der Politik. Im Grunde, wird der Vorherige Programmierer, dem es gelang, die Codebasis wurde auch peinlich um zu release den source-code von dem neuen team, der gerade eingestellt worden. Sie fühlte, dass jede Kritik der code war eine Kritik an Ihr als person, und als ein Ergebnis, werden Sie nur veröffentlicht code, um den rest von uns, wenn Sie gezwungen wurde. Sie ist die einzige person, die mit den administrativen Zugriff auf das Quell-repository, und wenn Sie wurden gebeten, die Freigabe alle der Quelle, die Sie bedroht, zu beenden, und nehmen Sie all Ihr wissen über den code und nach Hause gehen.
Diese Codebasis ist über 15 Jahre alt, und hat Windungen und Verrenkungen von verschiedenen Menschen mit verschiedenen Stilen. Keiner dieser Stile offenbar Kommentare oder Spezifikationen, zumindest in den kleinen Portionen ist Sie uns freigegeben.
Nur teilweise-code zur Verfügung und einer Frist, war ich gezwungen zu tun, insgesamt umschreiben. Ich habe angeschrien, als ein Ergebnis, denn es wurde behauptet, dass ich verursacht eine starke Verzögerung, aber ich hielt meinen Kopf nach unten und bekam es auch getan, anstatt zu argumentieren.
Politik kann eine große Schmerzen.
Habe ich in genau dieser situation, sondern eher als eine Summe umschreiben, ich arbeitete, um Dinge zu ändern, die durch ein refactoring-Prozess. Das problem habe ich begegnete, war die enorme Komplexität des Codes arbeite ich mit - vielen-Seiten von schrecklichen, Spezial-case-driven development basierend auf wenn-Fälle und verworrene regexes geschichteten zurück auf über zehn Jahre ungeplante Wachstum und expansion.
Mein Ziel war es Refactor-Funktion durch die Funktion so, dass es die gleiche Ausgabe für die gleiche Eingänge, sondern arbeiten viel mehr sauber und glatt unter der Motorhaube erleichtern das künftige Wachstum und die Leistung zu verbessern. Die Allgemeine Lösung war sauber und schnell, aber die Befestigung job auf die code just got mehr und mehr schwierig und kompliziert, wie obskure special-Fällen in die Dokumente werden analysiert, indem das system begann, sich zu zeigen und meine schönen, sauberen code erzeugen würde-Ausgabe, die war nur ein wenig zu anders als das, was das original getan hat ( das war Seiten, so dass eine unterschiedliche Anzahl von Leerzeichen bewirken, dass alle Arten von layout-Probleme auf älteren IE-Versionen ) in kleinen und obskuren Wege.
Ich weiß nicht, ob der überarbeitete code schon mal verwendet - ich verließ das Unternehmen, bevor es die chance hatte, völlig integriert zu werden - aber ich bezweifle es. Warum zwanzig Zeilen code, wenn fünfzehn hundert 'wenn' Aussagen und drei-Linie reguläre Ausdrücke könnte die gleiche Arbeit?
Einer Gefahr in eine komplette Neuentwicklung ist, dass Ihr job ist, ständig auf der Linie. Sie sind Kosten, die nicht einen Beitrag zu der unteren Zeile. Der code nervt ist der code, der macht das Geld.
Aber wenn Sie fixieren Sie den vorhandenen code ein Stück zu einer Zeit, du bist der Mann, der weiß, wie die Geldmaschine funktioniert.
Meine Antwort ist: rewrite from scratch so oft wie möglich.
Ich habe die meisten meiner Karriere Erben dampfende Haufen Mist wir höflich als "Programme", geschrieben von Jungen, unerfahrenen Programmierern waren als "rock-stars" von den Managern. Diese Dinge sind in der Regel unlösbaren, und Sie am Ende verbringen Sie 10 mal so viel Aufwand zu halten, Sie humpelnd, als würden Sie damit verbracht haben, nur umschreiben Sie von Grund auf.
Aber ich habe auch profitiert enorm durch umschreiben meine eigenen Arbeit in regelmäßigen Abständen. Jeder rewrite ist eine chance, Dinge anders zu machen und möglicherweise bessere, und Sie sollten in der Lage sein, um die Wiederverwendung von mindestens einige Teile der älteren version.
That being said, nicht alle schreibt, sind eine gute Idee. Windows Vista, zum Beispiel.
Irgendwann, haben Sie schneiden Sie Ihre Verluste. Wenn Sie gerade geerbt dieser code-Basis, Sie möglicherweise änderungen, die unbeabsichtigte Folgen haben, und aufgrund der fehlenden tests, werden Sie fast unmöglich zu finden.
Zumindest, starten Sie das schreiben von tests sofort.
Anstatt eine komplette Neuentwicklung von Grund auf, die Sie starten möchten Refactorings, die code-Basis in kleinen Schritten während der Einführung von unit-tests. Zum Beispiel
Ich würde lieber Dinge tun, Stück für Stück, z.B., erstellen Sie ein back-end in die Datenbank mit einem Datenmodell, wie Sie arbeiten in diesen Bereichen (D. H., Benutzer anmelden, dann Benutzer-management, und so weiter), und optimieren die bestehenden front-end zur Nutzung der neuen back-end (interface-driven, so können Sie auch hinzufügen, tests). Dadurch halten Sie den vorhandenen code mit möglichen undokumentierte Kniffe und Verhaltensweisen, die Sie nicht replizieren, durch die Entwicklung wieder von vorne an, während das hinzufügen in einigen separation of concerns.
Nach einer Weile werden Sie migriert haben rund 60% der code-Basis zu verwenden, der neuen back-ends ohne die Arbeit, die ein offizielles Projekt, nur Wartung, so werden Sie in einer besseren position, um zu argumentieren für die Entwicklung Zeit zu tun, die anderen 40%, und sobald das getan ist, die bestehenden front-end-Klassen wird stark reduziert in Größe und Komplexität. Sobald es vollständig migriert werden, Sie werden in der Lage sein, um die Wiederverwendung für die neue back-end-model-und controller-Komponenten, wenn Sie jemals die Zeit für die Implementierung einer neuen Ansicht.
Starten Sie durch das schreiben eine technische Spezifikation. Wenn der code so schrecklich ist, dann Wette ich, es gibt keinen wirklichen Skillung entweder. So schreiben Sie eine umfassende und detaillierte spec - Sie schreiben müssen, eine spec-jedenfalls, wenn Sie möchten, neu zu schreiben, von Grund auf, so dass die Zeit ist eine gute Investition. Seien Sie vorsichtig, um alle details über die Funktionen. Da Sie in der Lage zu untersuchen, die dem tatsächlichen Verhalten der app, das sollte einfach sein. Gerne können Sie auch Verbesserungsvorschläge, aber bitte erfassen Sie alle details des aktuellen Verhaltens.
Als Teil der Untersuchung, Sie könnte prüfen, schreiben von automatisierten tests von system zu untersuchen und zu dokumentieren erwartete Verhalten. Schwerpunkt auf black-box - /Integrationstests anstelle von unit-Tests (die den code wird wahrscheinlich nicht erlauben, jedenfalls, wenn es so hässlich).
Wenn Sie haben diese Skillung wirst du wahrscheinlich entdecken, dass die app ist eigentlich viel komplexer, als Sie Ihren ersten Eindruck, zu überdenken und umschreiben von Grund auf. Wenn Sie sich entscheiden, um allmählich umgestalten statt, der Spezifikation und-tests wird Ihnen helfen, eine Menge. Aber wenn Sie immer noch entscheiden, vorwärts zu gehen und umschreiben, dann haben Sie eine gute Skillung zu arbeiten, und eine suite von Integrations-tests, die Ihnen sagen, wenn Ihre Arbeit abgeschlossen ist.
Ich denke, das hängt von zwei Dingen:
1), Wie fehlerhaft das zugrunde liegende design des legacy-Codebasis,
2) die Zeit, Die es dauern würde, zu tun umzuschreiben.
1) Das Unternehmen arbeite ich für eine schrecklich gestaltete codebase, die das umgestalten wirklich schwierig, weil wir konnte nicht umgestalten, mit jeweils einem bit, das Hauptproblem war, nicht mit den einzelnen Klassen und Funktionen, sondern mit dem Gesamtkonzept. Also die refactoring-Ansatz, der sehr schwer werden würde. (Wenn die gesamte design war gut, aber, sagen wir, die einzelnen Funktionen wurden 300 Zeilen lang und müssen Aufbrechen, dann ein refactoring Sinn macht).
2) Trotz viel code und sehr unübersichtlich, das ausführen von Prozessen. Unser Motor war nicht ganz so viel. Also das umschreiben war nicht so lange. Manchmal-Manager nicht erkennen, dass die Funktionalität von Hunderten von tausenden von code-Zeilen können neu erstellt werden, in sehr kurzer Zeit.
Wir haben versucht, dies zu erklären zu unseren CTO (kleine Firma), aber er dachte immer noch umschreiben, wäre zu riskant, also ich und mein co-worker schrieb die grundlegenden Funktionen des Motors über vier Wochenenden. Dann zeigte unser CTO und wurde schließlich überzeugt.
Nun, wenn der Aufbau der grundlegenden Funktionalität würde uns sechs Monate hätten wir nicht viel auf ein argument.
Es ist auch eine widersprüchliche Aussage in der Wirtschaft, die sagt,
Versunkene Kosten, laut Wikipedia (https://en.wikipedia.org/wiki/Sunk_cost):
Als versunkene Kosten sind gekoppelt mit politischem Druck oder persönliche ego (welcher manager will derjenige sein, zu zugeben, dass Sie eine schlechte Entscheidung getroffen oder nicht richtig überwachen, Ergebnisse, auch wenn es unumgänglich war oder aus Ihrer unmittelbaren Kontrolle?), es führt zu einer situation, genannt Eskalation der Verpflichtung (https://en.wikipedia.org/wiki/Escalation_of_commitment), die definiert ist als:
Was hat das mit code?
Haben eine ziemlich lange Karriere als software-Entwickler nun einen gemeinsamen thread die ich gefunden habe, ist, dass, wenn konfrontiert mit einer Herausforderung oder hässlich codebase (auch wenn es unsere eigenen von vor zwei Jahren), ist unser Erster Instinkt ist, zu wollen, werfen die alten, hässlich-code und neu zu schreiben. Wenn es sich um einen bekannten Codebasis, dann ist dies in der Regel, geboren aus der Tatsache, dass wir nun sehr viel mehr vertraut mit den Tücken des Projekt-und business-Anforderungen als wir waren, als wir das Projekt starteten, so dass wir (vielleicht unbewusst) sehnen sich nach der Möglichkeit zu beheben, unsere vergangenen Sünden durch löschen Sie mit Perfektion. Wenn es eine fremde Codebasis, wir neigen oft dazu, zu über-vereinfachen Sie die Herausforderungen, die sich durch den ursprünglichen Entwickler, gern über "Kleinigkeiten" zu Gunsten der "big-picture"-der Architektur-Ebene zu denken, und oft weht budgets und Zeitrahmen durch einen Mangel an Verständnis der komplexen Detail des business cases, der den code ursprünglich vorgesehen war, zu lösen.
Dann ist das ganze Konzept der technischen Schulden, die ebenso wie finanzielle Schulden, KANN und WIRD entstehen, bis zu dem Punkt, dass eine Codebasis wird, technisch insolvent. Mehr und mehr Zeit und Ressourcen investiert werden, in die Problembehandlung von Fehlern, löschen von Bränden, und übermäßig anspruchsvoll Verbesserungen in einem Umfang, der Fortschritt wird teuer, schwierig und gefährlich. Projekte dauern länger und länger aufgrund von Mängeln und zog aus der Projektarbeit zu lösen Produktion Probleme. Nach Stunden "Vorfälle" beginnen immer erwartet, dass die operation stattdessen von einem seltenen Ausrutscher. Statt sich zurückzuziehen und beginnen, Dinge zu tun, Recht zu erhöhen unsere Zukunft Produktivität und Qualität des Lebens), finden wir uns in einer position, wo wir gezwungen sind, Sie mehr und mehr technische Schulden, um Fristen einzuhalten - die technische gleichbedeutend mit Bargeld auf Kreditkarte auf ein minimum Zahlung auf eine andere Karte.
Dass alles gesagt wird, es nicht heißt, wir sollten umschreiben, wenn möglich, noch sollten wir vermeiden, umschreiben funktionierenden code an allen Kosten. Beide Extreme sind potenziell verschwenderisch, und die letzteren nicht dazu neigen, führen zu einer Eskalation des Engagements (weil auf allen Kosten bedeutet mit völliger Missachtung Kosten, selbst wenn diese Kosten vollständig über die Vorteile). Was muss eintreten, ist eine Objektive Beurteilung der Kosten und nutzen von Neuschreiben von code versus schrittweise zu verbessern. Die Herausforderung ist die Suche nach jemanden mit der Kompetenz und Objektivität zu machen, dass die Entscheidung richtig. Für uns Entwickler, die wir sind in der Regel voreingenommen gegenüber umschreiben, weil es dazu neigt, eine Menge interessanter und ansprechender als die Arbeit auf einige crappy legacy-Codebasis. Führungskräfte neigen dazu, voreingenommen in die andere Richtung, weil ein umschreiben erlegt einige unbekannte mit wenig wahrnehmbar unmittelbaren nutzen. Das Ergebnis ist im Allgemeinen das fehlen einer echten Entscheidung, die dann standardmäßig weiterhin dump Stunden in bestehenden code bis einigen Umstand erfordert eine gerichtete Verschiebung (oder der Entwickler, der heimlich schreibt den code, und in der Regel bekommt ein spanking für Sie).
Ich gearbeitet habe, codebase, die waren etwas zu retten, wenn auch hässlich. Sie nicht Folgen etablierten Praktiken oder Normen, nicht Muster, nicht schön, aber Sie führten Ihre beabsichtigten Funktionen Recht gut und waren flexibel genug, dass Sie geändert werden könnten, entsprechen den zukünftig zu erwartenden Bedürfnissen für die voraussichtliche Lebensdauer der Anwendung. Zwar nicht glamourös, es war durchaus akzeptabel, um diesen code am Leben, während schrittweise Verbesserungen, wenn sich die Gelegenheit bot. Tun, sonst würde produziert haben wenig nutzen andere als hübsch auszusehen. Ich würde sagen, dass die meisten code, über die die sollte ich diese umschreiben? Frage fällt unter diese Kategorie, und ich finde mich erklärt in der junior-Entwickler im team, dass, während es wäre ein großer Spaß zu umschreiben YetAnotherLineOfBusinessApp in {insert whizzbang Rahmen hier}, es ist weder notwendig oder wünschenswert, und hier sind einige Möglichkeiten, wie wir Sie verbessern können...
Habe ich auch gearbeitet codebase, die waren hoffnungslos. Diese wurden Anwendungen, die kaum gestartet, in den ersten Platz, in der Regel hinter dem Zeitplan und in einer reduzierten Funktionalität Staates. Sie wurden geschrieben in einer Weise, dass niemand, aber die ursprünglichen Entwickler hätte keine chance, zu verstehen, was der code schließlich nicht. Ich beziehe mich auf diese als "nur-Lesen" - code. Wenn es einmal geschrieben ist, wird jeder Versuch, ändern potenziell Ergebnisse im systemischen Unverständliches Versagen von unbekannter Herkunft, führt zu Panik, Großhandel schreibt der riesige monolithische code-Konstrukte, die dazu dienen keinem anderen Zweck als zur Aufklärung der aktuellen Entwickler auf das, was tatsächlich geschieht, um eine variable geschickt mit dem Namen
obj_85
durch die Ausführung erreicht Linie 1,209 verschachtelte 7 Ebenen tief inif... else...
,switch
, undforeach...
Aussagen irgendwo in derDoEverythingAndMakeCoffee(...)
Methode. Versuche zur Umgestaltung dieser code führt zu Fehler. Jeder Pfad, dem Sie Folgen, führt zu einer weiteren Herausforderung, und mehr Wege, und dann Wege, die Filiale, und dann wieder an einem früheren Weg, und nach zwei Wochen des Köpfe-down refactoring einer einzigen Klasse, die Sie erkennen, dass, während Sie vielleicht besser gekapselt, der neue code ist fast so schrill und verschleiert, wie der alte code, wahrscheinlich enthält noch mehr Fehler, weil die ursprüngliche Absicht von dem, was Sie umgestaltet werden, war völlig unklar, und nicht zu wissen, was genau die Fälle, führte zu der ursprünglichen Katastrophe in Erster Linie Sie können nicht sicher sein, Sie haben vollständig repliziert die Funktionalität. Fortschritt ist fast nicht-existent ist, weil die übersetzung der codebase ist fast unmöglich und etwas, das so unschuldig ist das umbenennen einer Variablen oder die Verwendung der richtigen Art produziert eine exponentielle Menge an unerwünschten Nebenwirkungen.Versuchen zu verbessern codebase wie die oben ist eine übung in Sinnlosigkeit. Das Refactoring führt in der Regel zu 80% neu schreiben sowieso, und das Endergebnis ist nirgendwo in der Nähe eine 80% Verbesserung. Sie am Ende mit etwas, das ist sehr inkonsistent, und der neue code hat eine Menge Kompromisse, die umgesetzt werden musste, im Interesse der Interoperabilität mit legacy-code (die Hälfte davon war unnötig, da die legacy-code, dass den neuen code, der benötigt wird, um die Interaktion mit später bekommt umgestaltet werden sich sowieso). Es gibt nur zwei Wege, die verfolgt werden können... weiterhin entstehen technische Schulden durch hacking in "fixes" und änderungen bei der Hoffnung, dass der Antrag veraltet ist (oder man an einem anderen Projekt) bevor es kollabiert unter seinem eigenen Gewicht, oder jemand macht sich die unternehmerische Entscheidung und geht das Risiko ein, mache eine komplette Neuentwicklung. Ich hasse diese beiden Optionen, denn es bedeutet in der Regel warten, bis etwas Kritischer ausgefallen oder ein Projekt ist hinter dem Zeitplan, und dann verbringen die nächsten drei Monate abends und am Wochenende versuchen, etwas atmen, dass es wohl nie gegeben haben sollte lebendig in den ersten Platz.
So, wie Sie sich entscheiden?
Es gibt ein altes Sprichwort, das sagt:
Den Schlüssel, um zu wissen, Wann der re-schreiben, liegt dort. Funktioniert das system derzeit nicht, was Sie wollen? Wenn die Antwort ja ist, ist die langsame, aber stetige Verbesserungen sind Ihre beste Wette. Wenn die Antwort ist Nein, ein re-schreiben, was Sie wollen.
Zurück zu Joel ' s essay spricht er über code, ist chaotisch, aber die software ist zuverlässig und liefert den erwarteten Wert. Wenn statt, haben Sie unzuverlässigen code voll von großen Fehler und das war es nicht, die alle Ihre Anwendungsfälle. Sie hatte Dinge, die waren angeblich noch nicht funktionieren, oder die sind eben einfach fehlt. In diesem Fall werden alle die kleinen Härchen wächst aus ihm heraus nicht Bugfixes, sondern Krebs.