Ich bin gestern von meinem derzeitigen Arbeitsplatz zurückgetreten, und ich nehme es auf mich, meine Projekte zu dokumentieren, damit ich sie leicht übergeben kann.Dokumentieren Code beim Verlassen einer Firma
Wenn ich bedenke, dass mein Code bereits zu einem guten Standard kommentiert ist, was sollte ich sonst noch tun, um meinen Kollegen zu helfen, meine Projekte zu übernehmen?
Wenn Sie mit einem neuen Code arbeiten, der von jemand anderem geschrieben wurde, ist das erste, was dem neuen Typ (oder Mädchen) fehlt, ein Überblick über das System. Welche Subsysteme gibt es, welchen Zweck haben sie und wo sollte man eine gegebene Aufgabe erledigen, sind einige Fragen, die einem einfallen.
Ein kurzes Startdokument, das den Gesamtsystementwurf (und die Gründe, warum dieses Design gewählt wurde) vielleicht mit einigen Diagrammen erklärt, wäre etwas, worüber ich mich freuen würde, wenn ich an einer von jemand anderem geschriebenen Software arbeite .
Einverstanden. Setzen Sie sich und denken Sie darüber nach, was Sie brauchen, wenn Sie sich Ihrer nächsten Firma anschließen. –
Ich füge eine andere Sache hinzu, (ein anderes Dokument für die bekannten Bugs und nicht gelöst) –
Also, ein breiter Überblick und einige grundlegende Fragen und Antworten? Die nicht aufgelösten/unvollständigen Funktionen sind eine gute Idee, um aufzuschreiben. – GenericTypeTea
Persönlich schreibe ich alle meine Dokumente in einem Top-Down-Stil, zunächst Definitionen zu allen Begriffen (um ein gemeinsames Vokabular zu etablieren) und dann erklärtes Thema in breiten Begriffen zu erklären, verfeinert Details weiter unten im Dokument. Also wird diese Art von Dokument, das alle wichtigen Teile des Systems abdeckt, ganz gut funktionieren. Es wäre auch schön, wenn Sie in Ihren Projekten Argumente für architektonische Entscheidungen liefern würden.
In Bezug auf Rationalität für alte Projekte ... Wie erklärst du die Gründe, warum du vor 18 Monaten etwas gemacht hast, von dem du jetzt weißt, dass es falsch ist ... oder eher nicht falsch war, aber du weißt jetzt, dass es nicht der beste Weg ist? – GenericTypeTea
Ich schreibe persönlich alle meine Gedanken in ein kleines "easy to use" -Wiki..wenn etwas falsch läuft, ich muss nur mein Wiki durchsuchen ... danach kann ich nur mit meinem Kollegen über dieses Thema reden und es schreiben unten in meiner Dokumentation. Für mich ist es wichtig, alles niederzuschreiben. Manchmal ist es ein Overkill von Informationen, aber es funktioniert für mich. :-) – bastianneu
@GenericTypeTea - In diesem Fall können Sie dokumentieren - 1) warum dieses Design zu diesem Zeitpunkt ausgewählt wurde 2) warum es jetzt als falsch/veraltet betrachtet wird und 3) warum es nach der Tat/wie nicht geändert werden konnte Du hast vor, es zu ändern. – samitgaur
UML-Sequenzdiagramme für komplexe Klassen-/Systeminteraktionen, Klassendiagramme für komplexere OO-Designs und Diagramme auf Systemebene, die zeigen, wie verschiedene Systeme und Apps miteinander verbunden sind.
Sie können das Design des Projekts erklären, wie einige wichtige Funktionen funktionieren und vielleicht können Sie zukünftige Erweiterungen, die Sie geplant haben, dokumentieren.
Überlegen Sie, ob Sie Ihre Top-Level-Übersichtsdokumentation zu einem Wiki machen - es ermöglicht Ihren zukünftigen Kollegen, sie einfach zu bearbeiten und zu erweitern.
Und eine Begründung (wie erwähnt) ist sehr nützlich: Warum haben Sie die Lösung A gewählt, wenn die Lösungen B und C für einen zufälligen Beobachter so viel besser aussehen? Es kann alle möglichen endlosen Diskussionen im Keim ersticken.
Das mag selbstverständlich sein, aber wenn die Projekte nicht "out of the box" kompilieren/laufen, wenn sie zum ersten Mal in eine neue Entwicklungsumgebung (natürlich sollten sie) gehen, ein Schritt-für-Schritt Schritt-Anleitung, wie man alles in Gang bringt, wird die neuen Leute vor vielen Kopfschmerzen bewahren.
Ich wünschte, ich hätte hier nichts Nützliches zu sagen, aber da der Empfänger von Code durch mehrere Abschwünge, Skill Rebalancings usw. übertragen wird, würde ich gerne wiederholen und ein paar Punkte zu den vorherigen Antworten hinzufügen.
Ich nehme an, Ihr Management hat eine oder mehrere Personen ernannt, die Ihre Arbeit übernehmen.
Sie sagten, Sie brauchen es sowieso nicht, aber dies ist nicht die Zeit, Kommentare zum Code hinzuzufügen.
Es wurde bereits darauf hingewiesen, dass der neue Besitzer der Software einen Überblick auf hoher Ebene benötigt, was die Software macht und was dazu benötigt wird. Halten Sie dies kurz und versuchen Sie nicht, dass es sich in "wie sollte die Software ausgesehen haben" bewegt hat, kümmern Sie sich nicht um die Neugestaltung des Systems aus dem Grab.
Dann gehen Sie zu praktischen Fragen: Wer sind die Stakeholder, Tester und alle anderen, die beteiligt waren und werden können und über diese Software wissen.
Wo sind die Anforderungen andere Dokumentation und PRs, gibt es etwas Besonderes in den PR-Anforderungen sind bevorstehende Anforderungen?
Wo in der Versionskontrolle ist die Software, ist alles drin? "Ja wirklich?"
Was ist nötig, um die Software zu bauen?
Die wertvollste Zeit wird für die Überprüfung der letzten beiden Punkte aufgewendet: Erneutes Erstellen einer kompletten Build-Umgebung aus der Versionskontrolle und Erstellen (Testen/Ausliefern) von der Maschine des neuen Eigentümers. Wenn es Zeit gibt, beheben Sie ein einfaches Problem.
Viel Glück im neuen Job!
Jemand anderes hat bereits erwähnt, dass Sie Ihre gesamte Toolchain dokumentieren, um jemandem beim Einrichten der Entwicklungsumgebung zu helfen. Eine andere Sache, die ein bisschen zu meta sein könnte, ist zu dokumentieren warum Sie diese Werkzeuge verwenden.
Nichts ist schlimmer, als irgendwo neu anzufangen und das ganze MS Word von den Wurzeln auszustreifen, nur um herauszufinden, wann man gerade dabei ist, dass das deutsche Verkaufsbüro seine TPS-Berichte erstellen lassen muss in diesem Format und kann den Wizbang-JSON, mit dem Sie ihn ersetzen wollten, nicht verwenden.
Ich stimme für das Schließen dieser Frage als Off-Topic ab, da es sich nicht um die Programmierung handelt. –