An fremdem Code arbeiten [geschlossen]

Ich habe kaum ein Jahr Erfahrung im Codieren. Nachdem ich mit der Arbeit begonnen hatte, arbeitete ich die meiste Zeit am Code einer anderen Person, indem ich entweder neue Features über die vorhandenen hinzufügte oder die vorhandenen Features änderte. Der Typ, der den eigentlichen Code geschrieben hat, arbeitet in meiner Firma nicht mehr. Es fällt mir schwer, seinen Code zu verstehen und meine Aufgaben zu erledigen. Wann immer ich versucht habe, den Code zu ändern, habe ich in irgendeiner Weise mit den Arbeitsfunktionen herumgespielt. Woran sollte ich denken, wenn ich den Code eines anderen überarbeite?

Hat der Code Unit-Tests? Wenn nicht, empfehle ich Ihnen dringend , sie hinzuzufügen. Auf diese Weise können Sie neue Funktionen / Fehlerbehebungen als fehlgeschlagene Tests schreiben und dann den Code ändern, den der Test besteht. Je mehr davon Sie erstellen, desto mehr Vertrauen haben Sie, dass Ihr hinzugefügter Code nichts anderes beschädigt hat.

Das Schreiben von Komponententests für Code, den Sie nicht vollständig verstehen, hilft Ihnen, den Code zu verstehen. Natürlich sollten Funktionstests hinzugefügt werden, falls diese noch nicht existieren. Mein Eindruck war, dass diese bereits von der OP-Frage existierten. Wenn ich in diesem Punkt falsch liege, sollten diese Funktionstests Ihr erster Schritt sein.

Eagle76dk macht einen großen Punkt zu Ihrem Manager an Bord bekommen , diese Arbeit zu tun - mehr Details in Eagle76dk Beiträgen gehen .

Wenn Sie diese Tests schreiben, sollten Sie außerdem versuchen, die Tests so zu schreiben, dass das Geschäftsverhalten überprüft wird, das die Methode möglicherweise versucht hat, und nicht das Codeverhalten. Gehen Sie außerdem keinesfalls davon aus, dass das im Code angezeigte Geschäftsverhalten das richtige ist. Wenn Sie jemanden haben, der Ihnen sagen kann, was die Anwendung tun soll, ist dies in vielen Fällen wertvoller als das, was der Code Ihnen sagen könnte.

Zusätzlich zu einer anderen Antwort, in der Unit-Tests erwähnt wurden, würde ich vorschlagen, dass Sie sicherstellen, dass sich alle Komponenten in der Versionskontrolle befinden, damit Sie Ihre Änderungen problemlos rückgängig machen können. Und kleine Änderungen vornehmen, um den Code wartungsfreundlicher zu machen.

Meiner Meinung nach besteht der schnellste Weg, den Code eines anderen zu lernen (insbesondere, wenn Änderungen unerwartetes Verhalten auslösen, wie Sie es beschreiben), darin, den Code mit einem Debugger durchzugehen .

Beginnen Sie mit dem Durchlaufen der Hauptschleife / Hauptmethoden des Programms. Verwenden Sie die Step-In- und Step-Out- Funktionen, um zu sehen, was die verschiedenen Methoden bewirken. Dadurch lernen Sie die allgemeine Struktur des Codes.

Teilen und erobern Sie danach, indem Sie die verschiedenen Teile des Programms auf einer tieferen Ebene durchgehen und lernen. In den meisten Debuggern können Sie Variablen und ihre aktuellen Werte untersuchen . Studieren Sie, wie und wann sie sich ändern.

Legen Sie Haltepunkte für Methoden fest, die Verhaltensweisen auslösen, die Sie betreffen. Wenn Sie beispielsweise versuchen, einen Text im Programm zu ändern und der Text immer wieder auf den ursprünglichen Wert zurückgesetzt wird, setzen Sie Haltepunkte an allen Stellen, an denen der Text geändert wird, oder versuchen Sie, alle diese Änderungen auf eine einzige Methode zu verschieben. Verwenden Sie die Aufrufliste, um zu sehen, von wo aus diese Methode aufgerufen wird usw. usw.

Wenn das Ändern einer Codezeile an anderen Stellen zu unerwarteten Änderungen führt , setzen Sie einen Haltepunkt in diese Zeile und überprüfen Sie, was dort passiert. Überprüfen Sie beispielsweise die Werte der aktuellen Variablen im Gültigkeitsbereich, verwenden Sie step into oder den Aufrufstapel, um festzustellen, woher sie stammen Der Anruf kam.

Auf diese Weise lernen Sie die Struktur des Codes überraschend schnell. Ich habe genau wie Sie bei meinen ersten Programmierjobs angefangen, mit viel Code, der vor vielen Jahren geschrieben und von vielen Menschen über viele Jahre hinweg geändert wurde. Der Code gehörte nicht nur mir, da dort andere Leute zur gleichen Zeit daran arbeiteten. Zu diesem Zeitpunkt konnte ich noch nicht alles umschreiben. Das Schreiben von Tests für diesen ganzen Code hätte Monate oder Jahre gedauert. Der Debugger hat mich wirklich gerettet, ich weiß nicht, wie ich den Code ohne ihn gelernt hätte ...

Das erste, was zu beachten ist, ist, dass mehr Zeit für das Lesen von Code aufgewendet wird als für das Schreiben von Code. Nehmen Sie sich Zeit, um zu verstehen, wie der andere Mann gearbeitet hat - seinen Stil und seine Herangehensweise an Probleme.

Versuchen Sie, den vorhandenen Stil so weit wie möglich zu übernehmen - andernfalls muss der Typ nach Ihnen doppelt so viel Anpassungsarbeit leisten.

Der Umgang mit dem Code einer anderen Person ist die Norm, nicht die Ausnahme. Sie müssen sich mit der Frage auskennen, wie der andere ein Problem gelöst oder eine Funktion implementiert hätte. Sobald Sie das getan haben, werden Sie es leichter finden, mit seinem Code umzugehen.

Seien Sie nicht zu schnell, um anzunehmen, dass der Code des anderen stinkt.

Sei aber immer misstrauisch.

Aber es braucht Zeit, um den Code eines anderen Entwicklers zu verstehen. Je mehr eine Funktion oder ein Objekt von mehreren Teilen des Systems verwendet wird, desto vorsichtiger müssen Sie sein. Wenn Sie das Problem näher am Symptom lösen können, kann dies manchmal hilfreich sein. Normalisieren Sie beispielsweise eingehende Daten von einem anderen Objekt auf der Seite des Problemobjekts, nachdem die Daten übermittelt wurden, bevor etwas anderes passiert.

Es ist ein schlechtes Zeichen, wenn eine Änderung eine andere unerwartet zerstört. Wenn Sie weitere erfahrene Entwickler haben, auf die Sie sich verlassen können, empfehlen wir Ihnen, sich mit Dingen zu befassen, die Probleme verursachen. Zumindest können Sie ein paar Dinge aufgreifen, die sie beim Debuggen beobachten.

In einer idealen Welt wird jeder von einem bestimmten Entwickler geschriebene Code gut dokumentiert, gut strukturiert und nachvollziehbar getestet, sowohl mit automatischen Tools wie Unit-Tests als auch mit Use-Case-Skripten, die ein Benutzer durchläuft, um zu überprüfen, ob Sie das erwartete Ergebnis erzielen.

Das Erste, was Sie jedoch lernen werden, ist, dass wir nicht in einer idealen Welt leben!

Viele Entwickler dokumentieren ihren Code nicht richtig, wenn überhaupt, mischen sie Geschäftslogik mit nicht verwandtem Code, und der einzige Test, den sie durchführen, ist ein schneller Durchlauf des erwarteten normalen Anwendungsfalls.

Wenn Sie mit Code wie diesem arbeiten, müssen Sie zunächst festlegen, was er tun soll. Wenn es Kommentare gibt, geben sie möglicherweise Hinweise, aber rechnen Sie nicht damit. Ich habe die Erfahrung gemacht, dass viele Programmierer nicht gut darin sind, sich selbst zu erklären, und selbst wenn sie Kommentare hinterlassen, sind sie möglicherweise bedeutungslos. Wenn Sie jedoch nicht der einzige Programmierer im Unternehmen sind, muss jemand zumindest eine grundlegende Vorstellung davon haben, wofür der Code gedacht ist und was er tun soll. Herumfragen!

Wenn Sie Unit-Tests haben, werden sie Ihr Leben verdammt viel einfacher machen. Andernfalls müssen zum Erlernen der Codebasis möglicherweise Komponententests für bereits vorhandenen Code geschrieben werden. Normalerweise wird dies nicht als bewährte Methode angesehen, da beim Schreiben von Komponententests, die dem vorhandenen Code entsprechen, Komponententests durchgeführt werden, bei denen davon ausgegangen wird, dass es sich um einen Fehler handelt richtig), aber es gibt Ihnen zumindest eine Grundlinie. Wenn Sie später feststellen, dass ein Verhalten, das Sie für richtig hielten, tatsächlich falsch ist, können Sie den Komponententest ändern, um zu prüfen, ob das erwartete Ergebnis vorliegt und nicht das Ergebnis, das der Code jetzt angibt. Sobald Sie einen Unit-Test durchgeführt haben, können Sie Änderungen vornehmen und bewerten, welche Nebenwirkungen Ihre Änderungen haben.

Die beste Ressource für den Umgang mit undokumentiertem Code ist es, die Endbenutzer zu befragen. Sie wissen vielleicht nichts über Code, aber sie wissen, was die Anwendung tun soll. Das Sammeln von Anforderungen ist der erste Schritt in einem Projekt, und das Gespräch mit den potenziellen Benutzern des zu entwickelnden Systems ist immer ein wichtiger Teil davon. Stellen Sie sich vor, Sie führen die Anforderungserfassung für ein neues Projekt durch, das zufällig bereits erstellt wurde.

Denken Sie daran, dass selbst gut geschriebener und dokumentierter Code für einen Außenstehenden schwer zu verstehen sein kann. Code ist im Wesentlichen ein Ausdruck dafür, wie die Person, die ihn geschrieben hat, zu dieser Zeit gedacht hat, und jeder hat seinen eigenen einzigartigen Denkprozess. Sie müssen lernen, ein bisschen geduldig und ein Detektiv zu sein. Es ist schwierig, sich in den Denkprozess einer anderen Person hineinzuversetzen, aber es ist eine wesentliche Fähigkeit für einen Programmierer, den vorhandenen Code zu pflegen. Da der größte Teil der Codierung (ca. 70%) mit der Beibehaltung des vorhandenen Codes zusammenhängt, ist es wichtig, diese Fähigkeit zu erlernen.

Oh, und jetzt, wo Sie den Schmerz gesehen haben, den schlecht dokumentierter, ungetesteter und durcheinandergebrachter Code verursachen kann, werden Sie es dem nächsten armen Entwickler nicht antun, richtig? :) Lernen Sie aus den Fehlern Ihres Vorgängers, kommentieren Sie Ihren Code gut, stellen Sie sicher, dass jedes Modul eine klar definierte Verantwortung hat, an die es sich hält, und stellen Sie sicher, dass Sie einen umfassenden Satz von Komponententests haben, die Sie entweder zuerst schreiben (für TDD-Methoden) oder zumindest neben dem Code, der entwickelt wird.

Denken Sie daran, dass die Fähigkeit, Code zu lesen, den Sie nicht geschrieben haben, eine sehr wertvolle Fähigkeit ist, die wahrscheinlich wertvoller ist als das Schreiben von Code. Leider ist dies in den Schulen weitestgehend unterbewertet.

Ich versuche zu sagen, dass es normal ist, dass Sie beim ersten Lesen nicht immer den Code verstehen (genau wie es normal ist, dass Sie nicht beim ersten Mal den perfekten Code schreiben). Wenn Sie akzeptieren, dass das Abrufen eines Fremdcodes einige Zeit in Anspruch nimmt, macht es Ihnen nichts aus, zusätzliche Anstrengungen zu unternehmen. Eine kleine Zusammenfassung:

• Unit-Tests wären ideal, aber nicht immer realistisch. vor allem, wenn Sie in einer großen Organisation mit viel Bürokratie arbeiten.

• Erfahren Sie, wie Sie Ihr Versionskontrollsystem richtig verwenden. Sie werden nie das Bestehende brechen (nicht wirklich nie , aber es ist ein gutes Sicherheitsnetz).

• Gehen Sie nicht davon aus, dass es schlecht ist, nur weil Sie es nicht sofort verstehen. Gehen Sie nicht davon aus, dass es einfach gut ist, weil es funktioniert. Wichtig ist, dass Sie den Codestil des vorherigen Betreuers verstehen und die hinzugefügten Zeilen an seinen Stil anpassen. Der Betreuer, der nach Ihnen kommt, wird Ihnen dafür danken.

• In einigen Unternehmen ist die Schwierigkeit, Code zu lesen, leider zu unterschätzen. Dies ist in großen Unternehmen mit starren Prozessen üblich. Sie ziehen es oft (implizit) vor, dass Sie schnell funktionierenden Code übermitteln, anstatt sich die Zeit zu nehmen, um etwas Sauberes zu schreiben. Ich überlasse es Ihnen zu entscheiden, wo Ihr Team in diesem Punkt steht.

• Vergessen Sie nicht, dass das Lesen von Code eine Fähigkeit ist . Je mehr Sie es tun, desto besser werden Sie es verstehen. Ein anderer Weg, dies zu sagen, ist, dass der einzige Weg, gut darin zu werden, darin besteht, es viele Male zu üben. Wie oben erwähnt, ist und bleibt das Lesen von Code ein viel größerer Teil Ihrer Arbeit als das Schreiben.

Ich gehe davon aus, dass der Code nicht durch automatisierte Tests abgedeckt wird. Schritt Nr. 0 wäre, sofort zu bestellen und zu lesen, wie man mit Legacy-Code von Michael Feathers effektiv arbeitet . Es ist einfach von unschätzbarem Wert.

Die grundlegenden Schritte, die ich vorschlagen würde:

• Decken Sie den Code mit Tests ab, die die aktuelle Funktionalität abdecken.
• Refactor bis verständlich.
• Schreiben Sie einen Test für die neue oder geänderte Funktionalität.
• Implementieren Sie die neue Funktionalität.
• Refactor bis zur Zufriedenheit.

Ich verzichte bewusst auf die Angabe der Testvarianten (Unit, Integration, ...) - bekomme nur eine Art automatisierte Testabdeckung.

(und ja, befolgen Sie den Codierungsstil in Bezug auf Layout und Benennung)

Wie bereits erwähnt: Willkommen in der realen Welt. Ich kann mich nur früheren Antworten anschließen. Ich möchte die Antwort nur mit meiner Arbeitserfahrung über Zeitschätzungen erweitern.

Ein guter Vorschlag, um Ihnen klar zu machen, dass es einige Zeit dauern wird, bis Sie erfahren, wie die anderen Entwickler denken. Normalerweise werden Sie feststellen, dass die aktuelle Lösung häufig vom Alter und der Erfahrung des Entwicklers abhängt.

Wenn Sie Glück haben, muss die anstehende Aufgabe analysiert werden und das Verstehen der Dokumentation wird Ihnen sehr helfen (aber dies ist oft nicht der Fall).

Ich habe die Erfahrung gemacht, dass Sie beim Ändern des Codes anderer nicht versuchen, den Code zu ändern, der nicht Ihre aktuelle Aufgabe betrifft. Sie kennen vielleicht eine bessere Lösung oder sie könnte intuitiver geschrieben werden, aber Änderungen führen häufig zu Problemen wie:

• Die Aufgabe wird länger dauern und Ihr Chef wird es nicht verstehen.
• Der Code, den Sie ändern, muss getestet werden und kostet. Die aktuelle Lösung wurde getestet und genehmigt.
• Es wird schwierig zu erkennen sein, welche Änderungen die aktuelle Aufgabe lösen und welche nur Korrekturen sind.

Aber zögern Sie nicht, Ihrem Chef mitzuteilen, wenn Sie etwas sehen, von dem Sie denken, dass es anders sein sollte (es zeigt nur, dass Sie denken können).

Stellen Sie schließlich sicher, dass Sie genügend Zeit haben, um die Lösung zu finden. Eine schnellere Lösung kommt mit Erfahrung. Es gibt jedoch selten eine schnelle Lösung, da dies der erste / Hauptgrund für Fehler und nicht wartbaren Code ist.

Stellen Sie sich das vor, als würden Sie eine Operation an einer Person durchführen.

Sie suchen nach dem Problem, das Sie beheben müssen, und stellen fest, dass die meisten Arterien usw. nicht so eingerichtet sind, wie Sie es tun würden. Schneiden Sie sie ab und hacken Sie sie herum, bis es für Sie richtig aussieht, und beheben Sie dann das Problem.

Erstaunlicherweise stirbt Ihr Patient fast sofort.

Ältere Anwendungen sind identisch. Sie haben bereits eine Arbeitsweise - Sie müssen die verschiedenen Komponenten in der Software und deren Beziehung zueinander verstehen und dann Ihre Änderungen vornehmen, damit sie auf die gleiche Weise funktionieren. Es ist nicht aufregend, Ihrer Kreativität freien Lauf zu lassen, aber Sie können dies bei persönlichen Projekten tun.

Ich würde einen leitenden Ingenieur bitten, sich jeden Montag für etwa eine Stunde mit Ihnen zusammenzusetzen und einen anderen Aspekt des Systems zu erläutern. Notieren Sie sich, was er sagt, und senden Sie die Notizen per E-Mail an ihn und Ihren Manager, um festzustellen, ob Ihr Manager etwas hinzuzufügen hat. Sie sollten auf diese Weise ziemlich schnell auf dem Laufenden sein.

Stellen Sie zunächst sicher, dass Sie verstehen, was das System tut, um Dinge nicht zu beschädigen. Testen Sie vor - nehmen Sie Ihre Änderungen vor - testen Sie danach. Es gibt keine magischen Formeln; Wenn du Erfahrung sammelst, wirst du besser - oder du wirst gefeuert, denke ich!

Eine Sache, die ich hier nicht wirklich gesehen habe - arbeite nicht auf einer Insel.

Wenn Sie nicht der einzige Programmierer in Ihrem Outfit sind, gibt es bestimmt jemanden , der mehr Erfahrung als Sie hat, und möglicherweise viele Leute, auf die Sie sich stützen können.

Fragen stellen. Viele von ihnen.

Machen Sie sich keine Sorgen, jemanden zu "nerven" (aus vernünftigen Gründen) - ich möchte lieber, dass mich jemand während eines normalen Entwicklungszyklus für ein oder zwei Fragen unterbricht, als später in einer Produktionsumgebung ein Feuer löschen zu müssen.

Wenn Sie bereit sind, etwas einzuchecken, überprüfen Sie es mit Ihren Mentoren. Sie sollten Ihnen nicht nur sagen können, ob etwas anderes kaputt geht, sondern, was noch wichtiger ist, warum. Durch das Überprüfen des Codes wird der Mentor auch zu einem besseren Programmierer, der einen Einblick in das System erhält, den er ansonsten möglicherweise nicht so oft sieht.

Denken Sie daran: Sie lernen nicht nur das System, wie es jeder neue Mitarbeiter tun müsste, sondern Sie lernen auch, wie man Programmierer wird.

Und ermutigen Sie nach fünf Jahren den nächsten Neuen, Sie als Mentor einzusetzen.

Denken Sie beim Debuggen von Code daran: Es gibt immer einen Grund . Wenn Sie einige Tage lang versucht haben, denselben dummen Fehler zu finden und zu beheben, und Sie keine Fortschritte erzielen, ist es verlockend, sich eine oder mehrere der folgenden Fragen zu stellen:

• Ich bin einfach nicht schlau genug, um herauszufinden, wie dieser Code funktioniert

• Der Typ, der diesen Code schrieb, hatte keine Ahnung, was er tat

• Magie ist involviert: sehr schwarze Magie

Das sind alles Formen des Aufgebens. Das Gegenmittel ist, sich immer daran zu erinnern, dass Computer deterministisch sind: Es gibt immer einen Grund dafür, was sie tun. Der Code mag nach Ebbe in einer Fischkonservenfabrik riechen und einer riesigen Schüssel Linguine ähneln, aber wenn Sie unerbittlich rational und aufgeschlossen sind, werden Sie es herausfinden .

Unabhängig davon, ob Sie nach Möglichkeit Komponententests schreiben oder kleine Anwendungen mit dem zu ändernden Code schreiben, müssen Sie die Logik überprüfen, verstehen und anschließend dokumentieren.

Wenn der Code größtenteils funktioniert - hört sich so an -, würde ich den Stil der Code-Formatierung für dieses Modul beibehalten, unabhängig davon, ob es Ihr Stil ist oder nicht. Es hält die Dinge einheitlich. Gute Kommentare kommen jedoch nie aus der Mode.

Ich empfehle ein Testsystem und eine Testplattform, auf der Sie diesen Code ändern und testen können, ohne die Produktion zu unterbrechen.

Wenn Sie Elemente des Codes in einer Bibliothek entfernen können, würde ich es tun, es sei denn, Sie arbeiten an einer Bibliothek.

Sobald Sie die Logik verstanden haben, können Sie sie im Laufe der Zeit umschreiben und testen.

Dieser Rat ist abhängig von der Sprache, die Sie verwenden, der Fähigkeit, einen Prüfstand zu erhalten, und anderen Einschränkungen, die Sie haben.

Versuchen Sie, mit einigen Code Analyzer-Tools nicht verwendeten Code zu finden, der gelöscht werden kann. Sie müssen sich also zumindest nicht um diesen Code kümmern.

Es wurde oben angemerkt, dass Sie den Zweck des Systems verstehen müssen, nicht nur die Details des Codes. Ein Programmierer mit ausreichender Erfahrung, um ein Auftragserfassungssystem zu schreiben, ist im Allgemeinen mit dem Teil „Vorwärtsbewegung“ vertraut, bei dem Produkte ausgewählt, eine Rechnung formatiert und die Zahlung verarbeitet werden. Wenn der Benutzer feststeckt, entscheidet er, dass es ihm egal ist, und beginnt, Transaktionen zurückzusetzen, oder wenn er einen Fehler in der Zahlungsverarbeitung macht und auf die Schaltfläche "Zurück" klickt. Zu diesem Zeitpunkt sind viele Programmierer verblüfft, weil sie sehen, dass Code aus dem Nichts auftaucht und nicht herausfindet, warum er da ist.

Kurz gesagt, Sie müssen nicht nur den „normalen Ablauf“ verstehen, sondern auch die Rückverfolgung, die erforderlich ist, wenn jemand einen Fehler macht oder seine Meinung ändert. Dies wird noch schlimmer, wenn Supervisor-Overrides ausgeführt werden und einige Codes nur mit bestimmten Kontoberechtigungen ausgeführt werden können.

Wenn jemand 10.000 Codezeilen pro Jahr schreibt und eine Anwendung eine Lebensdauer von zehn Jahren hat, muss ein Programmierer, der für die Übernahme der Arbeit eines anderen verantwortlich ist, möglicherweise 100.000 Codezeilen verstehen. Teilen Sie dies durch 50 Zeilen pro Seite mit 2000 Seiten. Wenn das Programm in ein Entwurfsmuster geschrieben ist, wird der Programmierer feststellen, dass das Verständnis eines "Blocks" zumindest zu einem allgemeinen Verständnis der meisten anderen führt. Wenn nicht, dann ist es notwendig, jede letzte verdammte Zeile zu lesen.

Einige Programmierer tun einfach das, was ihnen gesagt wird, und schreiben Spaghetti. Sie verstehen nie das Gesamtbild - sie setzen einfach Korrekturen ein, wenn sich Benutzer beschweren. In einem solchen Fall ist es eine gute Idee, mit der Migration zu einem geeigneten Muster zu beginnen. Letztendlich kann dies bedeuten, dass Dinge neu codiert werden, die nicht "kaputt" sind. Mach dir keine Sorgen, stelle nur sicher, dass dein Projekt nach und nach besser gewartet werden kann.

Hier gibt es einige wirklich schöne Antworten. Aber ich denke, es kann auch erwähnenswert sein, wie viel Vertrautheit mit guten Entwurfsmustern dazu beitragen kann, vorhandenen Code zu lesen (gut geschrieben) und lesbaren Code zu schreiben.

Natürlich kann es sehr verwirrend sein, wenn Sie auf einen SomethingFactoryin der Fabrik vorhandenen Code stoßen , der tatsächlich nicht dem Muster folgt . Es kann jedoch von Vorteil sein, solche Fälle so gering wie möglich zu halten.

Das Befolgen von Entwurfsmustern (wo es die Geschäftsanforderungen erlauben) kann auch die Codeduplizierung erheblich reduzieren, was wiederum Fehler bei zukünftigen Änderungen verringert.

Einige gute Quellen für Entwurfsmuster sind

http://sourcemaking.com/design_patterns

http://www.oodesign.com/

und natürlich das Buch

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

Die Verfolgung des Kontrollflusses zwischen den Methoden ist sehr wichtig für die Entwicklung einer mentalen Abbildung der Geschäftslogik.

Unsere Lösung basiert auf der Erkenntnis, dass eines der wenigen vertrauenswürdigen Informationen, die bei der Annäherung an ein Altsystem verfügbar sind, das laufende System selbst ist. Unser Ansatz überprüft die Ausführungsspuren und verwendet die Logikprogrammierung, um Tests für sie durchzuführen.

Das Generieren eines Workflow-Datenmodells ist die beste Methode zum Analysieren aller Codepfade:

In der Praxis wird die Codeüberprüfung in früheren wissenschaftlichen Arbeitsabläufen unhandlich. Der Ursprung derartiger Workflows bedeutet, dass möglicherweise während der Entwicklung keine Softwareentwicklungspraktiken angewendet wurden, was zu einer Codebasis führt, die effektiv verschleiert wird. Während die statische Analyse gut entwickelte Techniken für die Datenflussanalyse aufweist, unterstützen sie das Verhalten in Workflows der realen Welt nicht. Zum Beispiel, wenn eine Konfigurationsdatei geladen werden muss, um zu bestimmen, wie Daten verarbeitet werden sollen, oder wenn die dynamische Codeauswertung verwendet wird.

Und die Visualisierung des Workflows ist ideal:

Ein allgemeines Motiv, das sich für die visuelle Entwicklung eignet, ist die Darstellung eines Workflows als Grafik. Dies schützt den Benutzer vor der zugrunde liegenden Komplexität von Ressourcen und Ausführung

Verweise

• Grundlegendes zu Legacy-Workflows mithilfe der Laufzeitanalyse (pdf)
• Trace-basiertes Testen von objektorientiertem Altsystem-Logik (pdf)
• console.trace () - Web-APIs | MDN
• Verfolgung von Methodenaufrufen über Proxies
• Wie Sie Ihre Ruby-Methoden ausspionieren
• Einfache Verfolgung verschachtelter Funktionsaufrufe auf der Website von Python - Eli Bendersky
• Protokollierung von Methodenein- und ausgängen - Mebyon Kernow
• Trace: Instrumentierung zur Anzeige von Funktionsaufrufen
• -Xtrace -
• GitHub - johnno1962 / SwiftTrace: Verfolgen von Swift- und Objective-C-Methodenaufrufen
• Debug :: Trace - Perl-Erweiterung zur Verfolgung von Unterprogrammaufrufen - metacpan.org

Stellen Sie sicher, dass Sie ein Programm verwenden, mit dem Sie nach Inhalten in der aktuellen Datei suchen können. Nichts ist schlimmer, als zu wissen, dass sich das Gesuchte in der aktuellen Datei befindet, aber Sie scrollen und scrollen und können es nicht finden. Eine Gliederungsansicht in dem Tool, mit dem Sie den Code bearbeiten, hilft bei diesem Problem wirklich.