it-swarm.com.de

Arbeiten am Code eines anderen

Ich habe kaum ein Jahr Erfahrung im Codieren. Nachdem ich angefangen hatte zu arbeiten, arbeitete ich die meiste Zeit am Code eines anderen, indem ich entweder neue Funktionen über die vorhandenen hinzufügte oder die vorhandenen Funktionen änderte. Der Typ, der den eigentlichen Code geschrieben hat, funktioniert 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 irgendwie mit den Arbeitsfunktionen herumgespielt. Was sollte ich alles beachten, wenn ich an dem Code eines anderen arbeite?

60
Xavi Valero

Hat der Code Unit-Tests? Wenn nicht, empfehle ich 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 von denen 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, diesen Code zu verstehen. Natürlich sollten Funktionstests hinzugefügt werden, wenn sie noch nicht vorhanden sind. Mein Eindruck war, dass diese bereits aus der OP-Frage existierten. Wenn ich mich in diesem Punkt irre, sollten diese Funktionstests Ihr erster Schritt sein.

Eagle76dk macht einen großartiger Punkt darüber, wie Sie Ihren Manager für diese Arbeit an Bord holen - weitere Details in Eagle76dks Beitrag.

Wenn Sie diese Tests schreiben, sollten Sie außerdem versuchen, die Tests so zu schreiben, dass sie das Geschäftsverhalten überprüfen, das die Methode möglicherweise versucht hat, und nicht das Codeverhalten. Gehen Sie auch überhaupt nicht 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 sagt.

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

46
Klee

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

Beginnen Sie mit einem Schritt durch die Hauptschleife/Hauptmethoden des Programms. Verwenden Sie die Funktionen Schritt in und Schritt aus, um zu sehen, was verschiedene Methoden tun. Dadurch lernen Sie die allgemeine Struktur des Codes kennen.

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 Studienvariablen und deren aktuelle Werte. 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 Aufrufstapel, um zu sehen, von wo aus diese Methode aufgerufen wird, usw. usw.

Wenn das Ändern einer Codezeile an anderen Stellen nerwartete Änderungen verursacht, setzen Sie einen Haltepunkt in diese Zeile und sehen Sie, was dort passiert, indem Sie beispielsweise die Werte der aktuellen Variablen im Gültigkeitsbereich überprüfen, indem Sie step in oder verwenden den Aufrufstapel, um zu sehen, woher der Anruf kam.

Auf diese Weise lernen Sie überraschend schnell die Struktur des Codes. 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 gleichzeitig daran arbeiteten. Zu diesem Zeitpunkt konnte ich noch nicht alles umschreiben. Das Schreiben von Tests für all diesen 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 ...

32
jake_hetfield

Das erste, was Sie beachten sollten, ist, dass mehr Zeit für das Lesen von Code als für das Schreiben von Code aufgewendet wird. 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 anpassen.

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

30
jmoreno

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

Aber sei immer misstrauisch.

Aber ja, es braucht Zeit, um den Code eines anderen Entwicklers zu verstehen. Je häufiger 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 des Zauns, nachdem die Daten geliefert wurden, aber bevor etwas anderes passiert.

Es ist ein schlechtes Zeichen, wenn eine Sache unerwartet eine andere bricht. Wenn Sie andere erfahrene Entwickler haben, auf die Sie sich verlassen können, würde ich empfehlen, dass sie sich mit Dingen befassen, die Ihnen Probleme bereiten. Zumindest können Sie ein paar Dinge aufgreifen, die Sie beim Debuggen beobachten.

21
Erik Reppen

In einer idealen Welt wird der gesamte von einem bestimmten Entwickler geschriebene Code gut dokumentiert, gut strukturiert und verständlich getestet, sowohl mit automatischen Tools wie Komponententests als auch mit Anwendungsfallskripten, die ein Benutzer durchläuft, um zu überprüfen, ob Sie das erwartete Ergebnis erhalten.

Das erste, was Sie 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 kurzer Überblick über den erwarteten normalen Anwendungsfall.

Wenn Sie mit Code wie diesem arbeiten, müssen Sie zunächst festlegen, was er tun soll. Wenn es Kommentare gibt, können sie Ihnen Hinweise geben, 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 um einiges einfacher machen. Wenn Sie dies nicht tun, besteht ein Teil des Lernens der Codebasis möglicherweise darin, Komponententests für bereits vorhandenen Code zu schreiben. Normalerweise wird dies nicht als bewährte Methode angesehen, da Sie beim Schreiben von Komponententests, die dem vorhandenen Code entsprechen, Komponententests erhalten, bei denen der Code wie er ist funktioniert (sie werden so geschrieben, dass davon ausgegangen wird, dass es sich tatsächlich um einen Fehler handelt richtig), aber zumindest gibt es Ihnen 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 so ändern, dass das erwartete Ergebnis und nicht das Ergebnis, das der Code jetzt liefert, überprüft wird. Sobald Sie einen Komponententest durchgeführt haben, können Sie Änderungen vornehmen und bewerten, welche Nebenwirkungen Änderungen haben.

Die beste Ressource, die Sie beim Umgang mit einem undokumentierten Code haben, besteht darin, die Endbenutzer zu fragen. Sie wissen vielleicht nichts über Code, aber sie wissen, was die Anwendung tun soll. Das Sammeln von Anforderungen ist die erste Phase eines Projekts, und das Gespräch mit den potenziellen Benutzern des zu entwickelnden Systems ist immer ein wichtiger Bestandteil davon. Stellen Sie sich vor, Sie führen die Anforderungserfassungsphase für ein neues Projekt durch, das gerade bereits erstellt wurde.

Denken Sie daran, dass selbst gut geschriebener und gut 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, in den Denkprozess einer anderen Person einzusteigen, aber es ist eine wesentliche Fähigkeit für einen Programmierer, der vorhandenen Code wartet. Da der größte Teil der Codierung (ca. 70%) mit der Pflege des vorhandenen Codes zusammenhängt, ist es eine wichtige Fähigkeit, diese zu erlernen.

Oh, und jetzt, da Sie den Schmerz gesehen haben, den schlecht dokumentierter, ungetesteter und durcheinandergebrachter Code verursachen kann, werden Sie es nicht dem nächsten armen Entwickler antun, der mitkommt, oder? :) 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 der es festhält, und stellen Sie sicher, dass Sie über umfassende Komponententests verfügen, die Sie entweder zuerst schreiben (für TDD-Methoden) oder Zumindest neben dem Code, der entwickelt wird.

14
GordonM

Denken Sie daran, dass die Fähigkeit, Code zu lesen, den Sie nicht geschrieben haben, eine sehr wertvolle Fähigkeit ist, wahrscheinlich wertvoller als das Schreiben von Code. Leider wird dies an Schulen weitgehend unterschätzt und unterschätzt.

Ich versuche zu sagen, dass es normal ist, dass Sie Code beim ersten Lesen nicht immer verstehen (genau wie es normal ist, dass Sie beim ersten Mal keinen perfekten Code schreiben). Wenn Sie akzeptieren, dass es einige Zeit dauert, einen Fremdcode zu erhalten, 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 hoher Bürokratie arbeiten.

  • Erfahren Sie, wie Sie Ihr Versionskontrollsystem richtig verwenden. Sie werden niemals das Bestehende brechen (nicht wirklich niemals , 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 gut ist, nur weil es funktioniert. Wichtig ist, dass Sie den Codestil des vorherigen Betreuers verstehen und Ihre hinzugefügten Zeilen an seinen Stil anpassen. Der Betreuer, der nach Ihnen kommt, wird es Ihnen 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 bevorzugen oft (implizit) den Push-Code, der schnell funktioniert, anstatt sich Zeit zu nehmen, um etwas Sauberes zu schreiben. Ich überlasse es Ihnen zu entscheiden, wo Ihr Team in diesem Punkt steht.

  • Vergessen Sie niemals, dass das Lesen von Code eine Fähigkeit ist. Je mehr Sie es tun, desto besser werden Sie darin. Eine andere Möglichkeit, dies zu sagen, besteht darin, dass der einzige Weg, um 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.

13
rahmu

Nach Ihren Problemen mit versehentlichem Brechen von Dingen zu urteilen, gehe ich davon aus, dass der Code nicht durch automatisierte Tests abgedeckt wird. Schritt # 0 wäre, sofort zu bestellen und zu lesen Effektiv mit Legacy-Code arbeiten von Michael Feathers. 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 darauf, den Geschmack der Tests (Einheit, Integration, ...) anzugeben - erhalte einfach eine Art automatisierte Testabdeckung.

(und, ja, folgen Sie dem Codierungsstil in Bezug auf Layout und Benennung)

11
rjnilsson

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

Ein guter Vorschlag, um Ihren Chef klar zu machen, es wird einige Zeit dauern, um zu lernen, 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 Verständnis der Dokumentation hilft Ihnen sehr (dies ist jedoch häufig nicht der Fall).

Ich habe die Erfahrung gemacht, dass Sie beim Ändern des Codes anderer versuchen, den Code nicht zu ändern, der Ihre aktuelle Aufgabe nicht betrifft. Möglicherweise kennen Sie eine bessere Lösung oder sie könnte intuitiver geschrieben werden. Eine Änderung führt jedoch 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 sein zu erkennen, welche Änderungen die aktuelle Aufgabe lösen und welche "nur" Korrekturen sind.

Aber zögern Sie nicht, Ihrem Chef zu sagen, 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.

10
Eagle76dk

Stellen Sie sich vor, Sie führen eine Operation an einer Person durch.

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. Sie schneiden und hacken sie also herum, bis es für Sie richtig aussieht, und beheben dann das Problem.

Erstaunlicherweise stirbt Ihr Patient fast sofort.

Legacy-Anwendungen sind gleich. Sie haben bereits eine Arbeitsweise - Sie müssen die verschiedenen Komponenten in der Software und ihre 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 etwa eine Stunde lang mit Ihnen zusammenzusetzen und einen anderen Aspekt des Systems zu erklären. Machen Sie sich Notizen zu dem, 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. Auf diese Weise sollten Sie sich schnell auf den neuesten Stand bringen.

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

5
Stefan

Eine Sache, die ich hier nicht wirklich angesprochen 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, die Sie lernen können auf.

Fragen stellen. Viele von ihnen.

Machen Sie sich keine Sorgen, dass Sie jemanden (im Rahmen der Vernunft) "nerven" - 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 Ihrem/Ihren Mentor (en). Sie sollten Ihnen nicht nur sagen können, ob etwas etwas anderes kaputt macht, sondern vor allem, warum. Durch das Überprüfen des Codes wird der Mentor auch zu einem besseren Programmierer, der ihm einen Einblick in das System gibt, den er sonst möglicherweise nicht so oft betrachtet.

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

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

3
Wonko the Sane

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 machen, ist es verlockend, an eines oder mehrere der folgenden Themen zu denken:

  • Ich bin einfach nicht klug 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 für das, 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 offen sind, werden Sie es herausfinden.

2
Caleb

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

Wenn der Code meistens 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 denen Sie diesen Code ändern und testen können, ohne die Produktion zu unterbrechen.

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

Mit der Zeit können Sie, sobald Sie die Logik verstanden haben, neu schreiben und testen.

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

1
octopusgrabbus

Versuchen Sie, einige Code-Analysetools zu verwenden, um nicht verwendeten Code zu finden, der gelöscht werden kann. Sie müssen sich also zumindest nicht um diesen Code kümmern.

1
FrVaBe

Es wurde oben angemerkt, dass Sie den Zweck des Systems verstehen müssen, nicht nur die Details des Codes. Ein Programmierer, der über genügend Erfahrung verfügt, um ein Auftragserfassungssystem zu schreiben, ist im Allgemeinen mit dem Teil "Weitergehen" vertraut, bei dem Produkte ausgewählt, eine Rechnung formatiert und die Zahlung verarbeitet werden. Sie bleiben hängen, wenn der Benutzer "Nein, egal" entscheidet und beginnt, Transaktionen zurückzusetzen, oder wenn er einen Fehler in der Zahlungsabwicklung 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 herausfinden kann, warum er dort ist.

Kurz gesagt, Sie müssen nicht nur den „normalen Ablauf“ verstehen, sondern auch das gesamte Backtracking, das erforderlich ist, wenn jemand einen Fehler macht oder seine Meinung ändert. Dies wird noch schlimmer bei Supervisor-Überschreibungen, bei denen Code nur mit bestimmten Kontoberechtigungen ausgeführt werden kann.

Wenn jemand 10.000 Codezeilen pro Jahr schreibt und eine Anwendung eine Lebensdauer von zehn Jahren hat, muss ein Programmierer, der für die Arbeit eines anderen verantwortlich ist, möglicherweise 100.000 Codezeilen verstehen. Teilen Sie dies durch 50 Zeilen pro Seite auf 2000 Seiten. Wenn das Programm in ein Entwurfsmuster geschrieben wird, 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 wurde, und schreiben Spaghetti. Sie verstehen das große Ganze nie - sie korrigieren es einfach, wenn sich Benutzer beschweren. In einem solchen Fall ist es eine gute Idee, mit der Migration von allem, was Sie können, in ein geeignetes Muster zu beginnen. Letztendlich kann dies bedeuten, dass Dinge neu codiert werden, die nicht "kaputt" sind. Machen Sie sich keine Sorgen, stellen Sie nur sicher, dass Ihr Projekt immer besser gewartet werden kann, solange es sich um Ihr Projekt handelt.

1
Meredith Poor

Hier gibt es einige wirklich nette Antworten. Aber ich denke, es kann auch erwähnenswert sein, wie viel Vertrautheit mit gutem Entwurfsmuster helfen kann, vorhandenen Code zu lesen (gut geschrieben) und lesbaren Code zu schreiben.

Natürlich kann es sehr verwirrend sein, wenn Sie in vorhandenem Code auf ein SomethingFactory stoßen, das nicht dem Fabrikmuster folgt. Aber so viel Ihr Team und Ihr Framework erlauben, kann es vorteilhaft sein, solche Fälle auf ein Minimum zu beschränken.

Das Befolgen von Entwurfsmustern (sofern die geschäftlichen Anforderungen dies zulassen) 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

0
Nameless One

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

Unsere Lösung basiert auf der Erkenntnis, dass eine der wenigen vertrauenswürdigen Informationen, die verfügbar sind, wenn Sie sich einem Legacy-System nähern, das laufende System selbst ist. Unser Ansatz überprüft die Ausführungsspuren und verwendet Logikprogrammierung, um Tests für sie auszudrücken.

Das Generieren eines Workflow-Datenmodells ist der beste Weg, um alle Codepfade zu analysieren:

In der Praxis wird die Codeüberprüfung in älteren wissenschaftlichen Workflows unhandlich. Der Ursprung solcher Workflows bedeutet, dass während der Entwicklung möglicherweise 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 hat, unterstützen sie das Verhalten in realen Workflows nicht. Zum Beispiel, wenn eine Konfigurationsdatei geladen werden muss, um zu bestimmen, wie Daten verarbeitet werden sollen, oder wenn die dynamische Code-Auswertung verwendet wird.

Die Visualisierung des Workflows ist ideal:

Ein häufiges 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

Referenzen

0
Paul Sweatte