it-swarm.com.de

Was ist der effektivste Weg, um unbekannten, strukturell nicht einwandfreien Codes Funktionen hinzuzufügen?

Dies ist wahrscheinlich etwas, mit dem sich jeder früher oder später während der Entwicklung auseinandersetzen muss.

Sie haben einen vorhandenen Code, der von einer anderen Person geschrieben wurde, und müssen ihn erweitern, um unter neuen Anforderungen zu funktionieren.

Manchmal ist es einfach, aber manchmal haben die Module eine mittlere bis hohe Kopplung und eine mittlere bis niedrige Kohäsion. Sobald Sie also anfangen, etwas zu berühren, bricht alles. Und Sie haben nicht das Gefühl, dass es richtig behoben ist, wenn Sie die neuen und alten Szenarien wieder zum Laufen bringen.

Ein Ansatz wäre, Tests zu schreiben, aber in Wirklichkeit war das in allen Fällen, die ich gesehen habe, so gut wie unmöglich (Vertrauen auf die grafische Benutzeroberfläche, fehlende Spezifikationen, Threading, komplexe Abhängigkeiten und Hierarchien, Fristen usw.).

Also fällt alles irgendwie auf den guten alten Cowboy-Codierungsansatz zurück. Aber ich weigere mich zu glauben, dass es keinen anderen systematischen Weg gibt, der alles einfacher macht.

Kennt jemand einen besseren Ansatz oder den Namen der Methodik, die in solchen Fällen verwendet werden sollte?

121
Coder

Zunächst einmal wird es ein wenig langweilig, dass jeder auf dieser Seite alles, was von jemand anderem geschrieben wurde, für Müll hält.

Das Verstehen von Code ist schwierig, zugegebenermaßen erschweren einige schlechte Programmierpraktiken das Verstehen, aber für jedes einigermaßen komplexe System wird es schwierig sein, die verwendeten internen Strukturen und Redewendungen zu verstehen, selbst wenn es sich um gut geschriebenen Code handelt.

Systeme laufen routinemäßig seit mehr als zwanzig Jahren. Programmiermethoden, Best Practices, Designphilosophien und Moden ändern sich alle paar Jahre, und Programmierer greifen die verbesserten Stile unterschiedlich schnell auf. Was 2007 als Stand der Technik und hervorragendes Beispiel für Code galt, sieht heute altmodisch und schrullig aus. Als Übung schlage ich vor, dass Sie einen Code ausgraben, den Sie vor drei Jahren geschrieben haben. Ich kann fast garantieren, dass Sie zusammenzucken werden.

Zunächst müssen Sie also die anfängliche WTF-Antwort unterdrücken. Sagen Sie sich, dass das System gut genug und lange genug funktioniert hat, um zu Ihrem Problem zu werden. Es muss also etwas Gutes daran sein.

Versuchen Sie, den ursprünglichen Codierstil und die verwendeten Redewendungen zu verstehen, studieren Sie die seltsameren Codebits und prüfen Sie, ob sie in ein Muster fallen.

Wenn die erforderlichen Änderungen gering sind, folgen Sie dem ursprünglichen Codierungsstil. Auf diese Weise nimmt jemand den Code auf, nachdem Sie sich nur an eine bestimmte Eigenart gewöhnt haben.

Wenn die erforderlichen Änderungen groß sind und sich die Änderungen auf einige Funktionen oder Module konzentrieren, nutzen Sie die Gelegenheit, diese Module umzugestalten und den Code zu bereinigen.

Berücksichtigen Sie vor allem den Arbeitscode nicht neu, der nichts mit der sofortigen Änderungsanforderung zu tun hat. Es dauert zu lange, es führt zu Fehlern, und Sie können versehentlich eine Geschäftsregel stempeln, deren Perfektionierung Jahre gedauert hat. Ihr Chef wird Sie dafür hassen, dass Sie so langsam kleine Änderungen vornehmen, und Ihre Benutzer werden Sie dafür hassen, dass Sie ein System zum Absturz gebracht haben, das jahrelang ohne Probleme lief.

139
James Anderson

Grundsätzlich haben Sie drei Ansätze:

  1. Von Grund auf neu schreiben. Es funktioniert möglicherweise für kleine Anwendungen, aber Sie können es nicht für große Codebasen verwenden.

    Beachten Sie, dass es für kleine bis mittlere Codebasen nicht das schlechteste Szenario ist, das Sie unbedingt vermeiden sollten.

    Es gibt einen guter Grund, nicht von Grund auf neu zu schreiben: Es wird allgemein erwartet, dass eine alte Codebasis getestet wird, Tricks enthält, mit denen der Code unter bestimmten Umständen funktioniert usw., und wenn Sie alles neu schreiben, werden Sie es tun Stellen Sie eine Reihe von Fehlern vor, die bereits behoben wurden.

    Dies ist ein ngültiges Argument in Fällen, von denen Sie sprechen, da Sie erwähnt haben, dass der Code eine sehr geringe Qualität hat: nicht getestet, mit fehlenden Spezifikationen, nie überarbeitet usw. Schreiben Sie nicht von Grund auf neu Die Regel muss sich dagegen auf den qualitativ hochwertigen, QS-geprüften Code beschränken.

  2. Cowboy-Codierungsansatz verwenden : alles ändern, dann testen. Dies kann je nach Kontext fehlschlagen oder erfolgreich sein.

    • Beispiel 1: Sie ändern die geschäftskritische Anwendung. Sie wissen, dass Ihr Kunde wütend wäre, wenn Sie etwas in vorhandenem Code brechen würden, und dieser Kunde ist überzeugt, dass das eigentliche Produkt nicht nur gut funktioniert, sondern auch korrekt geschrieben ist (oder der Kunde versteht einfach nicht, was beschissener Spaghetti-Code ist) gut geschriebener Code).

      Hier können Sie keine Cowboy-Codierung verwenden, da Sie keine neuen Fehler einführen dürfen. Dies bedeutet, dass Sie einen von zwei anderen Ansätzen verwenden müssen.

    • Beispiel 2: Ihr Kunde teilt Ihnen mit, dass seine Erfahrung mit dem vorherigen Entwickler eine Katastrophe war. Das Produkt funktioniert nicht einmal die Hälfte der Zeit und ist so wie es ist völlig unbrauchbar. Der Kunde versteht, dass das Ändern des so schlecht geschriebenen Quellcodes noch mehr Fehler verursachen kann.

      Auf der anderen Seite kann Cowboy-Codierung eine gute Lösung sein, wenn Sie sicher sind, dass sie die Gesamtkosten im Vergleich zu zwei anderen Lösungen senkt.

  3. Beginnen Sie mit der Überarbeitung des ursprünglichen Codes, fügen Sie Komponententests (und andere in bestimmten Fällen erforderliche Tests) hinzu, dokumentieren Sie sie usw. und fügen Sie dann Ihre Änderungen hinzu. Dies kann ein guter Ansatz sein, wenn der Code nicht zu beschissen ist und einen gewissen Wert hat. Wenn ich zum Beispiel weiß, dass der Code von meinem erfahreneren Kollegen unter Zeitdruck und geringen Budgetbeschränkungen geschrieben wurde, werde ich diesen Ansatz auf jeden Fall verwenden, da:

    • Es gibt Teile des Codes, die geschickt gemacht werden,

    • Sie werden viele Dinge aus dem Code lernen, den Sie umgestalten.

    • Selbst unter Zeitdruck und geringen Budgetbeschränkungen ist ein Code eines besser ausgebildeten Entwicklers immer noch ein Code eines bestimmten Niveaus. Dies bedeutet, dass der Fachmann, wenn es unter bestimmten Umständen einen Trick gibt, um die Anwendung zum Laufen zu bringen, einen Code hat Der Entwickler hinterlässt weiterhin einen Kommentar, in dem erläutert wird, warum die folgende Codezeile hinzugefügt wurde.

Ich glaube nicht, dass es eine perfekte Lösung gibt: Vergleichen Sie alle drei für jedes Projekt oder jede Aufgabe, bewerten Sie ihre jeweiligen Kosten und wählen Sie je nach den Umständen die beste aus.

Befolgen Sie im Allgemeinen diese beiden Regeln:

  • Regel 1 : Je besser die Entwickler sind, die den Code geschrieben haben, desto mehr Refactoring vs. Umschreiben von Grund auf neu müssen Sie verwenden.

  • Regel 2 : Je größer das Projekt ist, desto mehr Refactoring vs. Umschreiben von Grund auf neu verwenden müssen.

Refactor eine große Datenbank, die von jemandem geschrieben wurde, der erfahrener ist als Sie. Schreiben Sie kleine Codeteile oder Code, der von ungelernten Programmierern geschrieben wurde, von Grund auf neu.

46

Das ist im Grunde mein Alltag. Es gibt Fälle, in denen das Schreiben kleiner Tests aus den von Ihnen genannten Gründen einfach zu unpraktisch ist. Sie sollten zwar immer große Tests durchführen, aber es ist oft unmöglich, alle Grundlagen abzudecken. Der beste Ansatz, den ich finde, ist Spirale nach außen.

Anstatt von Anfang an neu zu schreiben, sollten Sie die Elemente gut verstehen. Wenn es lange Funktionen gibt, versuchen Sie, sie in logische Abschnitte zu schneiden. Entkoppeln/entwirren Sie die kleineren Elemente, die am wenigsten komplizierten nicht kreisförmigen Abhängigkeiten. Starten Sie eine parallele Bibliothek, die Sie gut verstehen, und migrieren Sie kleine Funktionen in generischen Bits.

Wenn Sie dies tun, werden Sie das System langsam entwirren und auf immer größere Codestücke hinarbeiten, die auch modularer werden.

Dokumentieren Sie, als wäre es eine Droge und Sie sind süchtig danach. Ich möchte keinen Roman in Ihren Code schreiben, aber es besteht die Möglichkeit, dass der Code nicht allzu dokumentiert ist. Machen Sie es also im .NET- oder Doxygen-Stil: Was macht die Funktion, Eingabe, Ausgabe (und wenn nötig, welche globalen Variablen oder Eigenschaften, die Sie verwenden oder ändern).

Letzter Trick: Standardverhalten definieren. Wenn das Programm als Ganzes Optionen oder Parameter enthält, definieren Sie die Standardeinstellung und implementieren Sie eine einfache Methode zur Bereitstellung mit allen Standardeinstellungen (ich habe dies mit einer einfachen Datei INI. Sehr nützlich) gemacht.) explizit angelegt. Anschließend können Sie andere Optionen und Funktionen als neue Optionen hinzufügen, die an das ursprüngliche System anknüpfen.

40
MPelletier

Bei der Arbeit mit Big Ball Of Mud war der einzig effektive Ansatz für mich, (mehr) Tester zu bekommen und einen gründlichen Profi zu arrangieren Qualitätssicherung im Projekt .

  • Die Sache ist, dass alle Ansätze, die mit einer besseren Codebasis anwendbar sind, es einfach nicht schaffen.
    Mit gutem Code studiere ich Dokumentation, um mehr über die Prinzipien zu erfahren, lese Code (und insbesondere Unit-Tests) durch, um Konstruktionsdetails zu ermitteln, schreibe meine eigenen Unit-Tests, um die von mir vorgenommenen Änderungen abzudecken usw. Wenn der Code verbessert wird, bleiben Unit-Tests intakt oder kleinere Änderungen vornehmen, Dokumente benötigen keine größeren Nacharbeiten usw. usw.

    Mit schlechtem Code scheinen die Dinge genau umgekehrt zu funktionieren. Informationen, die ich aus der Dokumentation erhalte, sind größtenteils obskure und veraltete Abfälle. Das Lesen von Code bringt mein Gehirn zum Schmelzen mit einem komplizierten Kontrollfluss und kontraintuitiven Patches, die auf frühere Patches angewendet wurden, die auf noch frühere Patches angewendet wurden, die vor langer Zeit erstellt wurden, um Designfehler schnell zu umgehen.

    Bei Unit-Tests tun diese Dinge entgegengesetzt zu meiner Verwendung in gutem Code, z. B. bei vernünftigen Änderungen zu brechen und die tatsächlichen Fehler, die ich mache, nicht zu erfassen. Was schmerzhaft, aber nicht überraschend ist - was würde man sonst noch von Tests erwarten Einheiten, die anfangs ein schlechtes Design haben? Anstatt Ihnen bei der Verbesserung des Designs zu helfen, arbeiten Unit-Tests häufig daran, schlechten Code zu erhalten. In meinem letzten Wartungsprojekt habe ich beispielsweise regelmäßig große Codestücke entfernt, auf die nur aus veralteten sinnlosen Unit-Tests verwiesen wurde. Übrigens verwende ich dieses Wissen beim Schreiben von neuem Code: Wenn ich herausfinde, dass meine Komponententests zu kompliziert/zerbrechlich werden, deutet dies darauf hin, dass ein Problem mit meinem eigenen Design behoben werden muss.

Nun zurück zu dem, was für mich funktioniert hat. Das erste ist, sich nicht vom Management mit Sie sind ein guter Entwickler, damit können Sie umgehen Rhetorik betrügen. Denken Sie selbst, denken Sie kritisch und Sie werden feststellen, dass trotz guter Entwickler-Rauchschutzwände das Ganze stark auf - Qualität geneigt ist Versicherung Seite .

  • Fragen Sie sich zunächst - warum haben sie diesen Big Ball of Mud nicht einfach weggeworfen?
    Warum haben sie in die Einstellung von Ihnen investiert, um es aufrechtzuerhalten? In der Regel liegt der Grund darin, dass das Ding für die Benutzer gut funktioniert und von Ihnen erwartet wird, dass es für die Benutzer gut funktioniert. Sie nehmen es als Black Box wahr, sie schauen nicht in den (beschissenen) Code, sie sehen nur eine nützliche Funktionalität.

    Wenn Sie jemals mit professioneller Qualitätssicherung gearbeitet haben, werden Sie schnell erkennen, dass Tester auf diese Weise mit Software umgehen. Black Box, Funktionalität, Qualität aus Anwendersicht - all dies sind Themen und Themen der Qualitätssicherung.

Okay, wenn Sie bisher gelesen haben, fragen Sie sich vielleicht, wie genau das bei mir funktioniert? Es ist wirklich einfach.

Das erste ist - wenn ich eine Bugfix-Funktion beende, ordne ich das entsprechende Element in Issue Tracker dem QA-Mitarbeiter neu zu, um meine Änderungen zu überprüfen . Auf diese Weise muss ich keine Zeit mit umständlichen Funktionstests verschwenden. Überprüfen Sie einfach schnell, ob Kandidatencode für die Qualitätssicherung bereit ist.

Wenn ich wirklich Glück habe (kommt nicht oft vor), muss ich mir keine Sorgen mehr machen. Das schlimmste Szenario ist auch nicht so schlimm. Wenn ich etwas falsch gemacht habe, meldet sich der Tester nur ein oder zwei Tage später bei mir und erklärt klar, was genau schief gelaufen ist und wie der Fehler reproduziert werden kann, zusammen mit der erweiterten Regressionstestsuite erweitert auf Fangen Sie diese Art von Fehlern leicht ab, wenn sie erneut auftreten. Nicht wirklich schlecht, findest du nicht?

Die nächste großartige Sache, die mit der Qualitätssicherung einhergeht, ist regelmäßige Regressionstestzyklen.

  • Einige (lahme) Manager versuchen möglicherweise, Sie davon zu überzeugen, dass Sie dies erledigen können automatisch - vertrauen Sie ihnen nicht.
    Dinge, die mit gutem Code großartig funktionieren, machen den Trick mit Big Ball Of Mud einfach nicht.

    Die Testausführung ist umständlich, die Analyse der Testergebnisse ist mühsam. Die Pflege der Datenbank für Probleme und Regressionen erfordert viel Fokus (mehr Fokus, als Sie sich leisten können, wenn Sie sich auch auf die Entwicklung konzentrieren möchten). Anstatt Zeit damit zu verschwenden, ein Alleskönner zu sein, lassen Sie professionelle Tester dies für Sie tun, geben Sie Ihrem Gehirn Zeit und Zeit für Design und Codierung. Nutzen Sie einfach das gute alte Arbeitsteilung .

Regelmäßige Testzyklen (imNSho wöchentlich sind am besten, obwohl monatlich auch für mich gut funktioniert hat) lassen Sie das Unmögliche tun - effektives Refactoring .

Mit effektiv Ich meine, wenn das Ding eine Woche zum Codieren und eine Woche zum Beheben von Regressionsfehlern benötigt, können Sie davon ausgehen, dass Sie genau das - zwei Wochen wie geplant - verbringen, ohne zu sinken in einen zusätzlichen Monat, der für die Durchführung hirnschädigender Tests und die komplizierte Fehleranalyse verschwendet wird - denn Tester übernehmen dies für Sie.


Neben den oben genannten Hauptvorteilen gibt es noch andere, kleinere, aber angenehme Boni auf dem Weg.

  1. Mit Testern erhalten Sie jemanden, mit dem Sie über Design diskutieren können. Wie ich geschrieben habe, helfen Dokumente und Code hier nicht, wenn Sie sich mit Big Ball of Mud - Vakuum beschäftigen, wenn Sie alleine arbeiten. Ein Tester, der Ihren Code ausführt und aus einer anderen Perspektive betrachtet, ist ein großartiger Partner, um Ideen auszutauschen und mögliche Änderungen zu untersuchen.

  2. Mit Testern erhalten Sie jemanden, der Ihr Verständnis von Designproblemen sichert. Wenn sich nur Entwickler über Codequalität beschweren, klingt dies oft nach subjektiven WTFs hinter der geschlossenen Tür .

    Aber wenn dies von einem QS-Mann wiederholt wird, der so etwas wie component A hatte 100 Regressionsfehler für 10 neue Funktionen im Gegensatz zu component B mit 10 Regressionsfehlern pro 20 neuen Funktionen, Kommunikation wird plötzlich zu einem ganz anderen Spiel.

  3. Last but not least hilft eine professionelle Qualitätssicherung dabei, Ihr Verständnis für den Aufwand zu fördern, in den Sie in Designverbesserungen investieren sollten. Wie ich bereits erwähnt habe, funktioniert das Management nicht sehr gut mit WTFs in Codequalität.

    Aber wenn es eine professionelle Qualitätssicherung gibt, mit all den Daten, die sie normalerweise sammeln, können Sie sich Dinge einfallen lassen, die dazu neigen, mit dem Zauberstempel I durch die Gehirne der Manager direkt in diese geheime Zelle zu schießen genehmigen

    Im letzten Jahr haben wir ungefähr 6 Mannmonate ausschließlich für die Behebung von Regressionsfehlern im Produkt verschwendet. Wie wäre es nun damit, dem Entwicklerteam ein oder zwei Wochen Zeit zu geben, um zu analysieren, ob wir etwas tun können, um diesen Abfall um die Hälfte zu reduzieren?

14
gnat

Ein Ansatz wäre, Tests zu schreiben,

Ich glaube, dass Sie Ihre eigene Frage zur Hälfte beantwortet haben. Es gibt eine Reihe von Möglichkeiten, wie Sie dies betrachten können. Mit der Erfahrung habe ich jedoch festgestellt, dass es immer darauf ankommt, einige der agilen Standardpraktiken anzuwenden und alles systematisch auf die gleiche Weise zu tun, wie Sie es tun würden jedes schwer zu lösende technische Problem.

So gehe ich persönlich mit dieser Situation um:

  • Beginnen Sie mit einer Studienzeit, machen Sie sich Notizen, zeichnen Sie Diagramme und stellen Sie sich (und/oder einem nahe gelegenen „lokalen Experten“) viele Fragen. Sie müssen den Code lesen und sich einen Überblick über das Problem verschaffen.
  • Identifizieren Sie mehrere offensichtliche Problembereiche und bewerten Sie das Risiko, mit ihnen in Konflikt zu geraten. Nehmen Sie einige Änderungen vor, um zu sehen, wie die Fehler auftreten werden, und um eine Vorstellung davon zu erhalten, wie viel zusätzlicher Aufwand erforderlich wäre, um entweder dem Pfad zu folgen, dem Ihre Spitze gefolgt ist, oder um etwas ganz anderes zu tun.
  • Wählen Sie ein Problem und schreiben Sie Tests. Verwenden Sie vorhandene Tests, wenn sie verfügbar sind, und schreiben Sie neue Tests, die die Geschäftslogik so gut wie möglich schützen.
    • Schreiben Sie Ihren Test so, dass er fehlschlägt, korrigieren Sie dann Ihren Test, um ihn zu bestehen, und ändern Sie Ihren Code so, dass er fehlschlägt. Verwenden Sie den letzten Schritt "Codefehler" als Gelegenheit, den Code zu durchlaufen und alles Offensichtliche zu identifizieren, das Sie sonst möglicherweise übersehen haben.
  • Entwerfen und planen Sie Ihre Änderung so, wie Sie glauben, dass der Code geschrieben werden sollte, um das Problem zu beheben. Hier müssen Sie zu den Anforderungen und der Spezifikation zurückkehren (vorausgesetzt, Sie haben eine) und Ihre Tests so schreiben, wie Sie es mit Ihren User Stories oder Features oder mit der Methode tun würden, die Sie normalerweise verwenden würden.
  • Schreiben Sie neue Tests, die Ihren neuen Geschichten entsprechen (auch bekannt als Ihre überarbeitete Spezifikation).
  • Überarbeiten Sie Ihren Code in kleinen Schritten. Beginnen Sie mit dem Extrahieren von Methoden, dann mit dem Extrahieren von Klassen, dann mit dem Verschieben von Methoden und Klassen und dem Kombinieren/Löschen von Klassen. Führen Sie immer zuerst alle einfachen Refactorings durch, da dies die schwierigeren Refactorings später erleichtert. Ich würde empfehlen, sowohl Refactoring als auch Refactoring To Patterns zu lesen, wenn Sie nach ein wenig Hilfe oder Inspiration suchen, um Ihre Bemühungen zu leiten.
    • Während Sie den Refactor durchführen, möchten Sie Ihre ursprünglichen Tests bestehen lassen und Ihre neuen Tests nach Abschluss des Refactorings bestehen lassen. Wenn Sie dies tun, werfen Sie möglicherweise einige der ursprünglichen Tests weg, oder Sie haben das Glück, dass sowohl alte als auch neue Tests zusammen bestanden werden.

Dies ist ein Prozess, von dem ich festgestellt habe, dass er für mich gut funktioniert. Es ist zeitaufwändig und kann manchmal langweilig sein, aber es funktioniert und gibt mir immer ein gutes Ergebnis. Ich habe nie Code gefunden, den ich angesichts der Zeit und der Ressourcen dafür nicht verbessern konnte. Die Sache ist, Sie können feststellen, dass Sie während Ihrer ersten Untersuchungen und Spitzen einige sehr schwierige Probleme oder sogar Show-Stopper identifizieren, basierend auf der Zeit und dem Aufwand, den Sie für alles benötigen, und die Schätzung dieser Art von Dingen kann sehr schwierig sein mit Sicherheit. Möglicherweise ist es am Ende besser, von vorne zu beginnen, oder Sie stellen fest, dass der Code für das Unternehmen, für das Sie arbeiten, von großem kommerziellen Wert ist. Geben Sie Ihre beste Schätzung an, um die Arbeit zu erledigen, und wenn Sie die Problemdomäne vollständig verstanden haben, geben Sie Ihre beste Schätzung an, um die Dinge von vorne zu beginnen. Präsentieren Sie Ihrem Chef einige Fälle und Szenarien und lassen Sie das Management entscheiden, wo das Geld ausgegeben werden soll. Das nimmt dir die Hitze und bringt sie fest mit ihnen zurück.

Wie gesagt, dieser Ansatz funktioniert bei mir, bei Ihnen funktioniert er möglicherweise nicht genau gleich. Möglicherweise möchten Sie den Prozess optimieren oder das Problem auf andere Weise lösen. Der Punkt ist, dass Sie diese schwierigen Probleme nur lösen können, indem Sie seitlich denken und ein Durcheinander im Code nicht einfach als verlorene Ursache ansehen. Betrachten Sie es stattdessen als ein schwieriges Problem und eine Herausforderung, und bei jedem Problem gibt es immer einen systematischen Weg, es zu lösen. Sie müssen nur einen Ansatz finden, der für Sie funktioniert. Persönlich bin ich sehr stolz darauf, aus einer schlecht gestalteten Anwendung ein wunderschön gestaltetes Produkt zu machen, wenn ich mich einer solchen Herausforderung stelle und ein paar Siege eingefahren habe.

8
S.Robins

Ich arbeite seit mehr als einem Jahr an einer komplexen Codebasis. Sehen Sie, ob meine Erkenntnisse Ihnen helfen können:

Ihre Erkenntnisse sind richtig. Wenn Sie einen anderen Teil des Codes erreichen, vergessen Sie den vorherigen Teil. Es kann ein nie endender Zyklus sein. Die wichtige Lehre, die Sie hier mitnehmen sollten, ist, dass das Produkt nicht funktionieren kann, ohne dass alle Teile ordnungsgemäß funktionieren. Selbst wenn ein Teil ausfällt, funktioniert das Produkt nicht. Betrachten Sie es aus einem anderen Blickwinkel: Wenn Sie ein Teil dramatisch verbessern, kann es dennoch NICHT zu einer besseren Funktionsweise des Produkts führen, was hier Ihr Hauptziel ist.

Also zuerst: Sei kein Entwickler. Sei ein Tester.

Versuchen Sie nicht, Teil für Teil zu verstehen. Verstehen Sie das gesamte Produkt und seine Funktionsweise, wenn alle Teile zusammen sind. Testen Sie das Produkt in einer Produktionsumgebung (d. H. Einer Nicht-Entwicklungsumgebung - keine Debug-Punkte). Protokollieren Sie dann wie bei jedem Tester die aufgetretenen Probleme in einem Bug-Tracker. Weisen Sie ihm den Schweregrad und die Priorität zu. Da diese Software schon seit einiger Zeit existiert, prüfen Sie, ob bereits ein Bug-Tracker erstellt wurde. Wenn es bereits einen gibt, haben Sie Glück. Fügen Sie diese hinzu und nehmen Sie sich Zeit und überprüfen Sie alle vorhandenen. Am Ende dieses Zyklus verstehen Sie das Produkt aus Anwendersicht (Sie sollten es auf keinen Fall verpassen) und auch aus Sicht der Qualitätssicherung. Zu gegebener Zeit könnten Sie sogar feststellen, dass eine Codezeile den Fehler behebt, und diejenigen, die ihn codiert haben, haben dies nicht getan, da es damals keinen wirklichen Bedarf gab.

Zweiter Schritt: Tragen Sie Ihren Designerumhang

Teilen Sie das Produkt in mehrere Teile (nicht wörtlich oder nach Ihren Wünschen, sondern nach der Art und Weise, wie sie zusammenarbeiten). Möglicherweise ist Ihre Arbeit bis jetzt oder vorhandenes Wissen könnte ins Spiel kommen. Versuchen Sie dann zu verstehen, wie sie miteinander und mit den 10 abhängigen Bibliotheken arbeiten. Schreiben Sie dann für jeden nachverfolgten Fehler Ihre Notizen, in denen Sie Code-Entitäten identifizieren (z. B.: Diese Änderung umfasst das Ändern der Klassen X, Y, Z usw.). Am Ende dieses Schritts werden Sie wahrscheinlich WENIGE Hinweise darauf haben, was die Probleme mit der aktuellen Architektur sind und was verbessert werden kann.

Anschließend können Sie entscheiden, ob die aktuelle Architektur/das aktuelle Design ausreicht, und die Software verbessern OR, wenn das Produkt ein besseres Design oder Änderungen am vorhandenen Design benötigt.

Kartenhaus

Da komplexe Produkte viel Code enthalten, sind wir möglicherweise nicht in der Lage, einige Dinge aufzunehmen und zu optimieren oder zu verbessern. Dies liegt daran, dass das gesamte System so miteinander verflochten werden kann, dass das Ändern einer der Klassen dem Ändern der Position einer Karte in einem Kartenhaus entspricht. Sie wissen nie, welches Ende brechen könnte. Nach meiner Erfahrung war dies wahr. Ich habe ein Teil ausgewählt, seinen Code verbessert, ohne die Verträge mit anderen Teilen des Codes zu kennen, und habe den Code schließlich aufgegeben und meinen Fehler erkannt. Also, anstatt zu versuchen, Teile zu verstehen, versuchen Sie zu verstehen, dass es ein Ganzes ist.

Priorisieren Sie Ihre Bedenken

Sie müssen bedenken, was Sie verbessern möchten:

Möchten Sie, dass das Produkt schneller ist?

Natürlich tust du. Aber ist es das Hauptanliegen? Ist es langsam? Wenn ja, erstellen Sie Leistungskriterien, identifizieren Sie Engpässe und verbessern Sie diese Teile. Nochmal testen.

Möchten Sie die Benutzerfreundlichkeit verbessern?

Dann ist es so ziemlich die API/UI-Seite.

Möchten Sie die Sicherheit verbessern?

Dann sind es die Grenzen, die Sie erkunden sollten.

Ich habe nur 3 Beispiele angegeben, aber es gibt noch viel mehr zu suchen.

Neueste und beste Dokumentation

Ich habe hier in einem der Beiträge gelesen, dass die neueste und beste Dokumentation der Code selbst ist. Selbst wenn Sie heute eine gute Menge an Dokumentation erstellen, ist dies nach einer Weile Geschichte. Code ist also Ihre neueste Dokumentation. Wenn Sie also einen Code durchsuchen, schreiben Sie Ihr Verständnis in die dortigen Kommentare. Achten Sie beim Übergeben der Codebasis darauf, dass Sie NICHT NUR von Kommentaren abhängen!

2
Sundeep

Schreiben Sie so viel Dokumentation wie nötig, um den aktuellen Code zu erklären. Sobald Sie sicher sind, dass Sie die Logik verstanden haben, können Sie sie möglicherweise ändern. Dokumentieren Sie alles, was Sie hinzufügen möchten, und stellen Sie sicher, dass Sie alle Fälle abdecken.

Schreiben Sie Regressionstests. Es spielt keine Rolle, ob Sie die Tests manuell testen oder automatisch ausführen. Sie müssen die ursprüngliche Funktionalität beibehalten, und Regressionstests helfen dabei.

Wenn es nicht genügend Spezifikationen gibt, fangen Sie an, die Leute nach weiteren Informationen zu durchsuchen, und schreiben Sie sie auf.

Schreiben Sie einen Plan zum Ändern des Codes auf und teilen Sie ihn in verschiedene Phasen auf.

0
Rudolf Olah