Wie taucht man in große Codebasen ein?

Welche Tools und Techniken verwenden Sie zum Erkunden und Erlernen einer unbekannten Codebasis?

Ich denke dabei an Werkzeugen wie grep, ctags, Komponententests, Funktionstest, Klasse-Diagramm Generatoren, rufen Sie Diagramme, Code - Metriken wie sloccount, und so weiter. Ihre Erfahrungen, die von Ihnen verwendeten oder selbst geschriebenen Helfer und die Größe der Codebasis, mit der Sie gearbeitet haben, würden mich interessieren.

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

was ich immer getan habe ist das folgende:

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

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

Wie isst du einen Elefanten?

Ein Bissen nach dem anderen :)

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

Muss ich hacken, bis ich den Job erledigt habe?

Zum großen Teil ja (sorry).

Mögliche Ansätze:

1. Versuchen Sie herauszufinden, was der Code in geschäftlicher Hinsicht tun soll.
2. Lesen Sie die gesamte Dokumentation, egal wie schlimm sie ist.
3. Sprechen Sie mit jedem, der etwas über den Code weiß .
4. Durchlaufen Sie den Code im Debugger.
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 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 gestalten (mit einem Refactoring-Tool).
4. Verwenden eines Tools, mit dem alle Verwendungen eines bestimmten Symbols hervorgehoben werden
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 mit Refactoring-Tools).
7. Fangen Sie an, Funktionen in sinnvolle Routinen zu extrahieren
8. Fange an, Tests hinzuzufügen, wo es möglich ist (nicht oft möglich)
9. Befreie dich von magischen Zahlen
10. Reduzierung von Duplikaten, wo möglich

... und was auch immer Sie für einfache Verbesserungen vornehmen können.

Allmählich sollte die Bedeutung des Ganzen klarer werden.

Wie für den Ort zu beginnen? Beginnen Sie mit dem, was Sie wissen. Ich schlage Ein- und Ausgänge vor. Oft bekommt man einen Überblick darüber, was diese sein sollen und wofür sie verwendet werden. Verfolgen Sie die Daten durch die Anwendung und sehen Sie, wo sie gespeichert und wie sie geändert werden.

Eines der Probleme, die ich dabei habe, ist die Motivation - es kann ein echtes Problem sein. Es hilft mir, das ganze Geschäft als Rätsel zu betrachten und die Fortschritte zu feiern, die ich mache, egal wie klein sie auch sein mögen.

Deine Situation ist eigentlich normal. Jeder, der in einen neuen Job eintreten muss, in dem bereits Code zum Arbeiten vorhanden ist, wird sich mit einem Element davon befassen. Wenn es sich bei dem System um ein wirklich fieses Altsystem handelt, entspricht es weitgehend den von Ihnen beschriebenen. Natürlich gibt es nie eine aktuelle Dokumentation.

Erstens haben viele empfohlen, effektiv mit Legacy-Code von Michael Feathers zu arbeiten. Dies ist in der Tat ein gutes Buch mit nützlichen Kapiteln wie "Ich kann diese Klasse nicht in ein Testgeschirr bekommen" oder "Meine Anwendung hat keine Struktur", obwohl Federn manchmal nur mehr Sympathie als Lösung bieten können. Insbesondere sind das Buch und seine Beispiele 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. Federn erwähnt hier die offensichtlichen Dinge wie Notizen zu machen und Listen zu 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,

Als nächstes denke ich, dass Ihr vorgeschlagener Ansatz sicherlich ein guter Schritt ist. Sie müssen zunächst auf hoher Ebene verstehen, wozu der Code dient.

Arbeiten Sie auf jeden Fall mit einem Mentor oder einer anderen Person im Team zusammen, wenn Sie Fragen haben, die beantwortet werden müssen.

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

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

• Kopieren Sie das ganze Durcheinander in die Zwischenablage
• Einfügen in Word / Textmate was auch immer
• Reduzieren Sie die Schriftgröße auf das 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.

Es braucht Zeit

Seien Sie nicht zu überstürzt, wenn Sie versuchen, eine alte Codebasis zu verstehen, insbesondere wenn Sie Technologien / Sprachen / Frameworks verwenden, 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 Lernprogrammen für die 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. Dabei stellen Sie Gemeinsamkeiten und Unterschiede fest, machen Notizen und stellen Fragen an vorhandene Entwickler.

"Warum hast du diesen Teil so gemacht?"

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

"Was hat Sie alle dazu bewogen, Technologie X vor Technologie Y zu wählen?"

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

Irgendwann werden Sie sich damit vertraut genug fühlen, um Dinge hinzuzufügen / zu reparieren. Wenn alles verwirrend erscheint oder es scheint, dass zu viel "Magie" vor sich geht, haben Sie nicht genug Zeit darauf verwendet, es zu untersuchen, zu verdauen und Diagramme zu erstellen. Das Erstellen von Diagrammen (Sequenzdiagramme, Prozessflussdiagramme usw.) ist eine hervorragende Möglichkeit, einen komplexen Prozess zu verstehen, und sie helfen dem "Nächsten".

cscope kann das tun, was ctags für C kann, und es kann auch auflisten, wo alle aktuellen Funktionen aufgerufen werden. Außerdem ist es sehr schnell. Skalierbar auf Millionen von LOC. Fügt sich nahtlos in Emacs und Vim ein.

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

doxygen kann syntaktisch hervorgehobenen und mit Querverweisen versehenen Code in HTML erzeugen. Nützlich beim Durchsuchen einer großen Codebasis.

Die Art und Weise, die ich mit Drupal empfehle und die nicht wirklich Drupal-spezifisch ist: Beginnen Sie mit dem Issue-Tracker. Es wird mit Sicherheit alte, nicht geschlossene Fehlerberichte geben. Kannst du sie reproduzieren? 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 in die Codebasis blicken, in der sie abstürzt. Oder Sie können den Code schrittweise durchgehen und sehen, wie er dort ankommt, wo er abstürzt. Auf diese Weise werden Sie nicht nur die Codebasis verstehen, sondern auch eine Menge Karma ansammeln und Ihre Fragen werden von der Community sehr begrüßt.

Eine wichtige Aufgabe besteht darin, mithilfe von Tools Abhängigkeitsdiagramme zu generieren , um die Codearchitektur von oben nach unten zu untersuchen. Visualisieren Sie zunächst ein Diagramm zwischen .NET-Assemblys oder -Gläsern. Auf diese Weise erhalten Sie eine Vorstellung davon, wie Features und Layer organisiert sind, und untersuchen Sie dann die Namespace-Abhängigkeiten (in einer oder mehreren verwandten .NET-Assemblys oder -Gläsern), um eine genauere Vorstellung von Code zu erhalten Strukturieren und schließlich können Sie sich Klassenabhängigkeiten ansehen, um zu verstehen, wie eine Gruppe von Klassen zusammenarbeitet, um ein Feature zu implementieren. Es gibt verschiedene Tools zum Generieren von Abhängigkeitsdiagrammen, z. B. NDepend für .NET , mit denen das folgende Diagramm generiert wurde.

Ein fantastischer Softwareentwickler sagte mir einmal, dass die teuerste Form der Codeanalyse und -wartung darin bestand, den Code Zeile für Zeile durchzugehen. Natürlich sind wir Programmierer, und das hängt so ziemlich mit dem Job zusammen. Ich denke, das Medium ist (in dieser Reihenfolge): 1. Holen Sie sich ein Notizbuch, um Notizen zu erstellen, damit Sie verstehen, wie der Code funktioniert, und fügen Sie sie im Laufe der Zeit hinzu. 2. Lesen Sie die Dokumentation zu Code 3. Sprechen Sie mit Autoren oder anderen Personen, die die Codebasis unterstützt haben. Fragen Sie sie nach einem "Brain Dump". 4. Wenn Sie sich mit einigen Klassenbeziehungen auf Detailebene auskennen, führen Sie ein schrittweises Debugging des Codes durch, um eine Synthese zwischen der Funktionsweise des Codes und der Funktionsweise des Codes zu erstellen wie der Code tatsächlich funktioniert.

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.

Drücken Sie dann auf "Ausführen" und beginnen Sie, den Code für die anscheinend wichtigsten Funktionen durchzugehen.

Teilen und erobern. Ich sehe mir jede Funktion und den zugehörigen Code an, gehe sie durch und gehe zum 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.

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

Sehen Sie, wie Michael Feathers effektiv mit Legacy-Code arbeitet

Hier ist meine kurze Liste:

1. Wenn möglich, lassen Sie den Code von jemandem auf hoher Ebene anzeigen. Welche Muster wurden berücksichtigt, welche Arten von Konventionen könnte ich erwarten, etc. Dies könnte einige Runden dauern, da ich am Anfang eine Geschichte erhalten würde, die mir neue Fragen stellen könnte, wenn ich mich mit dem Code vertraut mache zu fragen, wie ich die zwiebel des vorbestehenden projekts durcharbeite.

2. Führen Sie den Code aus und sehen Sie, wie die Systeme aussehen. Zugegeben, es kann mehr als ein paar Fehler enthalten, aber dies kann hilfreich sein, um eine Vorstellung davon zu bekommen, was es tut. Es geht nicht darum, den Code zu ändern, sondern nur darum zu sehen, wie dies abläuft. Wie fügen sich verschiedene Teile zu einem Gesamtsystem zusammen?

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

4. Wie gut kenne ich die in diesem Projekt verwendeten Sprachen und Frameworks? Die Wichtigkeit hierbei ist der Unterschied zwischen dem Betrachten einiger Dinge und der Frage: "Ja, das habe ich ein Dutzend Mal zuvor gesehen und kenne 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 die ich mir vor allem dann überlege, wenn ich mir älteren Code ansehe, 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 Dinge wurden so gemacht, wie sie waren. Für neue Bereiche kann es sich lohnen, etwas mehr Zeit darauf zu verwenden, die Struktur und die Muster in diesem Code zu kennen.

Last but not least: Kennen Sie die Erwartungen der Projektbetreiber in Bezug auf das, was Sie zu jedem Zeitpunkt tun sollen, wenn Sie die folgenden wenigen Vorstellungen davon haben, was zu erwarten ist:

• Setzen Sie neue Funktionen ein?
• Beheben Sie Fehler?
• Refactoring Sie Code? Sind die Standards für Sie neu oder sehr vertraut?
• Sollen Sie sich nur mit der Codebasis vertraut machen?

Ich versuche immer mit dem Einstiegspunkt in das Programm zu beginnen, da alle Programme einen haben (zB main method, main class, init, etc). Dies zeigt mir dann, was anfängt und wie die Dinge manchmal miteinander verbunden sind.

Danach habe ich einen Drilldown durchgeführt. Die Datenbank und 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 Refraktorwerkzeugen kann ich herausfinden, wer was anruft.

Ich versuche dann herauszufinden, wo die Schnittstelle konfiguriert und gehandhabt wird, da dies der nächste Einstiegspunkt für Informationen ist. Refractoring-, Such- und Debugging-Tools unterstützen meine Suche. Ich kann dann herausfinden, wo der Umgang mit Informationen beginnt und endet, indem ich mich durch alle Klassendateien arbeite.

Ich versuche dann, den Fluss auf ein Blatt Papier zu schreiben, um mich anfangs mit Dingen zu beschäftigen. Die Schaltfläche "Senden" wird an die allgemeine Überprüfung übergeben, die dann an das DAO oder die Datenbank übergeben und 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.

Ich würde sagen, ich beginne mit der Dokumentation usw., aber meiner Erfahrung nach ist die Dokumentationstiefe 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 Einloggen, Abrufen einer Kundenliste usw. Wenn die Muster überhaupt konsistent sind, sollte ein Thread Ihnen einen schönen, nicht unbedingt vollständigen Querschnitt des Systems bieten. 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 funktionaler Sicht zu verstehen, als aus technischer Sicht. Ich mache mir im Allgemeinen keine allzu großen Sorgen über die verwendeten Tools (ORMs, Protokollbibliotheken usw.) und konzentriere mich mehr auf die verwendeten Muster (MVP usw.). Nach meiner Erfahrung sind Werkzeuge im Allgemeinen flüssiger als Muster.

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 sind) - schreiben Sie es. Fragen Sie Manager, andere Mitarbeiter, auch ehemalige, ob sie verfügbar sind. Fragen Sie den Kunden oder suchen Sie nach Unterlagen.
2. Holen Sie sich specatio. Wenn es nicht existiert - schreibe es. Es lohnt sich nicht, jemanden danach zu fragen, als ob es nicht existiert, dann bist du in einer Situation, in der es anderen egal ist. Also nur so eigene schreiben (später wird es viel einfacher sich darauf zu beziehen).
3. Holen Sie sich Design. Nicht vorhanden - schreibe es. Versuchen Sie, so oft wie möglich auf Dokumente und Quellcode zu verweisen.
4. Schreiben Sie ein detailliertes Design auf das Teil, das Sie ändern müssen.
5. Definieren Sie, wie Sie es testen. So können Sie sicher sein, dass alter und neuer Code auf die gleiche Weise funktionieren.
6. Machen Sie das System in der Lage, in einem Schritt aufgebaut zu werden. Und mit altem Code testen. Legen Sie es zu SVC, wenn es nicht bereits ist.
7. Änderungen umsetzen. Nicht früher.
8. Vergewissern Sie sich nach etwa einem Monat, dass nichts kaputt ist.

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

In der Regel (insbesondere bei Skripten) ist dies jedoch im geschäftlichen Bereich nicht möglich (die Kosten sind zu hoch und der Wert zu niedrig). Eine Möglichkeit besteht darin, keine Änderungen vorzunehmen, bis die kritische Masse erreicht ist und das System aus der Produktion ausfällt (z. B. wenn ein neues System eingeführt wird) oder das Management entschieden hat, dass sich all dies lohnt.

PS: Ich erinnere mich an einen Code, der für 5 Clients mit unterschiedlichen Einstellungen verwendet wurde. Und jede Änderung (neue Funktion) war erforderlich, um zu berücksichtigen, "welche Teile verwendet werden" und "welche Konfigurationsclients", um nichts zu bremsen und Code nicht zu kopieren. Durch das Einstellen der Einstellungen für die Projektierung von Lebensläufen und das Schreiben von Spezifikationen wird diese Überlegungszeit auf nahezu 0 reduziert.

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 in diesem Teil 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.

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 verstehen, was los ist.

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 schauen Sie sich an dieser Stelle auch die Datenbank an. Gleichzeitig lernen Sie die Architektur kennen, und es 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. Versuchen Sie jedoch nicht, den gesamten Code zu lesen. Es ist wichtiger zu wissen, wo der Code X ausführen soll, als genau zu wissen, wie X ausgeführt wird. Der Code ist immer da, um Ihnen zu sagen, wie Sie ihn finden können.

Ich bin der Meinung, dass es in der Regel unproduktiv ist, nur in den Code einzuspringen und ihn zu lesen, ohne ein Ziel zu haben, das über das Erlernen des Codes hinausgeht. Wenn Sie versuchen, kleine Änderungen selbst vorzunehmen oder den Code der Änderungen eines anderen zu überprüfen, ist dies eine weitaus produktivere Nutzung Ihrer Zeit.

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, ein Überblick auf hoher Ebene ist hilfreich (sofern verfügbar), aber es besteht die Möglichkeit, dass Sie viel Zeit im Debugger verbringen, um den Programmfluss zu verfolgen. Es ist eine gute Idee, sich einen Überblick über die Anwendung zu verschaffen und zu sehen, wie / was / warum der Code verwendet wird.

Normalerweise führe ich eine Art Code-Komplexitätstool für den Code aus, um zu ermitteln, wo sich die Problembereiche befinden. Bereiche mit hoher Punktzahl sind wahrscheinlich nur 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 andere Entwickler verärgern könnten. Schließlich ist es vielleicht Ihr Baby, und niemand mag es, wenn ihm gesagt wird, dass Ihr Baby hässlich ist.

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

Ich finde es hilfreich, Programmcode-Flüsse zu entwickeln. Wenn ich Ä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, hat dies eine größere Auswirkung.

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

Wenn es sich um eine große Schlammkugel handelt, werden Sie möglicherweise nie das Innenleben verstehen (oder verstehen wollen).

Einige Dinge, die ich tue ...

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

2) Durchforsten Sie den Code in Eclipse von oben nach unten (gut, wenn Sie einen Editor haben, der Referenzen usw. durchsuchen kann), bis Sie wissen, was in der Codebasis vor sich geht und wo.

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

Das passiert sehr oft. Bis ich anfing, auf einer Open-Source-Plattform zu arbeiten, habe ich wohl nie einen Job angefangen, 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 Schlammballen zu lernen, und selbst dann kann es nach Jahren noch ein Teilsystem geben, von dem niemand etwas weiß.

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

Ist Paarprogrammierung eine Option? Es ist eine großartige Idee, eine andere Person zu haben, die Ideen auf den Kopf stellt.

Hier ist ein Verfahren, mit dem wir Duplikate entfernen.

• Wählen Sie ein Standard-Kommentar-Präfix für Duplikate aus (wir verwenden es [dupe]direkt nach dem Kommentar-Marker.
• Schreiben Sie mit Ihren Teams Angaben zu den Namen, die für das Duplikatverfahren verwendet werden sollen.
• erste Runde: Jeder nimmt einige Dateien und fügt sie [dupe][procedure_arbitrary_name]vor dem duplizierten Vorgang hinzu;
• Zweite Runde: Jeder nimmt eine Prozedur oder eine Teilmenge einer 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 der entsprechenden Klasse um;
• vierte Runde: grepglücklich!

Ich denke, eines der wichtigsten Dinge ist, ein einfaches Feature zu nehmen, das einfachste auszuwählen, an das Sie denken können, und es 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 sich dies mit 5 ~ 20 LOC ändert. Der wichtige Punkt ist nicht, dass Sie eine sehr ausgefallene Funktion hinzufügen, sondern dass Sie mit der Codebasis arbeiten (oder vielmehr sich damit auseinandersetzen :) und den gesamten Workflow durchlaufen. Sie müssten

1. Lesen Sie den Code, um die zu ändernde Komponente zu verstehen
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, 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 dann versendet

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

Eine kleine Sache, die ich hinzufügen wollte:

Ein Tool, das ich seit kurzem für diese Art von Problem benutze und das immens geholfen hat, ist Mind Mapping. Anstatt zu versuchen, alle Details der Implementierung in meinem Kopf zu überfrachten, werde ich eine Mindmap erstellen, die beschreibt, wie das System funktioniert, durch das ich gehe. Es hilft mir wirklich, tiefer zu verstehen, was vor sich geht und was ich noch herausfinden muss. Es hilft mir auch, den Überblick zu behalten, was ich in einem sehr genauen Maßstab ändern muss.

Ich empfehle, unter der Fülle von Mind-Mapping-Optionen ein freies Flugzeug zu verwenden.

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 Vorgesetzten um Erlaubnis, es zu organisieren, möglicherweise unter Aufsicht.

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

Erstellen / Aktualisieren eines Softwareumgebungserstellungsdokuments. Alle Tools, Macken, Installationsoptionen usw. finden Sie hier.

Laden Sie anschließend ein Dokument "Erste Schritte mit" ProductName "oder ähnliches hoch. Lass es einfach sein, dass der Geist im Laufe der Zeit fließt und sich selbst organisiert. Durchsuchen Sie dann veraltete Dokumente und bringen Sie sie auf den neuesten Stand. Die anderen Entwickler werden es zu schätzen wissen. Sie werden auf einzigartige Weise dazu beitragen, während Sie den Code lernen. Dokumentieren Sie vor allem solche Dinge, die Sie überraschen, falsch benannt oder nicht intuitiv sind.

Machen Sie sich nach dem Ende Ihrer Lehnkurve keine Sorgen mehr über die Aktualisierung der Dokumentation. Lass den nächsten Neuen das machen. Wenn er ankommt, weisen Sie ihn auf Ihre Arbeit. Wenn er Sie ständig um Antworten bittet, antworten Sie ihm nicht. Fügen Sie stattdessen die Frage zu Ihrer Dokumentation hinzu und geben Sie ihm die URL. Angel.

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

Und obwohl es sich nicht um Dokumentation handelt, handelt es sich bei einem verwandten Problem um die kleinen, eigenwilligen, manuell intensiven Vorgänge, die Ihre Teamkollegen ausführen. Automatisieren Sie sie mit Batches, SQL-Skripten und dergleichen und geben Sie diese ebenfalls frei. 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 lieber ein Skript und führen Sie das Skript aus. Angelrute schlägt wieder zu.

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

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

1. Vokabelblatt erstellen
2. Lernen Sie die Anwendung
3. Durchsuchen Sie die verfügbare Dokumentation
4. Vermutungen aufstellen
5. Suchen Sie nach Bibliotheken von Drittanbietern
6. Code analysieren

Dieser Prozess ist im Kontext einer großen Desktop-Anwendung geschrieben, aber die allgemeinen Techniken sind immer noch auf Webanwendungen und kleinere Module anwendbar.

entnommen aus: Ein Prozess zum Erlernen einer neuen Codebasis

Es gibt einige kleine Tipps, die ich mitteilen kann.

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

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

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

• Nehmen Sie kleinere Änderungen vor oder greifen Sie kleinere Fehler auf, um sie zu beheben und zu bestätigen. 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 Leuten, die bereits an dem Projekt arbeiten. Bringen Sie Ihre Ideen und Gedanken zum Ausdruck und sammeln Sie im Gegenzug Ihre Erfahrungen und Ansichten in Bezug auf die langjährige Arbeit mit diesem Projekt. Dies ist sehr wichtig, da Sie dadurch auch gut mit dem Team zurechtkommen.

Es ist lange her, dass ich selbst in eine große Codebasis eintauchen musste. In den letzten Jahren habe ich jedoch 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 ohne Frage der effektivste Weg, IMHO, die Paarprogrammierung.

In den letzten 12 Monaten hatten wir 4 neue Mitglieder im Team, und jedes Mal passte das neue Mitglied mit einem anderen Mitglied zusammen, das mit der Codebasis gut vertraut war. Am Anfang hatte 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.