it-swarm-eu.dev

Wie taucht man in große Codebasen ein?

Welche Tools und Techniken verwenden Sie, um eine unbekannte Codebasis zu erkunden und zu lernen?

Ich denke an Werkzeuge wie grep, ctags, Komponententests, Funktionstests, Klassendiagrammgeneratoren, Aufrufdiagramme, Codemetriken wie sloccount und so weiter. Ich würde mich für Ihre Erfahrungen, die Helfer, die Sie selbst verwendet oder geschrieben haben, und die Größe der Codebasis interessieren, mit der Sie gearbeitet haben.

Mir ist klar, dass das Kennenlernen einer Codebasis ein Prozess ist, der im Laufe der Zeit abläuft, und Vertrautheit kann alles von "Ich kann den Code zusammenfassen" bis zu "Ich kann ihn umgestalten und auf 30% der Größe verkleinern" bedeuten. Aber wie soll ich überhaupt anfangen?

145
miku

was ich immer getan habe, ist Folgendes:

Öffnen Sie mehrere Kopien meines Editors (Visual Studio/Eclipse/Whatever) und debuggen Sie und führen Sie Zeilenumbrüche durch den Code. Finden Sie den Codefluss heraus, stapeln Sie die Ablaufverfolgung, um zu sehen, wo sich die wichtigsten Punkte befinden, und gehen Sie von dort aus.

Ich kann Methode für Methode betrachten - aber es ist schön, wenn ich auf etwas klicken und dann sehen kann, wo im Code es ausgeführt wird, und mitmachen kann. Lassen Sie mich ein Gefühl dafür bekommen, wie der Entwickler wollte, dass die Dinge funktionieren.

55
ist_lion

Wie isst du einen Elefanten?

Ein Bissen nach dem anderen :)

Im Ernst, ich versuche zuerst mit den Autoren des Codes zu sprechen.

64
user2567

Muss ich hacken, bis ich den Job erledigt habe?

Zu einem großen Teil ja (sorry).

Ansätze, die Sie in Betracht ziehen könnten:

  1. Versuchen Sie herauszufinden, was der Code in geschäftlicher Hinsicht tun soll.
  2. Lesen Sie die gesamte vorhandene Dokumentation, egal wie schlimm sie ist.
  3. Sprechen Sie mit jedem, der etwas über den Code weiß.
  4. Gehen Sie den Code im Debugger durch.
  5. Führen Sie kleine Änderungen ein und sehen Sie, was kaputt geht.
  6. Nehmen Sie kleine Änderungen am Code vor, um ihn klarer zu gestalten.

Einige der Dinge, die ich tue, um Code zu klären, sind:

  1. Führen Sie einen Code-Prettifier aus, um den Code gut zu formatieren.
  2. Fügen Sie Kommentare hinzu, um zu erklären, was ich denke, dass es tun könnte
  3. Ändern Sie die Variablennamen, um sie klarer zu machen (mithilfe eines Refactoring-Tools).
  4. Verwenden eines Werkzeugs, das alle Verwendungen eines bestimmten Symbols hervorhebt
  5. Reduzieren der Unordnung im Code - auskommentierter Code, bedeutungslose Kommentare, sinnlose Variableninitialisierungen usw.
  6. Ändern Sie den Code, um die aktuellen Codekonventionen zu verwenden (erneut mithilfe von Refactoring-Tools).
  7. Beginnen Sie, Funktionen in sinnvolle Routinen zu extrahieren
  8. Fügen Sie nach Möglichkeit Tests hinzu (nicht oft möglich).
  9. Magische Zahlen loswerden
  10. Reduzieren Sie Doppelarbeit, wo dies möglich ist

... und welche anderen einfachen Verbesserungen Sie auch vornehmen können.

Allmählich sollte die Bedeutung dahinter klarer werden.

Wie für den Ort zu beginnen? Beginnen Sie mit dem, was Sie wissen. Ich schlage Ein- und Ausgänge vor. Sie können oft einen Überblick darüber bekommen, was diese sein sollen und wofür sie verwendet werden. Verfolgen Sie die Daten in der Anwendung und sehen Sie, wohin sie gehen und wie sie geändert werden.

Eines der Probleme, die ich bei all dem habe, ist die Motivation - es kann ein echter Slog sein. Es hilft mir, das ganze Geschäft als Puzzle zu betrachten und die Fortschritte zu feiern, die ich mache, egal wie klein sie sind.

39
Kramii

Ihre Situation ist tatsächlich häufig. Jeder, der in einen neuen Job eintreten muss, in dem Code vorhanden ist, mit dem er arbeiten kann, wird sich mit einem Element davon befassen. Wenn das System ein wirklich böses Legacy-System ist, dann ist es dem, was Sie beschrieben haben, sehr ähnlich. Natürlich gibt es keine aktuelle Dokumentation.

Erstens haben viele empfohlen Effektiv mit Legacy-Code arbeiten von Michael Feathers. Dies ist in der Tat ein gutes Buch mit nützlichen Kapiteln wie "Ich kann diese Klasse nicht in ein Testgeschirr integrieren" oder "Meine Anwendung hat keine Struktur", obwohl Federn manchmal nur mehr Sympathie als Lösung bieten können. Insbesondere das Buch und seine Beispiele sind weitgehend auf geschweifte Klammern ausgerichtet. Wenn Sie mit knorrigen SQL-Prozeduren arbeiten, ist dies möglicherweise nicht ganz so nützlich. Ich denke, das Kapitel "Ich verstehe diesen Code nicht gut genug, um ihn zu ändern" spricht Ihr Problem an. Feathers erwähnt hier die offensichtlichen Dinge wie Notizen machen und Einträge markieren, macht aber auch einen guten Punkt, dass Sie nicht verwendeten Code löschen können, wenn Sie über Quellcodeverwaltung verfügen. Viele Leute lassen kommentierte Codeabschnitte an Ort und Stelle, aber das hilft oft nicht weiter.

Als nächstes denke ich, dass Ihr vorgeschlagener Ansatz sicherlich ein guter Schritt ist. Sie müssen zuerst auf hoher Ebene verstehen, was der Zweck des Codes ist.

Arbeiten Sie auf jeden Fall mit einem Mentor oder jemandem im Team zusammen, wenn Sie Fragen beantworten müssen.

Nutzen Sie auch die Gelegenheit, den Code zu unterstützen, wenn Fehler aufgedeckt werden (obwohl Sie sich manchmal nicht freiwillig dafür melden müssen ... der Fehler wird Sie finden!). Benutzer können erklären, wofür sie die Software verwenden und wie sich der Fehler auf sie auswirkt. Dies kann oft ein sehr nützliches Wissen sein, wenn Sie versuchen, die Bedeutung der Software zu verstehen. Darüber hinaus kann es manchmal hilfreich sein, in den Code mit einem gezielten Angriffsziel einzusteigen, um sich auf "das Biest" zu konzentrieren.

32
Bernard Dy

Ich mache gerne Folgendes, wenn ich eine wirklich große Quelldatei habe:

  • Kopieren Sie das ganze Durcheinander in die Zwischenablage
  • In Word/Textmate einfügen, was auch immer
  • Reduzieren Sie die Schriftgröße auf ein Minimum.
  • Scrollen Sie nach unten und sehen Sie sich die Muster im Code an

Sie werden erstaunt sein, wie seltsam vertraut der Code aussieht, wenn Sie zu Ihrem normalen Editor zurückkehren.

13
sal

Es braucht Zeit

Fühlen Sie sich nicht zu gehetzt, wenn Sie versuchen, eine ältere Codebasis zu verstehen, insbesondere wenn Technologien/Sprachen/Frameworks verwendet werden, mit denen Sie nicht vertraut sind. Es ist nur eine unvermeidbare Lernkurve, die einige Zeit in Anspruch nimmt.

Ein Ansatz besteht darin, zwischen dem Code und den Tutorials zu den verwandten Technologien hin und her zu wechseln. Sie lesen/sehen sich das Tutorial an und sehen sich dann den Code an, um zu sehen, wie Ihre Vorgänger es gemacht haben. Sie stellen Ähnlichkeiten und Unterschiede fest, machen sich Notizen und stellen Fragen an vorhandene Entwickler.

"Warum hast du diesen Teil so gemacht?"

"Mir ist aufgefallen, dass die meisten Leute online es so machen, und Sie alle haben es anders gemacht. Warum ist das so?"

"Warum haben Sie sich alle für Technologie X gegenüber Technologie Y entschieden?"

Die Antworten auf diese Fragen helfen Ihnen, die Geschichte des Projekts und die Gründe für Entwurfs- und Implementierungsentscheidungen zu verstehen.

Schließlich werden Sie sich so vertraut fühlen, dass Sie anfangen können, Dinge hinzuzufügen/zu reparieren. Wenn alles verwirrend erscheint oder es so aussieht, als ob zu viel "Magie" vor sich geht, haben Sie nicht genug Zeit damit verbracht, es zu untersuchen, zu verdauen und grafisch darzustellen. Das Erstellen von Diagrammen (Sequenzdiagramme, Prozessflussdiagramme usw.) ist eine hervorragende Möglichkeit, einen komplexen Prozess zu verstehen, und sie helfen dem "nächsten Mann".

12
CFL_Jeff

cscope kann alles tun, was ctags für C tun können, und es kann auch auflisten, wo alle aktuellen Funktionen aufgerufen werden. Außerdem ist es sehr schnell. Skaliert leicht auf Millionen von LOC. Integriert sich nahtlos in Emacs und Vim.

C- und C++ - Codezähler - cccc kann Codemetriken im HTML-Format generieren. Ich habe wc auch benutzt, um LOC zu bekommen.

doxygen kann in HTML Syntax hervorheben und Code mit Querverweisen generieren. Nützlich beim Durchsuchen einer großen Codebasis.

9
aufather

Die Art und Weise, die ich mit Drupal und es ist nicht wirklich Drupal spezifisch) empfehle: Beginnen Sie mit dem Issue-Tracker. Es wird sicher alte, nicht geschlossene Fehlerberichte geben. Können Sie Wenn ja, aktualisieren Sie das Ticket, indem Sie es bestätigen. Wenn nein, schließen Sie es. Auf diese Weise finden Sie unzählige Möglichkeiten, die Software zu verwenden, und Sie können beginnen, in die Codebasis zu spähen, in der sie abstürzt. Oder Sie können mit dem Schritt beginnen Sehen Sie sich den Code an und sehen Sie, wie er dort ankommt, wo er abstürzt. Auf diese Weise beginnen Sie nicht nur, die Codebasis zu verstehen, sondern sammeln auch eine Menge Karma an, und Ihre Fragen werden von der Community sehr begrüßt.

8
chx

Eine wichtige Sache ist die Verwendung von Werkzeugen, um Abhängigkeitsgraphen zu generieren , um die Codearchitektur von oben nach unten zu erkunden. Visualisieren Sie zuerst ein Diagramm zwischen .NET-Assemblys oder -Jars. Auf diese Weise erhalten Sie eine Vorstellung davon, wie Features und Layer organisiert sind. Anschließend können Sie in Namespace-Abhängigkeiten (innerhalb einer oder mehrerer verwandter .NET-Assemblys oder -Jars) graben, um eine genauere Vorstellung von Code zu erhalten Struktur und schließlich können Sie Klassenabhängigkeiten betrachten, um zu verstehen, wie eine Reihe von Klassen zusammenarbeitet, um eine Funktion zu implementieren. Es gibt verschiedene Tools zum Generieren eines Abhängigkeitsdiagramms, z. B. NDepend für .NET , mit denen das folgende Diagramm generiert wurde.

enter image description here

Ein fantastischer Softwareentwickler hat mir einmal erzählt, dass die teuerste Form der Codeanalyse und -wartung darin bestand, den Code Zeile für Zeile durchzugehen. Natürlich sind wir Programmierer, und das kommt ziemlich genau mit dem Job. Ich denke, das glückliche Medium ist (in dieser Reihenfolge): 1. Besorgen Sie sich ein Notizbuch, um Notizen zu erstellen, wie Sie den Code verstehen, und fügen Sie ihn im Laufe der Zeit hinzu. 2. Lesen Sie die Dokumentation zum Code 3. Sprechen Sie mit Autoren oder anderen Personen, die die Codebasis unterstützt haben. Bitten Sie sie um einen "Brain Dump". 4. Wenn Sie an einem Punkt angelangt sind, an dem Sie einige der Klassenbeziehungen auf Detailebene verstehen, führen Sie ein schrittweises Debuggen des Codes durch, um eine Synthese zwischen der Funktionsweise des Codes und der Funktionsweise des Codes zu erstellen wie der Code tatsächlich funktioniert.

5
Tim Claason

Verstehe zuerst, was es zu tun hat - ohne das ist es wahrscheinlich Kauderwelsch. Sprechen Sie mit den Benutzern, lesen Sie das Handbuch, was auch immer.

Klicken Sie dann auf "Ausführen" und beginnen Sie, den Code für die scheinbar wichtigsten Funktionen zu durchlaufen.

5
Jon Hopkins

Teilen und erobern. Ich schaue mir jede Funktionalität und den zugehörigen Code an, gehe sie durch und gehe zur nächsten über, wobei ich langsam ein Bild des Ganzen aufbaue.

Wenn das Projekt Unit-Tests hatte, gehe ich sie auch gerne durch, sie sind immer sehr aufschlussreich und aufschlussreich.

3
aredkid
  1. Führen Sie alle Tests aus, falls vorhanden, und prüfen Sie, welcher Code abgedeckt ist und welcher nicht.
  2. Wenn Code, den Sie ändern müssen, nicht behandelt wird, versuchen Sie, Tests zu schreiben, um ihn abzudecken.
  3. Ändern Sie den Code. Brechen Sie die Tests nicht.

Siehe Michael Feathers 'Effektiv mit Legacy-Code arbeiten

3
kevin cline

Hier ist meine kurze Liste:

  1. Wenn möglich, lassen Sie jemanden den Code auf hoher Ebene anzeigen. Welche Muster wurden berücksichtigt, welche Arten von Konventionen könnte ich erwarten usw. Dies kann einige Runden dauern, da ich am Anfang eine Geschichte bekommen würde, in der ich neue Fragen haben könnte, wenn ich mich mit dem Code vertraut mache zu fragen, wie ich die Zwiebel des bereits bestehenden Projekts durcharbeite.

  2. Führen Sie den Code aus und sehen Sie, wie die Systeme aussehen. Zugegeben, es kann mehr als ein paar Fehler geben, aber dies kann nützlich sein, um eine Vorstellung davon zu bekommen, was es tut. Hier geht es nicht darum, den Code zu ändern, sondern nur zu sehen, wie dies abläuft. Wie passen verschiedene Teile zusammen, um ein Gesamtsystem zu bilden?

  3. Suchen Sie nach Tests und anderen Indikatoren für die grundlegende Dokumentation, die beim Aufbau eines internen mentalen Modells des Codes hilfreich sein können. Hier würde ich wahrscheinlich mindestens ein paar Tage vorschlagen, es sei denn, es gibt natürlich extrem wenig Dokumentation und Tests.

  4. Wie gut kenne ich die in diesem Projekt verwendeten Sprachen und Frameworks? Die Wichtigkeit hier ist der Unterschied zwischen dem Betrachten einiger Dinge und dem Sagen: "Ja, das habe ich ein Dutzend Mal zuvor gesehen und weiß es ziemlich gut" und "Was in aller Welt wird hier versucht? Wer hielt das für eine gute Idee?" Fragen, die ich zwar nicht laut aussprechen würde, aber ich würde sie mir besonders überlegen, wenn ich mir Legacy-Code anschaue, der möglicherweise sehr zerbrechlich ist und die Leute, die ihn geschrieben haben, entweder nicht verfügbar sind oder sich einfach nicht daran erinnern, warum Die Dinge wurden so gemacht, wie sie waren. Für neue Bereiche kann es sich lohnen, etwas mehr Zeit damit zu verbringen, sich über die Struktur und die Muster in diesem Code zu informieren.

Last but not least: Kennen Sie die Erwartungen derjenigen, die das Projekt leiten, in Bezug auf das, was Sie zu jedem Zeitpunkt tun sollen, angesichts der folgenden wenigen Ideen, was zu erwarten ist:

  • Setzen Sie neue Funktionen ein?
  • Beheben Sie Fehler?
  • Refactoring Sie Code? Sind die Standards für Sie neu oder sind sie sehr vertraut?
  • Solltest du dich nur mit der Codebasis vertraut machen?
3
JB King

Ich würde sagen, mit Dokumentation usw. zu beginnen, aber meiner Erfahrung nach ist die Tiefe der Dokumentation und das lokale Wissen oft umgekehrt proportional zum Alter, zur Größe und zur Komplexität eines Systems.

Davon abgesehen versuche ich normalerweise, ein paar funktionale Threads zu identifizieren. Mit funktional meine ich Dinge wie Anmelden, Abrufen einer Kundenliste usw. Wenn die Muster überhaupt konsistent sind, sollte ein Thread Ihnen einen schönen, nicht unbedingt vollständigen Querschnitt des Systems geben. Der beste Weg, um festzustellen, ob die Muster konsistent sind, besteht darin, eine Handvoll Threads zu analysieren.

Ich denke, das ist selbstverständlich, aber meiner Meinung nach ist es besser, das System aus einer funktionalen Perspektive als aus einer technischen Perspektive zu verstehen. Ich mache mir im Allgemeinen keine allzu großen Sorgen um die verwendeten Tools (ORMs, Protokollierungsbibliotheken usw.) und konzentriere mich mehr auf die verwendeten Muster (MVP usw.). Nach meiner Erfahrung sind Werkzeuge im Allgemeinen flüssiger als Muster.

2
Casey

Drucken Sie den Quellcode aus und lesen Sie ihn durch. Wenn es besonders groß ist, drucken Sie nur ausgewählte Teile aus, um es besser zu verstehen, und machen Sie so viele Notizen/Kommentare, wie Sie benötigen.

Verfolgen Sie das Programm ab dem Beginn seiner Ausführung. Wenn Sie einem bestimmten Teil der Codebasis zugewiesen sind, verfolgen Sie die Ausführung innerhalb dieses Teils und finden Sie heraus, welche Datenstrukturen verwendet werden.

Wenn Sie eine objektorientierte Sprache verwenden, versuchen Sie, ein allgemeines Klassendiagramm zu erstellen. Dies gibt Ihnen einen guten Überblick auf hoher Ebene.

Leider müssen Sie am Ende so viel Code wie möglich durchlesen. Wenn Sie Glück haben, haben die vorherigen Programmierer so viel Dokumentation wie möglich geschrieben, damit Sie besser verstehen, was los ist.

2
Rudolf Olah

Ich versuche immer, mit dem Einstiegspunkt in das Programm zu beginnen, da alle Programme einen haben (zB Hauptmethode, Hauptklasse, Init usw.). Dies zeigt mir dann, was begonnen wird und manchmal, wie Dinge miteinander verbunden sind.

Danach mache ich einen Drilldown. Die Datenbank und das DAO sind irgendwo konfiguriert, sodass ich einen Eindruck davon bekomme, wie die Dinge gespeichert sind. Vielleicht wird auch eine Art globale Instanzklasse gestartet, und dort kann ich herausfinden, was gespeichert wird. Und mit guten Refraktor-Werkzeugen kann ich herausfinden, wer was nennt.

Ich versuche dann herauszufinden, wo die Schnittstelle konfiguriert und gehandhabt wird, da dies der nächste Einstiegspunkt für Informationen ist. Refraktor-, Such- und Debugging-Tools helfen bei meiner Suche. Ich kann dann herausfinden, wo der Umgang mit Informationen beginnt und endet, und mich durch alle Klassendateien arbeiten.

Ich versuche dann, den Fluss auf Papier zu schreiben, nur um meinen Kopf zunächst um die Dinge zu wickeln. Die Schaltfläche "Senden" wird an die generische Überprüfung übergeben, die dann an das DAO oder die Datenbank übergeben und dann in der Datenbank gespeichert wird. Dies ist eine grobe Vereinfachung der meisten Apps, aber es ist die allgemeine Idee. Stift und Papier sind hier äußerst hilfreich, da Sie alles schnell aufschreiben können und sich nicht um die Formatierung in einem Programm kümmern müssen, das Ihnen helfen sollte.

2
TheLQ

Einige Dinge, die ich tue ...

1) Verwenden Sie ein Quellenanalysetool wie Source Monitor , um die verschiedenen Modulgrößen, Komplexitätsmetriken usw. zu bestimmen, um ein Gefühl für das Projekt zu bekommen und die Bereiche zu identifizieren, die nicht trivial sind.

2) Bohren Sie den Code von oben nach unten in Eclipse (gut, um einen Editor zu haben, der Referenzen usw. durchsuchen kann), bis ich weiß, was los ist und wo in der Codebasis.

3) Gelegentlich zeichne ich Diagramme in Visio , um ein besseres Bild der Architektur zu erhalten. Dies kann auch für andere im Projekt hilfreich sein.

2
JeffV

Das erste, was Sie tun müssen, um eine neue Codebasis zu erlernen, ist zu lernen, was sie tun soll, wie sie verwendet wird und wie sie verwendet wird. Schauen Sie sich dann die Architekturdokumentation an, um zu erfahren, wie der Code aufgebaut ist, und sehen Sie sich an dieser Stelle auch die Datenbank an. Gleichzeitig lernen Sie die Architektur kennen. Dies ist ein guter Zeitpunkt, um Prozessabläufe oder Anwendungsfalldokumente zu überprüfen. Beginnen Sie dann mit dem Eintauchen und Lesen von Code, nachdem Sie das Gesamtbild verstanden haben, aber nur Code, der sich auf Arbeiten bezieht, die Sie möglicherweise an diesem Code ausführen. Versuchen Sie nicht nur, den gesamten Code zu lesen. Es ist wichtiger zu wissen, wo der Code X ausführen soll, als genau, wie X ausgeführt wird. Der Code ist immer da, um Ihnen zu sagen, wie Sie ihn finden können.

Ich finde, dass der Versuch, Code einzuspringen und zu lesen, ohne ein Ziel zu haben, das über das Erlernen des Codes hinausgeht, im Allgemeinen unproduktiv ist. Der Versuch, kleine Änderungen selbst vorzunehmen oder den Code der Änderungen eines anderen zu überprüfen, ist eine weitaus produktivere Nutzung Ihrer Zeit.

2
Ryathal

Wenn eine Codebasis groß ist, konzentrieren Sie sich auf die Teile, an denen gerade gearbeitet wird. Andernfalls fühlen Sie sich überfordert und möglicherweise explodiert Ihr Kopf. Ich denke, eine Übersicht auf hoher Ebene ist hilfreich (falls verfügbar), aber wahrscheinlich verbringen Sie viel Zeit im Debugger, um den Programmablauf zu verfolgen. Es ist eine gute Idee, sich einen Überblick über die Anwendung zu verschaffen und zu sehen, wie sie verwendet wird, damit Sie verstehen, wie/wofür/warum der Code verwendet wird.

Normalerweise führe ich eine Art Code-Komplexitäts-Tool für den Code aus, um zu erfahren, wo sich die Problembereiche befinden. Bereiche mit hoher Punktzahl sind wahrscheinlich sehr schwer zu aktualisieren. Zum Beispiel bin ich auf eine Funktion gestoßen, die auf der zyklomatischen Skala 450 Punkte erzielte. Sicher genug, Hunderte von IFs. Sehr schwer zu pflegen oder zu ändern. Seien Sie also auf das Schlimmste vorbereitet.

Haben Sie auch keine Angst, bestehenden Entwicklern Fragen zu stellen, insbesondere wenn sie am System gearbeitet haben. Behalten Sie Ihre inneren Gedanken für sich und konzentrieren Sie sich auf die Lösung der Probleme. Vermeiden Sie Kommentare, die die anderen Entwickler verärgern könnten. Schließlich kann es ihr Baby sein und niemand mag es, wenn ihm gesagt wird, dass sein Baby hässlich ist.

Machen Sie kleine Schritte, selbst die kleinste Codeänderung kann große Auswirkungen haben.

Ich finde es hilfreich, Programmcode-Flows zu erstellen. Wenn ich also Änderungen vornehme, kann ich nach Abhängigkeiten suchen, um zu sehen, welche Methoden/Funktionen was aufrufen. Angenommen, ich ändere Methode C.

Wenn nur 1 Methode/Funktion C aufruft, ist dies eine ziemlich sichere Änderung. Wenn Hunderte von Methoden/Funktionen C aufrufen, ist dies von größerer Bedeutung.

Hoffentlich ist Ihre Codebasis gut aufgebaut, geschrieben und gepflegt. Wenn ja, wird es einige Zeit dauern, um es zu verstehen, aber irgendwann wird sich das Blatt wenden.

Wenn es sich um einen großen Schlammball handelt, werden Sie möglicherweise nie verstehen (oder wollen), wie es funktioniert.

2
Jon Raynor

Ich habe so viel getan ...

Hier ist mein aktueller Ansatz für Situationen, in denen "etwas funktioniert" und Sie dafür sorgen müssen, dass es "auf andere Weise funktioniert".

  1. Holen Sie sich Ziele, die das System lösen sollte (wenn sie nicht geschrieben wurden) - schreiben Sie es. Fragen Sie den Manager, andere Mitarbeiter, auch ehemalige, ob sie verfügbar sind. Fragen Sie den Kunden oder durchsuchen Sie eine Dokumentation.
  2. Holen Sie sich Spezifika. Wenn es nicht existiert - schreibe es. Es lohnt sich nicht, jemanden danach zu fragen, als ob es nicht existiert, dann sind Sie in einer Situation, in der es anderen nicht viel ausmacht. Also nur Weg, um selbst zu schreiben (später wird es viel einfacher sein, darauf zu verweisen).
  3. Holen Sie sich Design. Nicht existieren - schreibe es. Versuchen Sie, so weit wie möglich auf Dokumente und Quellcode zu verweisen.
  4. Schreiben Sie ein detailliertes Design für das Teil, das Sie ändern müssen.
  5. Definieren Sie, wie Sie es testen. Sie können also sicher sein, dass alter und neuer Code auf dieselbe Weise funktionieren.
  6. das System kann in einem Schritt erstellt werden. Und mit altem Code testen. Stellen Sie es auf SVC, falls es noch nicht geschehen ist.
  7. Änderungen implementieren. Nicht früher.
  8. überprüfen Sie nach etwa einem Monat, ob nichts kaputt ist.

Eine weitere optionale Aufgabe, die zwischen den einzelnen Schritten erforderlich sein kann: f off Manager (Projektbesitzer), der Ihnen mitteilt, dass "diese Änderungen bereits gestern vorgenommen werden sollten". Nach einigen Projekten kann er sogar helfen, Spezifikationen und Dokumente im Voraus zu erhalten.

Aber normalerweise (insbesondere für Skripte) ist dies im Geschäftsbereich einfach nicht möglich (die Kosten sind zu hoch, während der Wert zu niedrig ist). Eine Möglichkeit besteht darin, keine Änderungen vorzunehmen, bis die kritische Masse erreicht ist und das System aus der Produktion geht (z. B. wird ein neues System kommen) oder das Management entschieden hat, dass all dies sinnvoll ist.

PS: Ich erinnere mich an einen Code, der für 5 Clients mit unterschiedlichen Einstellungen verwendet wurde. Und jede Änderung (neue Funktion) musste überlegt werden, "welche Teile verwendet werden" und "welche Konfigurationsclients haben", um nichts zu bremsen und keinen Code zu kopieren. Durch das Setzen ihrer Einstellungen in Projekt-Lebensläufe und das Schreiben von Spezifikationen wird diese Denkzeit fast auf 0 reduziert.

Es wird keine Dokumentation geben oder es wird kaum Dokumentation geben oder es wird veraltet sein. Hier finden Sie alle vorhandenen Dokumentationen. Wenn es sich in einem Team-Repository befindet, erstellen Sie keine Kopie. Wenn nicht, legen Sie es dort ab und bitten Sie Ihren Manager um Erlaubnis, es zu organisieren, möglicherweise unter Aufsicht.

Holen Sie sich alles in das Repository für das Team und fügen Sie ein Glossar hinzu. Alle Basen haben Jargon; dokumentieren Sie es im Glossar. Erstellen Sie Abschnitte für Werkzeuge, Produkte, kundenspezifische usw.

Erstellen/Aktualisieren eines Erstellungsdokuments für eine Softwareumgebung. Alle Tools, Macken, Installationsoptionen usw. finden Sie hier.

Laden Sie dann ein Dokument "Erste Schritte mit" Produktname "oder Ähnliches hoch. Lass es nur Gedankenfluss sein und dich im Laufe der Zeit selbst organisieren. Gehen Sie dann veraltete Dokumente durch und bringen Sie sie wieder auf den neuesten Stand. Die anderen Entwickler werden es zu schätzen wissen, Sie werden auf einzigartige Weise einen Beitrag leisten, während Sie den Code lernen. Dokumentieren Sie insbesondere alle Dinge, die Sie überraschen oder falsch benannt oder kontraintuitiv sind.

Wenn Ihre Neigungskurve zu Ende ist, machen Sie sich keine Sorgen mehr über die Aktualisierung der Dokumentation. Lassen Sie den nächsten neuen Mann das tun. Wenn er ankommt, zeigen Sie ihn auf Ihre Arbeit. Wenn er Sie ständig um Antworten bittet, antworten Sie ihm nicht. Fügen Sie die Frage stattdessen Ihrer Dokumentation hinzu und geben Sie ihm die URL. Angel.

Ein Nebeneffekt ist, dass Sie ein Tool erstellt haben, auf das Sie in Monaten zurückgreifen können, wenn Sie es vergessen.

Und obwohl es sich nicht um Dokumentation handelt, ist ein verwandtes Problem all die kleinen skurrilen, manuell intensiven Verfahren, die Ihre Teamkollegen ausführen. Automatisieren Sie sie mit Batches, SQL-Skripten und dergleichen und teilen Sie diese ebenfalls. Schließlich ist prozedurales Wissen wohl genauso groß wie deklaratives Wissen, um in einer neuen Umgebung produktiv zu werden. Was auch immer es ist, tu es nicht; Schreiben Sie es stattdessen und führen Sie das Skript aus. Angelrute schlägt wieder zu.

1
toddmo

Das passiert sehr oft. Bis ich anfing, auf einer Open-Source-Plattform zu arbeiten, glaube ich nicht, dass ich jemals einen Job angefangen habe, der nicht mit dem Eingeständnis begann, dass der Code einige „Macken“ hatte.

Mit einem Step-Debugger und viel Hartnäckigkeit können Sie einen langen Weg zurücklegen. Leider braucht es oft Zeit und Erfahrung, um einen bestimmten großen Schlammball zu lernen, und selbst dann kann es nach Jahren noch ein Subsystem geben, das auftaucht, von dem niemand etwas weiß.

1
Jeremy French

Ich denke, eines der wichtigsten Dinge ist es, eine einfache Funktion zu verwenden, die einfachste auszuwählen, die Sie sich vorstellen können, und sie zu implementieren. Wenn es eine gepflegte Wunschliste gibt, verwenden Sie diese oder sprechen Sie mit jemandem, der mit der Codebasis vertraut ist, und lassen Sie ihn eine Funktion vorschlagen. Normalerweise würde ich erwarten, dass dies eine Änderung mit 5 ~ 20 LOC ist. Der wichtige Punkt ist nicht, dass Sie eine sehr ausgefallene Funktion hinzufügen, sondern dass Sie mit der Codebasis arbeiten (oder sich eher damit auseinandersetzen :)) und den gesamten Workflow durchlaufen. Sie müssten

  1. Lesen Sie den Code, um die Komponente zu verstehen, die Sie ändern
  2. Ändern Sie den Code und verstehen Sie, wie sich dies auf das umgebende System auswirkt.
  3. Testen Sie die Änderung und identifizieren Sie so, wie die Komponenten miteinander interagieren
  4. Schreiben Sie den Testfall und brechen Sie hoffentlich ein oder zwei Testfälle auf, damit Sie sie beheben und die Invarianten des Systems verstehen können.
  5. Bauen Sie das Ding oder sehen Sie, wie das CI es baut und versenden Sie es dann

Die Liste geht weiter, aber der Punkt ist, dass ein Mini-Projekt wie dieses Sie durch alle Elemente auf Ihrer Checkliste führt, um sich mit einem System vertraut zu machen, und auch zu einer produktiven Änderung führt.

1
Osada Lakmal

Eine kleine Sache, die ich hinzufügen wollte:

Ein Tool, das ich kürzlich für diese Art von Problem verwendet habe, das immens geholfen hat, ist Mind Mapping. Anstatt zu versuchen, alle Details darüber zu stopfen, wie etwas in meinem Kopf implementiert ist, werde ich eine Mindmap erstellen, die beschreibt, wie das System, das ich durchlaufe, funktioniert. Es hilft mir wirklich, tiefer zu verstehen, was los ist und was ich noch herausfinden muss. Es hilft mir auch, genau zu verfolgen, was ich ändern muss.

Ich empfehle die Verwendung von freies Flugzeug unter den zahlreichen Mind-Mapping-Optionen.

1
c.hughes

Ich habe einen ziemlich langen Beitrag zu diesem Thema geschrieben. Hier ist ein Auszug

Ich habe eine ganze Weile über dieses Problem nachgedacht. Ich beschloss, meine persönliche Lösung als allgemeinen Prozess aufzuschreiben. Die Schritte, die ich dokumentiert habe, sind wie folgt:

  1. Vokabular erstellen
  2. Lernen Sie die Anwendung
  3. Verfügbare Dokumentation durchsuchen
  4. Vermutungen aufstellen
  5. Suchen Sie Bibliotheken von Drittanbietern
  6. Code analysieren

Dieser Prozess wird im Kontext einer großen Desktop-Anwendung geschrieben, die allgemeinen Techniken gelten jedoch weiterhin für Webanwendungen und kleinere Module.

entnommen aus: Ein Prozess zum Erlernen einer neuen Codebasis

1
Lars

Es gibt einige kleine Tipps, die ich teilen kann.

Für ein vorhandenes Produkt beginne ich, sie intensiv zu testen. Wenn eine Aufgabe ausgewählt/zugewiesen wird, werde ich mich mehr auf die jeweilige Funktion konzentrieren.

  • Der nächste Schritt wäre, den Code zu finden, in den ich einbrechen und mit dem Erkunden beginnen kann. Unterwegs finde ich die abhängigen Module, Bibliotheken, Frameworks usw.

  • Der nächste Schritt wäre die Erstellung eines einfachen Klassendiagramms mit seinen Verantwortlichkeiten (wie CRC-Karten).

  • Nehmen Sie kleinere Änderungen vor oder nehmen Sie kleinere Fehler auf, um sie zu beheben und festzuschreiben. So können wir den Arbeitsablauf des Projekts lernen; nicht nur der Code. Oft haben große Produkte eine Art Buchführung, um Genehmigungen und Audits zu ermöglichen (z. B. Gesundheitsprojekte).

  • Sprechen Sie mit den Personen, die bereits an dem Projekt arbeiten. Drücken Sie Ihre Ideen, Gedanken aus und holen Sie sich im Gegenzug ihre Erfahrungen und Ansichten über die lange Arbeit mit diesem Projekt. Dies ist sehr wichtig, da Sie dadurch auch gut mit dem Team auskommen können.

1
sarat

Ich würde Sie ermutigen, Unit-Tests zu schreiben, bevor Sie etwas im Schlammballen ändern. Und nur Ändern Sie den Code zu diesem Zeitpunkt so weit, dass die Tests bestanden werden. Fügen Sie beim Refactoring vorab Unit-Tests hinzu, damit Sie wissen, dass die Geschäftsfunktionalität nicht durch Refactoring beeinträchtigt wurde.

Ist Paarprogrammierung eine Option? Eine andere Person zu haben, um Ideen abzuprallen, ist eine großartige Idee, um mit dieser Menge an Bösem umzugehen.

1
David Weiser

Hier ist ein Verfahren, mit dem wir Duplikate entfernen.

  • wählen Sie ein Standardkommentarpräfix für Duplikate (wir verwenden [dupe] direkt nach dem Kommentar-Marker;
  • schreiben Sie mit Ihren Teams Angaben zu Namen, die für das Duplizierungsverfahren verwendet werden sollen.
  • erste Runde: Jeder nimmt einige Dateien und fügt [dupe][procedure_arbitrary_name] vor der duplizierten Prozedur;
  • zweite Runde: Jeder nimmt eine Prozedur oder eine Teilmenge der Prozedur und weist einen Wert zu, der die Reihenfolge der Sympathie der verschiedenen Implementierungen mit demselben Zweck angibt (die Zeichenfolge lautet dann: [dupe][procedure_arbitrary_name][n]);
  • dritte Runde: Der Verantwortliche für jedes Verfahren schreibt es in die entsprechende Klasse um;
  • vierte Runde: grep glücklich!
1
cbrandolino

Es ist lange her, dass ich selbst in eine große Codebasis eintauchen musste. Aber in den letzten Jahren habe ich viele Male versucht, neue Entwickler in Teams zu bringen, in denen wir eine vorhandene, ziemlich große Codebasis hatten.

Und die Methode, die wir erfolgreich angewendet haben, und ich würde sagen, ist meiner Meinung nach der effektivste Weg ohne Frage, ist die Paarprogrammierung.

In den letzten 12 Monaten hatten wir 4 neue Mitglieder im Team, und jedes Mal wurde das neue Mitglied mit einem anderen Mitglied gepaart, das mit der Codebasis gut vertraut ist. Am Anfang hätte das ältere Teammitglied die Tastatur. Nach ungefähr 30 Minuten würden wir die Tastatur an das neue Mitglied weitergeben, das unter der Anleitung des älteren Teammitglieds arbeiten würde.

Dieser Prozess hat sich als recht erfolgreich erwiesen.

1
Pete

Mein Weg, ein großes Code-Projekt zu studieren, ist wie folgt:

  1. mach das Projekt und benutze es.
  2. verwenden Sie IDE, um das Projekt zu öffnen. Beispiel: Eclipse oder Codelite. Verwenden Sie dann IDE, um den gesamten Quellcode des Projekts zu indizieren.
  3. Verwenden Sie IDE, um ein Klassendiagramm zu generieren, wenn die Sprache des Projekts diese Funktion unterstützt.
  4. Finden Sie die Hauptmethode. Die Hauptmethode ist ein Programmeintrag. Die Hauptmethode ist auch ein guter Eintrag, um das Projekt zu erkunden.
  5. Finden Sie die wichtigsten Datenstrukturen und Funktionen des Programms. Sehen Sie sich die Implementierung an.
  6. Ändern Sie den Code des Projekts. Erstellen Sie ihn und verwenden Sie ihn. Beobachten Sie, ob er ordnungsgemäß funktioniert! Sie werden ermutigt, das Programm zu ändern.
  7. Nachdem Sie den Hauptablauf des Programms und die Implementierung des Kernsystems verstanden haben, können Sie die anderen Module des Programms erkunden.

    Jetzt haben Sie das große Code-Projekt verstanden! Bitte genießen Sie es!

0
Edward Shen