Best Practices für die Übergabe von Legacy-Code

In ein paar Monaten wird ein Kollege zu einem neuen Projekt übergehen und ich werde eines seiner Projekte erben. Zur Vorbereitung habe ich bereits Michael Feathers ' Working Effectively with Legacy Code bestellt .

Aber diese Bücher sowie die meisten Fragen zu Legacy-Code, die ich bisher gefunden habe, befassen sich mit dem Fall, dass Code unverändert übernommen wird. In diesem Fall habe ich jedoch Zugriff auf den ursprünglichen Entwickler, und wir haben etwas Zeit für eine ordnungsgemäße Übergabe.

Einige Hintergrundinformationen zu dem Code, den ich erben werde:

• Es funktioniert: Es sind keine Fehler bekannt, aber da die Leistungsanforderungen weiter steigen, werden in nicht allzu ferner Zukunft einige Optimierungen erforderlich sein.
• Undokumentiert: Auf Methoden- und Klassenebene gibt es so gut wie keine Dokumentation. Was der Code auf einer höheren Ebene tun soll, ist jedoch gut verstanden, da ich seit Jahren gegen seine API (als Black-Box) schreibe.
• Nur übergeordnete Integrationstests: Es gibt nur Integrationstests, die die ordnungsgemäße Interaktion mit anderen Komponenten über die API (ebenfalls Blackbox) testen.
• Sehr niedrige Ebene, optimiert für Geschwindigkeit: Da dieser Code für ein ganzes System von Anwendungen von zentraler Bedeutung ist, wurde im Laufe der Jahre ein Großteil davon mehrmals optimiert und ist extrem niedrige Ebene (ein Teil verfügt für bestimmte Strukturen über einen eigenen Speichermanager) /Aufzeichnungen).
• Gleichzeitiges und sperrenfreies Programmieren : Während ich mit dem gleichzeitigen und sperrenfreien Programmieren sehr vertraut bin und tatsächlich einige Teile zu diesem Code beigetragen habe, wird hierdurch eine weitere Komplexitätsebene hinzugefügt.
• Große Codebasis: Dieses spezielle Projekt besteht aus mehr als zehntausend Codezeilen, daher kann ich mir auf keinen Fall alles erklären lassen.
• Geschrieben in Delphi: Ich werde dies nur veröffentlichen, obwohl ich nicht glaube, dass die Sprache für die Frage von Belang ist, da ich glaube, dass diese Art von Problem sprachunabhängig ist.

Ich fragte mich, wie die Zeit bis zu seiner Abreise am besten verbracht werden könnte. Hier sind ein paar Ideen:

• Damit alles auf meinem Computer funktioniert: Auch wenn alles in die Quellcodeverwaltung eingecheckt werden sollte, der nicht vergessen hat, ab und zu eine Datei einzuchecken, sollte dies wahrscheinlich die erste Aufgabe sein.
• Weitere Tests: Ich hätte gerne mehr Unit-Tests auf Klassenebene, damit bei Änderungen von mir eingeführte Fehler frühzeitig erkannt werden können, da der aktuelle Code nicht testbar ist (große Klassen, lange Methoden, zu viele) gegenseitige Abhängigkeiten).
• Was zu dokumentieren ist: Ich denke, für den Anfang ist es am besten, die Dokumentation auf die Bereiche im Code zu konzentrieren, die ansonsten schwer zu verstehen wären, z. B. wegen ihrer niedrigen / hochoptimierten Natur. Ich fürchte, es gibt ein paar Dinge, die hässlich aussehen und überarbeitet / umgeschrieben werden müssen, aber es handelt sich tatsächlich um Optimierungen, die aus einem guten Grund veröffentlicht wurden, den ich verpassen könnte (vgl. Joel Spolsky, Things You Should Mach niemals, Teil I )
• Wie zu dokumentieren: Ich denke, einige Klassendiagramme der Architektur und Sequenzdiagramme kritischer Funktionen, begleitet von einer Prosa, wären am besten.
• Zu dokumentierende Personen: Ich habe mich gefragt, was besser wäre, wenn er mir die Dokumentation schreibt oder erklärt, damit ich die Dokumentation schreiben kann. Ich befürchte, dass Dinge, die für ihn, aber nicht für mich, offensichtlich sind, sonst nicht richtig abgedeckt würden.
• Refactoring mit Pair-Programming: Dies könnte aus Zeitgründen nicht möglich sein, aber ich könnte möglicherweise einen Teil seines Codes refactoren, um ihn wartungsfreundlicher zu machen, während er noch da war, um Eingaben darüber zu machen, warum die Dinge so sind, wie sie sind.

Bitte kommentieren und ergänzen. Da ich nicht genug Zeit habe, um all dies zu tun, interessiert mich besonders, wie Sie Prioritäten setzen würden.

Update: Da das Übergabeprojekt vorbei ist, habe ich diese Liste mit meinen eigenen Erfahrungen in dieser Antwort unten erweitert .

Wenn Sie Zugriff auf den Entwickler haben, fragen Sie nach folgendem Code:

• Welche Module waren am schwierigsten zu codieren / zu implementieren? Was waren die Probleme und wie wurden sie überwunden?

• Welche Module haben die meisten Fehler generiert.

• Welche Module haben zu den am schwierigsten zu lösenden Fehlern geführt?

• Auf welche Codeteile ist er am stolzesten?

• Welche Codestücke er aber wirklich gerne umgestalten würde, hat die Zeit nicht gehabt.

Diese Fragen geben Ihnen einen Einblick in das, was Ihnen die meisten Probleme bereiten wird, und, was vielleicht noch wichtiger ist, einen Einblick in die Denkprozesse und Perspektiven des ursprünglichen Entwicklers.

Da das Übergabeprojekt nun vorbei ist, würde ich mir die Zeit nehmen und meine eigene Antwort mit den Dingen aufschreiben, die für mich am besten funktionierten.

• Alles unter Versionskontrolle bringen: Nachdem ich sichergestellt hatte, dass alles, was ich erstellen musste, unter Versionskontrolle stand, durchsuchte ich auch die Festplatte des alten Entwicklers, um nach zusätzlichen Skripten oder Dienstprogrammen zu suchen, die hilfreich wären, um die Anwendung bereitzustellen und / oder zu testen, aber nicht nicht eingecheckt
• Top-down: Ich würde mit einem Blick auf die Hauptklassen und einer Führung mit dem alten Entwickler der Hauptbereiche beginnen. Dann würde ich selbst tiefer in den Rest eintauchen und Dinge, die für mich keinen Sinn ergaben, mit //TODOMarkierungen markieren.
• Schreiben Sie die gesamte Dokumentation selbst: Während ich vom alten Entwickler überprüft wurde, um sicherzustellen, dass alles in Ordnung ist, bestand ich darauf, alles selbst zu schreiben. Auf diese Weise würde ich sicher sein, dass das Schreiben für mich und nicht nur für den alten Entwickler Sinn macht.
• Kommentare überall: Ich habe jeder Klasse und jeder Methode XML-Dokumentationszusammenfassungen hinzugefügt . Auf diese Weise stellte ich sicher, dass ich mir jeden Code zumindest angeschaut hatte und genug Verständnis hatte, um zusammenzufassen, was er in einem Satz tat. Das Verständnis der Methoden unter Verwendung von Summate-Methoden / -Klassen wurde erleichtert, da IntelliSense diese Informationen aufnimmt. Ich konnte auch leicht Bereiche des Codes identifizieren, die ich noch betrachten musste.
• Dokument in der Nähe der Quelle: Um die Verbindung zwischen Quellcode und Dokumentation zu vereinfachen, habe ich den größten Teil meiner Dokumentation direkt in den Quellcode eingefügt. Für die Dokumentation auf hoher Ebene, die die Interaktion zwischen verschiedenen Subsystemen beschreibt, habe ich ein Wiki verwendet, da es nicht funktioniert hat, diese Informationen nur an einer Stelle im Code abzulegen. Die gesamte Dokumentation sollte elektronisch und im Volltext durchsuchbar sein.
• Diagramme: Für eine grundlegende Übersicht habe ich Klassendiagramme verschiedener Granularitäten für die verschiedenen Subsysteme verwendet. Für die gleichzeitigen Teile waren Objekt- und Interaktionsdiagramme sehr hilfreich. siehe auch meine andere frage zum thema .
• Refactoring als Paar: Während ich mit dem alten Entwickler ein paar Refactorings durchgeführt habe, um ein Gefühl für den Code zu bekommen und die Wartung zu verbessern, war dies ein zeitaufwändiger und auch riskanter Prozess, da es an guten Refactoring-Tools mangelte und eine Menge unangenehmer Dinge gab Abhängigkeiten zwischen den verschiedenen Teilen. Die effektive Arbeit von Michael Feathers mit Legacy-Code ist hierfür eine sehr gute Hilfe, auch wenn das Umgestalten ohne ordnungsgemäße Werkzeugunterstützung immer noch schmerzhaft ist. Während des Refactorings ließ ich ihn Maus und Tastatur steuern, da es ihm mehr Spaß machte (siehe auch meinen letzten Aufzählungspunkt) und ich war frei, aufzuschreiben, was ich lernte.
• Separate Eincheckvorgänge für Kommentare und Änderungen: Nachdem ich versehentlich einen Fehler durch Schreiben eines Kommentars über einen Fehler gemeldet habe override, habe ich bei separaten Eincheckvorgängen darauf geachtet, Kommentare und Änderungen vorzunehmen. Ich habe ein kleines Hilfsprogramm verwendet, um alle Kommentare aus dem Quellcode zu entfernen, bevor ich etwas eingecheckt habe, sodass ein Unterschied von einem Einchecken nur mit Kommentaren 0 Unterschiede ergeben würde. Alle Änderungen (z. B. das Entfernen nicht verwendeter Felder) wurden sorgfältig von Experten mit dem alten Entwickler überprüft, um sicherzustellen, dass ich keine noch benötigten Elemente entferne.
• Zeilweises Durchgehen kritischer Passagen: Für die optimiertesten / komplexesten Passagen ging ich den Code zeilenweise mit dem alten Entwickler und manchmal sogar mit einem dritten Kollegen durch. Auf diese Weise bekam ich ein gründliches Verständnis des Codes und als mehr Leute den Code überprüften, identifizierten wir tatsächlich ein paar Fehler sowie einige Dinge, die weiter optimiert werden könnten.
• Seien Sie schnell und motivieren Sie den alten Entwickler: Ich bemerkte, dass der alte Entwickler immer weniger interessiert war, als sein letzter Tag näher rückte (nicht überraschend). Ich würde daher sicherstellen, dass die kritischsten Teile zuerst übergeben werden und den Rest für mich selbst herausfinden, wenn nötig. Ich habe auch versucht, die spaßigeren Dinge (z. B. die Steuerung der Tastatur beim Pair-Programming) ihm zu überlassen und die langweiligen Dinge wie das Dokumentieren selbst zu machen.
• Feature-Anfragen identifizieren: Ich fand es hilfreich, den alten Entwickler nach einer Liste von Features zu fragen, nach denen die Leute gefragt hatten, die aber noch nicht hinzugefügt wurden. Es gab ein paar Dinge, die für mich einfach hinzuzufügen schienen, aber wo es einen guten Grund gab, wurden sie nicht hinzugefügt, da sie bei der Implementierung andere Dinge kaputt gemacht hätten, wie ich es zuerst gedacht hatte.

In einer ähnlichen Situation wäre meines Erachtens auch Folgendes zu bedenken:

• Stellen Sie sicher, dass Sie eine Bereitstellung durchführen und testen können: Führen Sie Ihre eigene Bereitstellung des Produkts von Grund auf durch - und vergewissern Sie sich, dass dies mit der Bereitstellung der Person identisch ist , die das Produkt verlässt. Dies würde sicherstellen, dass alle Skripte und Anweisungen für Sie klar sind, und versehentliche Versehen, wie z. B. Zutaten, die nicht in Ihr Versionskontrollsystem eingecheckt wurden, auffangen. (Ich sage nicht , dass dies würde geschehen, dass nur , wenn es hat passiert, wird es viel einfacher sein , mit jetzt zu tun, bevor die Person verlässt)

  (Dies ist möglicherweise für Sie nicht relevant, z. B. wenn Sie bereits Continuous Integration oder Continuous Deployment durchführen, es ist jedoch erwähnenswert, nur für den Fall ...)

• Weitere Tests schreiben: Dies ist eine sehr gute Methode, um Ihr Systemverständnis zu testen. Es ermöglicht (oder erzwingt) Ihnen, Bereiche des Codes genauer zu betrachten und entweder zu bestätigen, dass der Code so fehlerfrei ist, wie Sie vermuten, oder Bereiche aufzudecken, in denen Sie dachten, Sie hätten die Absicht verstanden, aber tatsächlich Sie Sie müssen Ihren Kollegen um Klärung bitten, bevor er geht

• Paarweises Schreiben von Dokumentationen: Dies ist eine effektive Methode zum Schreiben von Übersichten. Ich schlage vor, dass Sie Ihren Kollegen bitten, ein Merkmal oder einen Bereich zu beschreiben, und Sie schreiben es dann in der Dokumentation in Ihren eigenen Worten auf. Wir fanden, dass dies massiv einfacher war, wenn zwei Personen zusammen arbeiteten.

Ich würde das Verfassen von Tests als höhere Priorität als das Verfassen von Unterlagen betrachten, da die Tests Ihnen wahrscheinlich ein besseres Verständnis vermitteln.

In Bezug auf Refactoring mit Pair-Programmierung würde ich nur sagen, dass die Gefahr besteht, dass dies zu einer Grube ohne Boden wird, zumal Sie sagten, Sie hätten nur Tests auf hohem Niveau. Sie werden feststellen, dass es viel mehr Zeit in Anspruch nimmt, als Sie beabsichtigt hatten.

+1 für die Antworten, die Sie bereits in Ihrer Frage haben!

Geführte Tour
10k Zeilen Code sind eine Menge, aber ich denke, es ist immer noch nicht unmöglich, dass der andere Ihnen eine "geführte Tour" gibt. Sie setzen sich gemeinsam vor den Code und er nimmt Sie mit auf eine Reise von oben nach unten, wobei er die „Ebenen“ abarbeitet. Sie müssten es in kurzen Stößen tun - alles auf einmal würde Sie beide töten.

Vergrößern, Verkleinern
Der Vorteil dabei ist, dass er, während er es Ihnen erklärt, mit ziemlicher Sicherheit einige "Oh ja, es gibt auch diese" Momente hat, die er möglicherweise nicht hat, wenn er nur versucht, es zu dokumentieren selbstständig. Und Ihre Fragen helfen, sich auf die Dinge zu konzentrieren, die für ihn offensichtlich sind, aber für niemanden. Diese Art der Zoom-in / Zoom-out-Interaktion ist nur eins zu eins möglich. Der Versuch, so etwas zu schreiben oder zu lesen, ist unhandlich.

Dokumentation
Ich denke, Sie sollten beide unabhängig voneinander dokumentieren - er sollte ganz unten anfangen (falls Sie keine Zeit haben, dort zusammenzukommen), und Sie sollten ganz oben anfangen, auf der Grundlage dessen, was Sie verstanden haben seine geführte Tour und wie für jemand anderen [in einem früheren Job habe ich eine Menge 'Legacy'-Code geerbt und hatte erst die Zeit, ihn zu dokumentieren, bevor ich mich selbst verließ :)].

Wo ist was
Das meiste davon hat zum Ziel, dass Sie ein Gefühl dafür bekommen, wo Dinge passieren. So können Sie bei einem bestimmten Fehler oder einer bestimmten Änderung sehr schnell die Stelle im Code finden, auf die Sie sich konzentrieren müssen. Sie können sich selbst testen, indem Sie die Liste der alten Fehler lesen und prüfen, ob Sie das Problem genau vorhersagen können.

Pump ihn trocken
Es ist egal, ob er dich hasst oder nicht (lächelt). Deine Aufgabe ist es, so viele Informationen wie möglich aus dem Gehirn des Typen zu holen. Stellen Sie sicher, dass Sie das Management auf Ihre Seite bekommen und dass der Wissenstransfer Vorrang vor dem "Beheben der letzten Fehler, bevor er geht" hat (es sei denn, Sie beheben sie gemeinsam ...).

Ich schlage Folgendes vor (zusätzlich zu dem, was bereits identifiziert wurde) - Bitten Sie zuerst Ihren Manager, Ihnen Zeit zu geben, so viel wie möglich mit diesem Kerl zusammenzuarbeiten, und versuchen Sie, mit ihm zusammenzusitzen, wenn er eine Änderung vornehmen soll. Sie müssen nicht alles wissen, was er tut, aber versuchen, so viel wie möglich zu fangen. Am wichtigsten ist, mit ihm befreundet zu sein.

Behandeln Sie die Übergabe als Projekt, erstellen Sie einen Plan und binden Sie die Geschäftsleitung ein.

0 - Vergewissern Sie sich, dass Sie mit dem System vertraut sind.

1 - Machen Sie eine klare Bestandsaufnahme der Lösungskomponenten, deren Quelle und wo sie liegen (in verschiedenen Repositories)

2 - Holen Sie sich die Passwörter für die verschiedenen Server und verwalten Sie sie, falls möglich. Stellen Sie sicher, dass Sie alle Informationen zum Administratorkonto haben

3 - Holen Sie sich die Lizenzen für jede externe Komponente, es sei denn, sie liegt außerhalb Ihres Anwendungsbereichs (z. B. spezielle DLLs, Datenbanken usw.).

4 - Erhalten Sie einen schriftlichen Bericht über den aktuellen Status des Systems vom Entwickler und Ihren Kunden (falls diese in Ihrem Unternehmen ansässig sind).

5 - Holen Sie sich die Dokumentation für die Geschäftsregeln, Berechnungsformeln usw. Sie können dies mit ihm tun. Bitten Sie ihn um E-Mails, Besprechungsinformationen, Benutzeranforderungsdokumente, Entwurfsunterlagen und dergleichen, die Sie erhalten.

6 - Eine Liste der geplanten Ereignisse (monatliche Jobläufe, wöchentliche Jobläufe) abrufen, auf die die Software reagieren muss

7 - Erlernen der Sicherungs- / Wiederherstellungsverfahren

8 - Verstehen Sie die Frameworks, die beim Erstellen der Anwendung verwendet wurden

9 - Informieren Sie sich über die angeforderten / erwarteten / geplanten Änderungen und den Status aller ausstehenden Benutzeranforderungen. Beginnen Sie damit, herauszufinden, wie Sie diese auf eigene Faust ausführen können.

10 - Stellen Sie sicher, dass Ihre Test- und Entwicklungsumgebung sehr ähnlich sind.

11 - Versuchen Sie, wichtige Abhängigkeiten (von anderen Systemen oder zwischen Komponenten) zu identifizieren, die nicht leicht zu erkennen sind.

12 - Identifizieren und dokumentieren Sie die erforderlichen Versionen jeder Softwareverwendung und den Kontakt zum Anbieter (falls erforderlich).

13 - Identifizieren Sie alle Spezialwerkzeuge, die er verwendet hat und die Sie nicht haben, falls es Ihnen helfen könnte.

14 - Holen Sie sich einen hohen Systemfluss. und beginnen Sie mit dem Aufbau Ihrer Dokumentationsbibliothek

15 - Informationen zum Verwalten der Benutzersicherheit für die Anwendung

16 - Holen Sie sich das Fehlerprotokoll und versuchen Sie, die Aktionen und die Auswirkungen der Aktion auf ältere Daten (falls zutreffend) zu verstehen.

17 - Kennen Sie Prozesse, die zu lange dauern und auf die Sie achten müssen (z. B. ungewöhnliche Dateigrößen, FTP von doppelten Dateien usw.), sofern zutreffend.

18 - Überprüfen Sie die Uhr des Produktionsservers

19 - Identifizieren Sie, wo sich die Konfigurationen befinden, und vergleichen Sie jede Umgebungskonfiguration mit der Produktion, um zu wissen, welche Parameter sich unterscheiden und warum

20 - Holen Sie sich die Kontaktinformationen dieses Mannes

21 - Wenn das System intern ist, planen Sie eine Besprechung mit den Systembenutzern (Sie müssen wissen, wer sie sind und welche Rolle die einzelnen Benutzer spielen) und lassen Sie sich mit ihnen bekannt machen. Hören Sie, was sie über das System und über ihre aktuellen Probleme zu sagen haben. Stellen Sie sicher, dass Sie so früh wie möglich in E-Mails aufgenommen werden (nach Zustimmung Ihres Managers).

22 - Beurteilen Sie Ihr Verständnis 1 Woche vor seiner Abreise und melden Sie alle Probleme, die Sie als Risiko ansehen

Da Sie erwähnt haben, dass Sie keine Datenbank haben, wurde diese Liste kürzer.

Viel Glück.

Ich würde zuerst die kompliziertesten, für die Leistung optimierten Teile betrachten. Ich würde ihn dazu bringen, diese Teile zuerst zu dokumentieren und Ihnen einzeln zu erklären. Dann würde ich versuchen, Tests für diese Teile zu schreiben (einschließlich vor und nach Leistungstests, damit Sie sehen können, ob eine neue Optimierung die Dinge verbessert oder verschlechtert ) und lassen Sie die Tests von der anderen Person überprüfen. Auf diese Weise dokumentiert und erklärt er, dass Sie die Erklärung verwenden, um Tests zu schreiben (während er einen anderen Bereich dokumentiert), und durch seine Überprüfung wird sichergestellt, dass Sie verstanden haben, was Sie testen sollten. Auf diese Weise erhalten Sie auch zusätzliches Test-Durchschnitt für einige der kritischsten Teile der Anwendung und Dokumentation der spezialisierten Leistungsoptimierungen.

Wenn es Zeit gibt, nachdem ich diese behandelt habe, würde ich als Nächstes einen ähnlichen Prozess mit den Teilen der Anwendung durchlaufen, die im Laufe der Jahre am häufigsten geändert werden mussten, aber nicht in der ersten Gruppe der dokumentierten Dinge enthalten sind.

Dokumentieren Sie dann alles, was noch übrig ist.

Ich denke, der beste Weg, um einen großen Code zu finden, ist ein Top-Down-Ansatz. Versuchen Sie zunächst, das Gesamtbild zu verstehen, und vertiefen Sie dann schrittweise die einzelnen Komponenten.

Bitten Sie ihn nun, auf jeder Ebene des Grabens die Teile zu priorisieren, die die meiste Aufmerksamkeit erfordern. Lassen Sie sich von ihm so viel wie möglich erklären, aber dokumentieren Sie es immer selbst.

Das Beste daran, es selbst zu dokumentieren, ist, dass Sie, wenn Sie später wiederkommen, problemlos denselben kognitiven Zustand wiederfinden können, in dem Sie sich befanden, als er es Ihnen erklärte. Sie können viel einfacher verstehen, was Sie geschrieben haben, als was jemand anderes getan hat. Nach meiner Erfahrung produzieren zwei Personen, die denselben Code dokumentieren, keine ähnlich aussehenden Textteile.

Dies behebt vermutlich auch Ihre "Was und Wie dokumentieren" -Probleme. Wenn er Ihnen alles erklärt, können Sie selbst entscheiden, was bei der Rückkehr zum Code dokumentiert werden soll - und nur diese Teile dokumentieren.

Die Idee ist, zuerst den Code vollständig zu verstehen (in seiner Gegenwart) und dann alles zu schreiben / zu tun, was es Ihnen ermöglicht, ihn später (in seiner Abwesenheit) zu lernen.

Wenn Sie den Code vollständig verstehen, müssen Sie ein Gefühl für das Gesamtbild bekommen - und wie sich jede Komponente auf dieses Gesamtbild bezieht. Ich fand es besonders hilfreich, zu verfolgen, wie sich jedes Stück zu einem Ganzen zusammenfügt. Versuchen Sie nicht, etwas isoliert zu verstehen - verlieren Sie niemals den Kontext aus den Augen.

Nachdem Sie die oben genannten Schritte ausgeführt haben, übernehmen Sie proaktiv die Kontrolle. Entscheiden Sie selbst, für welche Teile Sie eine Unit-Test-Abdeckung benötigen. Welche Teile müssen optimiert werden (oder können optimiert werden), wie können Sie eine Komponente umgestalten?

Ich fühle für dich.

Ein paar Vorschläge:

1. Nehmen Sie jedes Gespräch auf, das Sie mit dem Programmierer führen!
2. Fragen Sie nach der Motivation hinter den "großen" Themen. Gut, dass Sie die API verstehen, aber nach internen Entscheidungen suchen - warum wurde der Code so partitioniert, wie er ist? Was sind die Verantwortlichkeiten.
3. Bemühen Sie sich, den Code wirklich zu studieren. Wenn Sie Wartungs- und Supportaufgaben übernehmen, besteht manchmal der Druck, "den Code zu studieren, während Sie Fortschritte machen". Widerstehen Sie, wenn Sie können, und studieren Sie den Code.
4. Suchen Sie nach Szenarien. Sie kennen die API - sehen Sie, wie sich der Code verhält. Ein Beispiel ist das eines Faxmoduls. Als Benutzer der API mussten Sie ein Seitenbild vorbereiten und dem Code einen Befehl zum Übertragen der Seite senden. Bitten Sie den Programmierer, mit Ihnen den Code zu verfolgen, um zu sehen, wie dieses Szenario abläuft. Dann gehen Sie natürlich zum Szenario "Empfangsseite".
5. 80/20 - versuchen Sie zuerst, die allgemeineren Szenarien abzudecken.
6. Überlegen Sie sich einen Umschreibevorgang. Wenn der Code alt ist und die Schnittstellen gut definiert sind, hat sich die Technologie möglicherweise genug geändert, um dies zu rechtfertigen.
7. Ich hasse es, das zu sagen, aber ich denke darüber nach, einen neuen Job zu suchen.

Wenn Sie eine anständige Dokumentation wünschen, kaufen Sie eine Kopie von Pascal Analyzer (PAL), die ich in Delphi-Projekten verwendet habe, und sie war großartig - sie haben möglicherweise die Dokumentationsfunktionalität in ein Produkt aufgeteilt, mit dem ich nicht vertraut bin (Pascal Browser) Sie müssen also möglicherweise beides kaufen (<300 USD), aber PAL war ein großartiges Werkzeug, um zu verstehen, wo Variablen verwendet wurden, von wo aus Funktionen aufgerufen wurden, und um alle möglichen Probleme mit dem Code aufzugreifen.

Verwenden Sie PAL, um eine Vorstellung davon zu bekommen, wie der Code strukturiert ist, und geben Sie eine Liste mit etwa 1000 Verbesserungsvorschlägen an, wenn meine Erfahrung von Nutzen ist. Das Durcharbeiten der Liste verbessert die Qualität des Codes, vereinfacht ihn erheblich und erleichtert Ihnen das Leben für die Zukunft. Delphi selbst unterstützt Refactoring in neueren Versionen (in den letzten 5 Jahren oder so). Sie mussten alles in die dpr-Datei aufnehmen, damit sie wieder richtig funktioniert, als ich das tat. Denken Sie daran.

Wenn Sie Unit-Tests möchten, laden Sie DUnit herunter und erstellen Sie einige Tests mit dem Original-Codierer. Dies ist wahrscheinlich eine konstruktive Methode, um zumindest einen Teil ihrer Zeit zu nutzen.

Sie haben zwar noch nichts über eine Backend-Datenbank gesagt, sollten jedoch davon ausgehen, dass es eine gibt

1. Lassen Sie das Datenmodell, insbesondere die Spalten und PK-FK, dokumentieren
2. Richten Sie eine SQL-Ablaufverfolgung ein und zeichnen Sie alle Abfragen auf, die während der Verwendung der Anwendung ausgelöst wurden. Die Reihenfolge der Ausführung der Abfragen gibt Ihnen einen guten Überblick über den Ablauf der Anwendung und hilft auch beim Debuggen

Ich bin in der gleichen Situation, in der unser Architekt nach Australien gezogen ist und viel Vermächtnis hinterlassen hat, wie er in der Firma der letzten 8 Jahre war. Er erbte sein Vermächtnis von früheren Architekten, die Bauunternehmer waren.

Sie und andere haben bereits gute Punkte erwähnt, aber hier sind Probleme, mit denen wir konfrontiert waren, nachdem er gegangen ist. Vielleicht können Sie sich besser vorbereiten ...

1) (Technische Person) Kontaktdaten der Kunden, mit denen er zu tun hat.

2) Sein Konto, unter dem er Softwarelizenzen gekauft hat, Schlüssel, die jedes Jahr erneuert werden müssen, und Prozesse / Kosten, um sie zu erneuern.

3) Einrichtungsdokument für Softwarebibliotheken / -komponenten und -produkte von Drittanbietern, die in Ihre Produkte integriert sind. Wir hatten 4 Tage lang Mühe, eine Maschine zurückzubringen, die aufgrund von IT-Aufräumarbeiten und falscher Anweisungen verloren gegangen war.

4) Dokumente / Schritte, mit denen der Quellcode bei Software-Hinterlegungsfirmen, z. B. Escrow, hinterlegt wird.

5) Es gibt noch eine lange Liste, die aber möglicherweise auch nicht auf Sie zutrifft. Es gibt keine Dokumentation, die eine reale Person ersetzen könnte. Halten Sie daher Ihre Daten griffbereit, bleiben Sie in guten Worten und wünschen Sie viel Glück :)

Ich weiß auch nicht, ob dies das erste Mal für dich ist. Für mich habe ich mit 5/6 Arbeitgebern gearbeitet und immer Code mit einer schlechten Dokumentation oder überhaupt keiner Dokumentation geerbt. Also bleibt zusammen mit der ganzen Dokumentation einfach positiv :)