Wie soll ich mich erinnern, was ich vor drei Monaten bei einem Projekt gemacht habe?


72

Ich habe vor drei Monaten an einem Projekt gearbeitet, und dann tauchte plötzlich ein anderes dringendes Projekt auf, und ich wurde gebeten, meine Aufmerksamkeit zu verlagern.

Ab morgen gehe ich zurück zum alten Projekt. Mir ist klar, dass ich mich nicht daran erinnere, was ich genau getan habe. Ich weiß nicht, wo ich anfangen soll.

Wie kann ich ein Projekt so dokumentieren, dass ich jedes Mal, wenn ich zurückblicke, nicht länger als ein paar Minuten brauche, um von meinem Standort aus loszulegen? Gibt es Best Practices?


98
Es gibt einen Grund, warum Leute Ihnen sagen, Sie sollen sie verlassen
Ratschenfreak

5
Hängt das nicht wirklich davon ab, wie Sie das Projekt überhaupt verfolgt haben? Sollen wir davon ausgehen, dass Sie alles aus dem Gedächtnis und ohne weitere Dokumentation gemacht haben?
JeffO

4
@ratchetfreak Ich wollte gerade "Das ist nur für Entwickler nützlich" sagen, bis mir klar wurde, dass Sie dasselbe Prinzip auf alles anwenden können. Die meisten Dokument-Repositorys haben einen Notizenabschnitt oder eine Beschreibung. Zustellungen per E-Mail enthalten Nachrichtentexte (oft ignoriert). Dokumente können Änderungen und Anmerkungen nachverfolgt haben. Es gibt auch in der PM-Welt ein ganzes Ökosystem von Kommentaren und Commit-Nachrichten! </
epiphany

6
Ich benutze das Versionskontrollsystem, um mich daran zu erinnern, was ich das letzte Mal getan habe, und einen Bug-Tracker, um herauszufinden, was noch zu tun ist.
Lie Ryan

2
Oh ja, einmal nach einer dreimonatigen Arbeitspause wurde ich in einem Vorstellungsgespräch gebeten, mein letztes Projekt zu beschreiben. Ich habe es getan, aber als sie nach Details fragten, konnte ich mich nicht für mein ganzes Leben an sie erinnern. Sie haben mich abgelehnt, weil ich anscheinend ein Schwindler bin, wenn ich mich nicht daran erinnern kann. Dies geschah vor ungefähr 15 Jahren, aber ich erinnere mich noch daran.
Andrew Savinykh

Antworten:


35

Ich wollte nur einige Ratschläge einbringen, die in Ihrer aktuellen Situation nicht nützlich sein werden, aber Sie können jetzt damit beginnen, sie umzusetzen, um in Zukunft zu helfen.

Natürlich gibt es die offensichtlichen Kandidaten wie ToDo-Listen und Issue-Logs; Wenn Sie sich die kürzlich hinzugefügten Probleme ansehen, erhalten Sie einen Hinweis darauf, was Sie getan haben, als Sie aus dem Projekt entfernt wurden.

Bei früheren Projekten, an denen ich gearbeitet habe, wurde von den Mitarbeitern erwartet, dass sie im Rahmen des Qualitätsmanagementprozesses ein Projektprotokoll führen. Die Inhalte waren nicht sehr klar spezifiziert, aber die Idee war, ein tägliches Protokoll der Dinge im Zusammenhang mit dem Projekt zu führen, die für die weitere Arbeit in der Zukunft oder für Überprüfungsaktivitäten nach Abschluss nützlich sein könnten. zum Beispiel:

  • Beobachtungen über die Qualität des Projekts

    Dieser Code kann einige Refactoring verwenden

    habe eine schnelle Implementierung durchgeführt, um dies zum Laufen zu bringen, aber ABC wäre besser.

  • Aufgaben / Probleme , die Sie nicht offiziell in einem Issue Tracker aufzeichnen möchten

    msgstr "sollte diese Methode funktionieren lassen, x < 0aber das ist derzeit nicht möglich.

  • Gestaltungsentscheidungen - insbesondere nicht triviale.

    Unsere Standard-Sortierfunktion führt eine schnelle Sortierung durch, wobei jedoch die Reihenfolge der Artikel unter den hier benötigten Sortierbedingungen nicht gleich bleibt.

    Der offensichtliche Algorithmus wäre ABC, aber das schlägt hier fehl, weil xes negativ sein könnte, sodass wir die verallgemeinerte Form benötigen ( Wikipedia-Link ).

  • Probleme aufgetreten und wie Sie sie gelöst haben. Eine meiner persönlichen Meinung nach sehr wichtige: Wenn Sie auf ein Problem stoßen, notieren Sie es im Protokoll.

    Der Code wurde ausgecheckt, aber es wurde der Fehler XYZ0123 ausgegeben. Es stellte sich heraus, dass ich zuerst Komponente C auf Version 1.2 oder höher aktualisieren musste.

Die letzten beiden Punkte sind sehr wichtig. Ich bin oft auf eine ähnliche Situation oder ein ähnliches Problem gestoßen - manchmal in einem völlig anderen Projekt - und dachte: "Hmm, ich erinnere mich, dass ich einen Tag damit verbracht habe, aber was war die Lösung noch einmal?"

Wenn Sie nach einer Weile wieder zu einem Projekt zurückkehren, sollten Sie durch das Zurücklesen des Projektprotokolls (unabhängig davon, ob es sich um Ihr eigenes oder das des neuesten Entwicklers handelt) wieder in den Fluss zurückkehren, den Sie hatten, als Sie gegangen sind, und Sie vor einigen Ihrer Fallen warnen kann sonst wieder hineinfallen.


68

Aufgabenlisten sind magisch. Im Allgemeinen müssen Sie für jedes Projekt eine aktive To-Do-Liste führen, und selbst wenn Sie mit dem Programmieren beschäftigt sind, wenn Sie an etwas denken, das erledigt werden muss, und Sie es nicht sofort erledigen können, wird es in die Liste aufgenommen. Bewahren Sie diese Liste an einem bekannten Ort auf, entweder in einer Tabellenkalkulation oder einer Textdatei im Projektordner auf elektronischem Wege oder in Ihrem Papierlogbuch.

Wenn Sie das Projekt über Nacht (oder über das Wochenende) verlassen, machen Sie sich eine Haftnotiz und schreiben Sie das nächste, was Sie tun wollten, auf die Notiz und kleben Sie sie auf den Monitor. Das macht es wahrscheinlicher, dass Sie am nächsten Morgen schnell darauf zurückkommen.

Bearbeiten :

Ich sollte erwähnen, dass To-Do-Listen (speziell priorisierte To-Do-Listen, die nach Veranstaltungsort und Projekt getrennt sind) ein wichtiger Teil des Getting Things Done- Buches sind, das ich als sehr einflussreich empfand.


22
Und wenn Sie an einem agilen Projekt mit kleinen Aufgaben arbeiten, sollte der Rückstand Ihre primäre Aufgabenliste für dieses Projekt sein.
Bart van Ingen Schenau

1
Ich habe vor kurzem damit begonnen, das zu tun, was Sie im letzten Absatz erwähnt haben, und es hat mir massiv geholfen, morgens loszulegen.
TMH

5
Tatsächlich. Immer bergab parken. Es ist Gewohnheitssache. Ich verlasse niemals eine Codebasis, ohne mir im Code oder in meiner Aufgabenliste eine Notiz darüber zu machen, was als nächstes zu tun ist. Ich stelle außerdem sicher, dass alles, was ich noch zu tun habe, entweder in der Quelle (ich verwende die TODO: -Konvention in Kommentaren, die meine IDE erkennen und als Liste darstellen kann) oder in meiner separaten Aufgabenliste (I) enthalten ist haben nur die für alle Projekte, aber es ist kategorisiert und priorisiert).
Joeri Sebrechts

3
TODOs im Code sind ausgezeichnet, aber Sie müssen fleißig sein, wenn Sie sie dort platzieren, auch für winzige Kleinigkeiten. Es todoist auch nützlich, ein Ziel in Ihrem Makefile zu haben, das diese ausgibt.
Blrfl

4
trello.com ist ein Lebensretter. Sogar für jene Montag-Monring-Team-Meetings, bei denen ich mich nur schwer daran erinnere, was ich letzte Woche getan habe und woran ich in dieser Woche arbeiten sollte. Es ist auch kostenlos.
SimonGates

33

Was nun?

Jetzt, ab morgen, gehe ich zurück zu meinem alten Projekt und stelle fest, dass ich mich nicht mehr genau erinnere, was ich getan habe und wo ich anfangen soll!

Ich vermute, Sie haben im nächsten Abschnitt noch nichts getan. Das Nachschlagen einer Aufgabenliste wird also nicht funktionieren.

  1. Blockieren Sie einen Zeitraum. Tragen Sie dies in Ihren Kalender ein und nehmen Sie sich Zeit, um das Projekt zu überprüfen. Hier werden möglicherweise Dokumentation, Code, Anforderungen usw. überprüft.
  2. Akzeptiere, es wird eine Weile dauern, bis du wieder auf dem neuesten Stand bist. Stellen Sie sicher, dass alle Beteiligten dies erkennen. Stellen Sie sicher , dass Sie dies erkennen.
  3. Beginnen Sie mit einer kleinen Aufgabe. Bauen Sie Ihr Selbstvertrauen auf, indem Sie etwas Kleines tun. Wenn Sie eine Liste neuer Elemente haben, arbeiten Sie zuerst kleinere durch. Dies stärkt nicht nur Ihr Selbstvertrauen, sondern macht Sie auch wieder mit dem Projekt vertraut.

Wie können Sie dies in Zukunft für sich selbst verbessern?

Ich möchte wissen, wie ich das Projekt so dokumentieren kann, dass ich jedes Mal, wenn ich zurückblicke, nicht länger als ein paar Minuten brauche, um von meinem Standort aus loszulegen!

Zunächst benötigen Sie ein System, mit dem Sie Ihre Aufgaben nachverfolgen können. Hast du so ein System jetzt? Wie verwalten Sie Ihre aktuelle Projektarbeit?

Ich könnte morgen von einem Bus angefahren werden und mein Team hätte eine gute Vorstellung von weit über 90% meiner Aktionsgegenstände. Dies liegt daran, dass ich ein zusammenhängendes System zur Dokumentation meiner:

  • Sofortige Aufgaben (<1 Woche Artikel)
  • "Schön zu haben" ToDos
  • Meilensteine ​​und Makro-ToDos (wo Besonderheiten nicht aussagekräftig sind)
  • Anforderungen / Besprechungsnotizen

Außerdem verwende ich ein VCS und kommentiere meinen Code gegebenenfalls.

Dies funktioniert für mich und mein Team, da ich der Hauptentwickler bin. Sie können eine Art Fehlerverfolgungssystem für ein Team verwenden. Oder ein Rückstand bei der Arbeit mit Agile. Es gibt eine Menge Möglichkeiten. Wenn Sie wirklich daran interessiert sind, lesen Sie die Informationen zu " Getting Things Done" oder anderen relevanten Methoden zur Aufgabenverwaltung, die aufgrund Ihrer Beschreibung nahezu genau existieren.

Was ist der Punkt?

Die Besonderheiten des Systems sind weniger relevant, als dass es ein zusammenhängendes System ist und Sie es verwenden . Und dass du es benutzt. Und benutze es. Das ist wichtig. Wichtiger als ein schönes perfektes System, das Sie nicht benutzen. Tun Sie nicht "gut, der größte Teil meiner Arbeit ist hier, aber einige sind in meinem Kopf", oder Sie hassen es, wenn Sie sich wieder auf ein Projekt einlassen.

Stellen Sie außerdem sicher, dass in Ihren Kommentaren das "Warum" und nicht nur das "Was" für den Code erklärt wird. Es ist viel einfacher zu lesen, "das ist, um einen Fehler mit IE8 zu beheben" und sich daran zu erinnern, was der Code bewirkt, als einen Kommentar, der lediglich die technischen Details erklärt.


@TheIndependentAquarius kein Problem, ich bin froh, dass es hilfreich war. Diese Situation kann überwältigend sein.
Enderland

@TheIndependentAquarius wahrscheinlich, weil Kommentare im Allgemeinen mehr oder weniger Post-its / Stickies sein sollen. Die Art und Weise, wie Stack Exchange festlegt, dass "diese Antwort großartig war", besteht darin, eine Antwort zu bestätigen oder zu akzeptieren. Kommentare hier sollen nicht unbedingt dauern.
Enderland

Eine viel rationalisiertere Version dieser "To-Do" -Liste ist die Verwendung eines Issue-Tracking-Systems. Es gibt viele kostenlose Systeme und viele kostenlose Git-Anbieter haben ein solches System in ihren Dienst eingebaut (siehe: GitHub).
BTownTKD

@ BTownTKD Ich sage das in meiner Antwort :)
Enderland

Es ist eine gute Antwort; zur Hervorhebung hinzugefügt.
BTownTKD

14

Meiner Meinung nach gibt es zwei Teile, um ein Code-Projekt "wieder aufzunehmen":

  1. Bestimmen, wo Sie aufgehört haben
  2. Denken Sie daran, was Sie noch zu tun haben

Dies ist eines dieser Dinge, von denen ich denke, dass es Ihr "anderes Gehirn" ist, wenn Sie die Versionskontrolle auf die richtige Weise durchführen.

Wo hast du aufgehört ? Sehen Sie sich Ihren letzten Änderungssatz an, solange Ihr Code häufig festgeschrieben wird. Es wird höchstwahrscheinlich etwas in deinem Kopf joggen. Wenn nicht, schauen Sie sich die letzten paar an, beginnend mit den ältesten und wiedergegebenen Commits.

Was , was übrig was Sie tun müssen , sollte ein Rückstand diesem Zweck dienen (oder eine To-do - Liste, oder was auch immer Sie es nennen wollen. Grundsätzlich Elemente für die Zukunft).

Ich bin kein Vollzeit-Softwareentwickler. Ich bin ein Programmierer, der an den Nächten und Wochenenden hackt. Aus diesem Grund kann ich manchmal Tage und Wochen vergehen, wenn Arbeit oder andere nicht programmierbare Dinge eine höhere Priorität haben, ohne meinen Code mit einem Blick aufzurufen. Das oben Gesagte hat sich als sehr effektiv erwiesen.


10

Dies soll keine vollständige Antwort sein - es gibt bereits einige sehr gute, die wichtige Dinge wie die Verwendung Ihres VCS und Ihrer Projektverwaltungssoftware erwähnen -, sondern vielmehr einen Nachtrag, der einige Punkte hinzufügt, die ich in keinem anderen Punkt gesehen habe finde es sehr hilfreich, und ich hoffe, andere Leute finden es auch hilfreich.

1. Keine Aufgabe ist zu früh oder zu klein, um sie aufzuschreiben

Die Leute machen normalerweise TODO-Listen für Dinge, die sie in Zukunft planen , aber da das Programmieren Konzentration erfordert und wir jederzeit unterbrochen werden können , fand ich es hilfreich, selbst das aufzuschreiben, was ich gerade mache. oder was ich in wenigen Sekunden anfangen werde . Sie können fühlen Sie sich in der Zone, und Sie könnten möglicherweise nicht die Lösung vergessen , dass Sie treffen gerade in diesem aha Moment, aber wenn Ihre Mitarbeiter durch Ihre Würfel fallen Ihnen ein Bild von seinem infizierten Zehen zu zeigen , und du bist Nur wenn Sie anfangen, an Ihrem eigenen Arm zu nagen , können Sie ihn endgültig loswerden. Vielleicht wünschen Sie sich, Sie hätten eine kurze Notiz aufgeschrieben, auch wenn nur auf einer Post-It ™ -Notiz.

Natürlich ist ein anderes, beständigeres Medium besser (ich mag OmniFocus besonders ), aber es geht darum, es wenigstens irgendwo zu haben , auch wenn Sie in 20 Minuten fertig sind und das Post-It ™ dann wegwerfen. Obwohl Sie möglicherweise feststellen, dass diese Informationen nützlich sind, um Arbeitszeitnachweise oder Rechnungen an den Kunden zu senden, oder wenn Ihr Chef / Kunde Sie fragt, woran Sie gearbeitet haben und Sie sich nicht erinnern können. Wenn Sie all diese Notizen in eine Schachtel, eine Schublade oder einen Ordner legen, und wenn eine große Unterbrechung auftritt - ein unterbrechendes Projekt -, können Sie sie durchsehen und sich an viele Dinge erinnern, die Sie getan haben, um Ihren Code an den Punkt zu bringen, an dem Sie sich befinden Finden Sie es, wenn Sie zum Projekt zurückkehren.

2. Verwenden Sie ein Whiteboard an Ihrem Schreibtisch, um große Bildideen festzuhalten

Ich habe ein 3 "x 4" großes Whiteboard neben meinem Schreibtisch, sodass ich zu Beginn eines Projekts die Lösungen für alle Probleme finden kann, die ich in einem Projekt wahrnehme. Dies können Architekturdiagramme, Anwendungsfälle, Listen von Risiken und Hindernissen oder alles sein, was für Sie relevant erscheint.

Bei einigen formalisierten Ansätzen müssen Sie Diagramme und Anwendungsfälle usw. als "Liefergegenstände" in Papier- oder elektronischem Format generieren. Ich bin jedoch der Meinung, dass dies eine Menge zusätzlicher Arbeit verursachen und zu einer Reihe von Teilprojekten werden kann, die enden Sich vom eigentlichen Zweck des Hauptprojekts trennen und nur Teil eines formalisierten Prozesses sein, den Sie durchführen müssen, dem aber niemand viel Aufmerksamkeit schenkt. Ein Whiteboard ist nach meiner Erfahrung das Einfachste, was überhaupt funktioniert. Es ist so ausdauernd wie Sie möchten (mit einer Kamera) und ermöglicht es Ihnen vor allem, Ihre Ideen sofort umzusetzen.

Ich denke besser mit einem Stift in der Hand, so dass es für mich selbstverständlich ist, meine Gedanken auf eine weiße Oberfläche zu werfen. Wenn Sie dies jedoch nicht für richtig halten, finden Sie hier einige Fragen, die Ihnen bei der Entscheidung helfen können, was relevant ist :

  • Wenn ich der leitende Entwickler wäre und drei Monate auf Hochzeitsreise gehen würde, während andere Entwickler das Projekt abschließen würden, welche allgemeine Anweisung würde ich ihnen geben wollen? Welche Ideen möchte ich sicherstellen, dass sie Bescheid wissen, oder welche Ansätze möchte ich sicherstellen, dass sie umgesetzt werden? Welche Bibliotheken oder andere hilfreiche Lösungen sollten mir bekannt sein?
  • Wenn dieses Projekt meine millionenschwere Idee wäre, von der ich wusste, dass sie meine zukünftige finanzielle Unabhängigkeit sicherstellen würde, aber ich war für eine kritische Operation angesetzt, die mich 3 Monate lang außer Gefecht setzen würde das Projekt?

(Wenn ich Ideen zum ersten Mal niederschreibe, sorge ich mich nur darum, dass sie für mein gegenwärtiges Ich Sinn ergeben. Wenn sie einmal niederschlagen, kann ich sie kritischer betrachten und Änderungen vornehmen, um sicherzustellen, dass sie für mein zukünftiges Ich oder für andere Sinn ergeben Die Kommunikation mit anderen, während Sie sie anfänglich aufschreiben, kann zu einer Schreibblockade führen - ein Geist, der durch konkurrierende Ziele verstopft ist.

Ich empfehle, dass Sie das Geld ausgeben, um ein anständiges Whiteboard zu kaufen, mindestens 10 x 12 cm, und es an dem Ort aufhängen, an dem Sie normalerweise arbeiten. Es gibt viele Vorteile eines physischen Whiteboards gegenüber einem virtuellen System.

  • Es ist gross. Indem es viel Platz einnimmt, wird seine Präsenz spürbar, und die darin enthaltenen Pläne scheinen Teil Ihres Arbeitsbereichs zu sein, sodass Sie immer in die richtige Richtung weisen können.
  • Es ist permanent vorhanden: Sie haben keine bestimmte App oder Website gestartet, um darauf zuzugreifen, und Sie riskieren nicht, zu vergessen, wie Sie dorthin gelangen, oder zu vergessen, dass es vorhanden ist.
  • Es ist sofort verfügbar, wenn Sie eine Idee haben, die Sie durchdenken möchten.

Sie verlieren viele Vorteile, wenn Sie nur ein Whiteboard in einem Besprechungsraum verwenden und dann mit Ihrem Telefon einen Schnappschuss machen. Wenn Sie mit dem Programmieren Geld verdienen, ist es die Kosten eines anständigen Whiteboards wert.

Wenn Sie ein anderes Projekt unterbrechen müssen, das Ihr Whiteboard gefüllt hat, müssen Sie möglicherweise auf den Schnappschuss Ihres Telefons zurückgreifen, aber zumindest haben Sie diesen in 3 Monaten, wenn das "dringende" Projekt abgeschlossen ist und Sie müssen kehre zum anderen zurück. Wenn Sie es dann auf Ihrem Whiteboard neu erstellen möchten, dauert es wahrscheinlich nur 15 Minuten, und Sie werden feststellen, dass Sie es in diesem Prozess erheblich verbessern können, wodurch sich dieser kleine Zeitaufwand sehr lohnt.

3. Machen Sie die Stakeholder auf die Kosten für die Unterbrechung eines Projekts aufmerksam

Ich finde die Metapher eines Flugzeugs hilfreich: Das Starten und Abschließen eines Projekts ist wie das Fliegen eines Flugzeugs. Wenn Sie auf halbem Weg aus dem Flugzeug aussteigen, wartet das Flugzeug nicht nur darauf, dass Sie wieder dorthin zurückkehren, sondern Sie benötigen auch eine Möglichkeit, um vom aktuellen Projekt / Flug zum nächsten zu gelangen. Wenn Sie sich mitten in einem Flug von Phoenix nach Fargo befinden und erfahren, dass Sie diesen Flug unterbrechen müssen, um ein anderes Flugzeug von Denver nach Detroit zu nehmen, müssen Sie das erste Flugzeug in Denver landen (welches ist glücklicherweise nicht weit von Ihrer Flugbahn entfernt (was bei echten Unterbrechungen nicht immer der Fall ist) und jemand muss herausfinden, was mit der Fracht und den Passagieren zu tun ist. Sie werden nicht nur sitzen und ewig warten.

Für Projekte bedeutet dies, dass der Übergang von einem Projekt zu einem anderen einen hohen Zeitaufwand bedeutet und viele Probleme mit sich bringt, die gelöst werden müssen.

In einem Projekt passiert offensichtlich und unvermeidlich viel in Ihrem Kopf, während Sie arbeiten, und nicht jeder Gedanke kann auf ein schriftliches Medium serialisiert werden, und nicht jedes Jota der Gedanken, die serialisiert werden, bleibt beim Deserialisieren zurück. Obwohl wir unsere Gedanken teilweise schriftlich festhalten können, handelt es sich um ein sehr verlustreiches Format.

Das Problem (wie ich es sehe) ist, dass Projektmanager und andere Geschäftsleute Projekte als eine Reihe von Schritten betrachten, die oft nach Belieben neu angeordnet werden können (es sei denn, es besteht eine explizite Abhängigkeit von ihrem Gantt-Diagramm) und leicht unter Menschen verteilt werden können oder verzögert, bis es für das Geschäft am bequemsten ist.

Jeder, der schon viel programmiert hat, weiß, dass Softwareprojekte nicht wie Legoblöcke behandelt werden können, um sie nach Belieben zu verschieben. Ich finde, dass die Metapher des Flugverkehrs zumindest den Beteiligten etwas Konkretes gibt, über das sie nachdenken können, und das eindeutig nicht als eine Reihe von unterschiedlichen Schritten betrachtet werden kann, die aus einer Laune heraus neu angeordnet werden müssen. Es macht es zumindest leicht zu verstehen , dass solche Unterbrechungen Kosten verursachen. Natürlich ist es immer noch ihre Entscheidung, aber Sie möchten sie darauf aufmerksam machen, bevor sie ein Projekt unterbrechen, um Ihnen ein anderes zu geben. Seien Sie nicht kämpferisch, sondern bieten Sie hilfreiche Informationen und die hilfreiche Perspektive des Entwicklers, der bereit ist, alles zu tun, was er von Ihnen benötigt, sondern nur Informationen, die er möglicherweise nicht kennt, wenn Sie ihn nicht informieren.


Zusamenfassend:

  1. Notieren Sie alles , was Sie über zu tun, auch wenn Sie nicht denken, könnten Sie jemals möglicherweise benötigen abgewertet. Sogar ein kurzer Stift schlägt eine lange Erinnerung.
  2. Brainstorming des Gesamtbilds auf einem physischen Whiteboard, auf das Sie dauerhaft zugreifen können.
  3. Sie können Projektunterbrechungen vermeiden, wenn Sie Entscheidungsträgern bewusst machen, dass solche Unterbrechungen mit Kosten verbunden sind, und Sie zumindest Erwartungen haben, damit sie wissen, dass das Projekt bei der Wiederaufnahme etwas länger dauert.

1
Die Stakeholder gehen davon aus, dass sie einen professionellen Entwickler bezahlen, der Code kommentiert und dokumentiert, damit er (zu einem späteren Zeitpunkt) oder eine andere Person (jederzeit) das Projekt übernehmen kann. Natürlich ist ihre Annahme die meiste Zeit falsch.
JeffO

Und Sie sollten kommentieren und dokumentieren! Ich hoffe du hast nicht gedacht, dass ich etwas anderes vorschlage. (Und übrigens stimme ich Ihrem Kommentar zu.)
Iconoclast

2

Sie können die Projekthistorie von vor drei Monaten in Ihrer Versionskontrollsoftware nachschlagen. Lesen Sie Ihre Commit-Nachrichten und die neuesten Diffs, um eine Vorstellung davon zu bekommen, woran Sie gearbeitet haben.


Ich bin überrascht, dass diese Antwort nicht positiv bewertet wurde. Das Versionskontrollprotokoll ist eine hervorragende Methode, um festzustellen, wo sich jemand vor einigen Monaten befand, als das Projekt vorübergehend ausgesetzt wurde. Klare Logmeldungen helfen sehr. Diffs und Listen geänderter Dateien sind eine zusätzliche Möglichkeit, ein Bild davon zu erhalten, was mit dem Projekt vor dem Suspendieren vor sich ging. Schließlich gibt es mehr Entwickler, die eine Versionskontrolle verwenden, als Entwickler, die ein Fehlerverfolgungssystem (oder sogar eine einfache Aufgabenliste ) verwenden, was diese Antwort für mehr Menschen wertvoll macht als die hoch gelobte Antwort von Scott Whitlock.
Arseni Mourzenko

2

Die Verwendung eines Versionsverwaltungssystems mit geeigneten Verzweigungs- und Zusammenführungsstrategien in Verbindung mit einem Issue-Tracking-System (wie Redmine oder GitHub ) hilft Ihnen, die vorgenommenen Änderungen zu unterteilen, ihnen Anweisungen zu geben und Ihren fehlenden "Kontext" als zu dokumentieren ein natürlicher Teil des Workflows.

  1. Vergewissern Sie sich vor einer Codeänderung, dass ein Problem in Ihrem Fehlerverfolgungssystem protokolliert ist. Das deckt den fehlenden Teil Ihrer Arbeit "Was habe ich getan" ab.
  2. Erstellen Sie eine Verzweigung in Ihrem Versionsverwaltungssystem, und stellen Sie sicher, dass Ihre Änderungen in dieser Verzweigung NUR mit dem oben genannten Problem zusammenhängen. Auf diese Weise können Sie Änderungen leichter isolieren und einen Überblick über die Änderungen erhalten. Dabei wird die Frage beantwortet, wo ich aufgehört habe. Sobald Sie später wieder daran arbeiten.
  3. Sobald Sie mit der Änderung fertig sind, führen Sie sie wieder in Ihrem Kofferraum zusammen und schließen Sie das Problem.

1

Es gibt viele lange Antworten. Dies ist eine kurze Beschreibung dessen, was mir am meisten hilft:

  • Code bereinigen.
  • Code bereinigen.
  • Code bereinigen.
  • Versionskontrolle (Unterschiede und Kommentare festschreiben).
  • Eine Post-It Note oder eine Todo-Liste oder eine Kanban-Tafel (siehe zB Trello und Evernote)

Diffs, Commit-Kommentare, Post-It-Notizen, Todo-Listen oder Kanban-Boards können jedoch aufgrund fehlenden Kontexts im Laufe der Zeit falsch interpretiert werden. Hier ist also das Wichtigste:

CODE REINIGEN.


Inwiefern hilft Clean Code Clean Code Clean Code bei der Frage: " Wie soll ich mich erinnern, was ich vor drei Monaten bei einem Projekt getan habe? " Wäre es nicht sauber Architektur sauber Architektur sauber Architektur viel mehr helfen? Man taucht normalerweise nicht zuerst in Details ein. Es geht darum, sich einen Überblick zu verschaffen, bevor die Details untersucht werden. Der allgegenwärtige Onkel wird Ihnen dabei leider nicht helfen. Trotzdem stimme ich den beiden anderen Punkten absolut zu.
JensG

@JensG: Code ist die Architektur. In einem gut geschriebenen Programm kann ich die Spitze der Programmarchitektur in Funktion sehen main, was für ein sehr großes Programm eher abstrakt sein wird. Ich kann dann tiefer eintauchen und mir zum Beispiel die Architektur ansehen, wie das Programm sich selbst aufräumt. Weiter bedeutet sauberer Code, dass Funktionen / Variablen / etc. Namen haben, die Sinn machen und eine Aussage über ihre Bedeutung machen. Wenn ich stattdessen Spaghetti / Write-Only-Code schreibe, wache ich oft am nächsten Morgen / Monat / Jahr auf, schaue meinen Code an und der einzige Gedanke ist wtf-did-i-do-there. Es ist das gleiche, wenn ..
phresnel

... ein Buch lesen oder schreiben: Ist es Kauderwelsch mit einem Flesch-Kincaid-Lesbarkeitsindex von 10, mit großen Phrasen, vielen komplizierten Wortkonstruktionen, bei denen sich der Leser auf die Syntax anstatt auf die Semantik konzentriert, oder ist es einfach zu lesen? mit einem Index von etwa 80 und damit nicht im Weg der Geschichte selbst.
Phresnel

Obwohl ich den Wert von sauberem Code sehe (und in keiner Weise bezweifle), stimme ich dem Code als Architektur überhaupt nicht zu. Der Code kann für alle Standards perfekt sauber und lesbar sein, ist aber dennoch so geschrieben, dass Sie nicht den Überblick behalten. Als nächstes lautete die Frage: " Wie soll ich mich erinnern, was ich getan habe? " Und " Ich weiß nicht, wo ich anfangen soll. " Ich kann keinen Schnittpunkt zwischen dem aktuellen Status des (bereinigten) Codes und dem, wonach das OP sucht, erkennen: den genauen Wegpunkt im Prozess , der von der Idee zum Produkt führt.
JensG

@JensG: Ich erkenne deinen Standpunkt. Ich denke, wir interpretieren nur "Mir ist klar, dass ich mich nicht daran erinnere, was ich genau getan habe" anders. Für mich klang das eher wie "Ich merke, dass ich mich nicht erinnere, welche Algorithmen und Datenstrukturen ich codiert habe und wie ich sie erweitern kann" genau das habe ich versucht umzusetzen und das ziel davon ". Mehrdeutige menschliche Sprache. ...
phresnel

1

Wie kann ich ein Projekt so dokumentieren, dass ich jedes Mal, wenn ich zurückblicke, nicht länger als ein paar Minuten brauche, um von meinem Standort aus loszulegen?

Zunächst einmal bedeutet dies, dass das Projekt eine allgemeine Beschreibung und Codestruktur enthält, die Sie in wenigen Minuten leicht erfassen können - im Gegensatz zu zig Zeilen Code ohne sichtbare Struktur und ohne Kommentare.

Gibt es Best Practices?

Die folgenden Best Practices habe ich während meiner über 20-jährigen Karriere in sehr kleinen bis sehr großen Projekten angewendet und sie haben mir und meinen Teams gute Dienste geleistet. Bewerben Sie sich in der angegebenen Reihenfolge, wenn Ihr Projekt wächst:

  1. Mit der Versionskontrolle erhalten Sie einen kostenlosen Überblick darüber, was wann und von wem die Änderungen vorgenommen wurden. Sie können jederzeit auf eine frühere Version zurückgreifen.

  2. Modularisieren Sie Ihren Code (je nach Sprache und Programmierumgebung verwenden Sie Klassen, Module, Pakete, Komponenten).

  3. Dokumentieren Sie Ihren Code. Dazu gehören eine zusammenfassende Dokumentation am Anfang jeder Datei (was macht das? Warum? Wie wird es verwendet?) Und spezifische Kommentare auf der Ebene von Funktionen, Prozeduren, Klassen und Methoden (was macht das? Argumente und Rückgabewerte / Arten? Nebenwirkungen?).

  4. Hinzufügen TODOund FIXMEKommentare , während Sie Codierung. Dies hilft, sich an das Warum und Was von Macken zu erinnern, die unweigerlich in Ihre Codebasis eindringen und die Sie später dazu bringen werden, WTF zu fragen ?! . Z.B:

    //TODO shall actually compute X and return it
    ... some code that does not compute X yet (maybe returns a fixed value instead)
    
    //FIXME make this constant time instead of n^2 as it is now 
    ... some code that works but is not efficient yet
    
  5. Machen Sie eine Gewohnheit von Zeichnen von Diagrammen zu dokumentieren Struktur und komplexe Verhalten wie Sequenzen von Anrufen zwischen den Modulen / Objekten / Systemen usw. Ich persönlich gefallen UMLet als es schnell zu bedienen ist, erstellt schöne Grafik, und vor allem nicht im Weg bekommt . Aber Sie sollten natürlich jedes Zeichenwerkzeug verwenden, das Sie für die Arbeit finden. Denken Sie daran, dass der Zweck solcher Zeichnungen darin besteht, kurz und bündig zu kommunizieren und kein System mit kleinsten Details anzugeben (!!).

  6. Fügen Sie frühzeitig Komponententests hinzu. Unit-Tests eignen sich nicht nur hervorragend für Regressionstests, sondern sind auch eine Form der Verwendungsdokumentation für Ihre Module.

  7. Fügen Sie frühzeitig Code-externe Dokumentation hinzu . Beginnen Sie mit einer README-Datei, in der die zum Ausführen und Entwickeln des Projekts erforderlichen Abhängigkeiten, die Installation und die Ausführung des Projekts beschrieben werden.

  8. Machen Sie es sich zur Gewohnheit, sich wiederholende Aufgaben zu automatisieren . Zum Beispiel sollten Compile / Build / Test-Zyklen in irgendeiner Form skriptiert werden (zB in JavaScript grunt, in Python fabric, in Java Maven). Dies wird Ihnen helfen, schnell auf dem Laufenden zu bleiben, wenn Sie zurückkommen.

  9. Wenn Ihr Projekt wächst, fügen Sie weitere Dokumentationen hinzu, indem Sie Quelltextdokumente generieren (unter Verwendung von Kommentaren im JavaDoc-Stil und eines geeigneten Tools, um HTML oder PDF daraus zu generieren).

  10. Wenn Ihr Projekt über eine einzelne Komponente hinauswächst und eine komplexere Bereitstellung aufweist, fügen Sie auf jeden Fall eine Design- und Architekturdokumentation hinzu . Beachten Sie auch hier, dass der Zweck darin besteht, Struktur und Abhängigkeiten zu kommunizieren und keine winzigen Details.


0

Zusätzlich zu den Vorschlägen zu Projektverfolgung, Aufgabenlisten, Trello usw. habe ich einmal etwas gelesen, das Ihnen beim Üben von TDD hilft, wenn Sie sich immer von Ihrem Projekt entfernen und bei jeder Rückkehr zum Projekt (morgen) einen neuen Fehlertest durchführen nächste Woche oder nächsten Monat)

Setzen Sie sich, führen Sie Tests durch und lernen Sie, wo Sie aufgehört haben.


1
Dies hat zwei Nachteile. Erstens, wenn Sie die kontinuierliche Integration verwenden, kommt es nicht in Frage, dass Sie bewusst einen Test durchführen, der fehlschlägt. Zweitens, wenn Sie in einem Team von mehr als einem Mitglied sind, werden andere Personen es möglicherweise nicht zu schätzen wissen, wenn Sie einen fehlgeschlagenen Test durchführen.
Arseni Mourzenko

1
@ MainMa Ich habe nicht Commit gesagt. Nur vor Ort.
Pete

Ich empfehle jedem Entwickler, sich zu verpflichten, wenn er selbst für einige Tage nicht an einem Projekt arbeitet. Dinge passieren. Ihr PC kann gestohlen werden oder Sie können ihn möglicherweise morgen nicht starten, da der RAID-Controller ausgefallen ist. Sie können das Projekt verlassen und der andere Entwickler kann Ihren Platz einnehmen. Sie könnten von einem Bus angefahren werden. Sie können das Projekt lokal löschen, weil es zu viel Platz einnimmt oder weil der Virus Ihr Betriebssystem zerstört hat. Nein, es kommt nicht in Frage, sich auf einen nicht festgeschriebenen Code zu verlassen.
Arseni Mourzenko

1
@MainMa wird dann festgeschrieben und an einen Zweig mit dem Namen gesendet next-steps. Ich bin mir nicht sicher, was Ihre Bedenken in Bezug auf die Einzelheiten des Ansatzes zur Versionskontrolle mit der Grundvoraussetzung eines fehlgeschlagenen Tests zu tun haben, der Ihnen dabei hilft, Ihr Gehirn in Schwung zu bringen, wenn Sie zu etwas zurückkehren. Auch dies wurde zusätzlich zu den Standardansätzen wie Rückständen, Aufgabenlisten usw. vorgeschlagen
Pete

2
@MainMa: Die Versionskontrolle hat viel mit Backups zu tun, aber das ist nicht ihr primärer Zweck. Wenn Sie ein Backup-System benötigen und die Art und Weise, wie Sie die Versionskontrolle verwenden, verhindert, dass es diesen Zweck erfüllt, dann besorgen Sie sich eine Time Capsule oder ähnliches. Sie sollten niemals gezwungen sein, vorzeitig einen Commit durchzuführen, nur um Ihr VCS zu zwingen, als Backup zu dienen. Und Sie sollten niemals daran gehindert werden, etwas anderes Gutes zu tun, weil Sie eine Richtlinie befolgen, die "alles sofort festschreibt".
Bilderstürmer

0

Zusätzlich zu den Kommentaren / Aufgabenlisten / Commits ist es wichtig, realistisch zu sein.

Abhängig von der Größe, Komplexität und dem Status, in dem Sie Ihre Arbeit beendet haben, kann es eine Weile dauern, bis Sie wieder mit einem Projekt beginnen. Bei einer umfangreichen Codebasis vieler interagierender Komponenten kann es Tage dauern, bis die volle Geschwindigkeit erreicht ist.

Gute alte Geduld wird nützlich sein.

Wenn ich überwältigt bin, nachdem ich nach einer Weile zu einem Projekt zurückgekehrt bin, nehme ich in der Regel die einfachste und kleinste Aufgabe und setze sie um. Es verhindert, dass ich mich verliere, wenn ich versuche, mich an viele Dinge auf einmal zu erinnern, und erhöht ein wenig das Selbstvertrauen. In den meisten Fällen erledige ich in wenigen Stunden automatisch immer größere Aufgaben.


0

Ich führe täglich ein Tagebuch über meine Arbeit. Was habe ich heute gemacht, was war heute schwierig, was ist der nächste Schritt, welche Ideen hatte ich heute für die Zukunft. Ich füge auch ein bisschen Erzählung darüber hinzu, wie der Tag war: Gab es ein interessantes Gespräch oder Treffen? Hat etwas Wut oder Vergnügen? Dies hilft, die Dinge in die richtige Perspektive zu rücken, wenn ich später mein Tagebuch lese.

Wenn ich nach einer Weile zu einem Projekt zurückkomme, habe ich die letzten Einträge im Tagebuch gelesen, um mich mit dem Projekt vertraut zu machen. All diese kleinen, alltäglichen Details sind unglaublich wichtig, um sich an den Entwicklungsprozess zu erinnern. Sie unterscheiden sich erheblich von einer Aufgabenliste oder einer normalen Projektdokumentation, da sie Sie daran erinnern, wie es war, an dem Projekt zu arbeiten, und nicht nur, wie man das Produkt verwendet.


dies scheint nicht alles zu bieten erhebliche über Punkte gemacht und erläutert vor 11 Antworten
gnat

0

Für mich ist es die einfachste Methode, Projekte wieder aufzunehmen, einfach, Ihre Arbeit ständig zu protokollieren. Microsoft 'OneNote' eignet sich besonders zum Speichern und Gruppieren von Notizenseiten. Insbesondere die Suchleiste erleichtert das schnelle Auffinden Ihrer Notizen.

Die folgenden Aufgaben in OneNote helfen mir, die Projektfortschritte fortzusetzen:

  • Tägliche / wöchentliche Protokolle - Führen Sie ein tägliches oder wöchentliches Fortschrittsprotokoll, um festzustellen, welche Fortschritte Sie bereits mit einem Projekt erzielt haben.

  • Aufgabenliste - Ich habe eine allgemeine Aufgabenliste, aber ich führe auch eine separate Aufgabenliste für die Projekte, an denen ich arbeite, damit ich mich daran erinnere, was ich noch für ein Projekt zu tun habe. Manchmal lasse ich auch // TODO: Elemente in meinem Code.

  • Projektnotizen - Zu den von mir notierten Elementen gehören Links zu Issue- / Project-Tracking-Elementen, Codeausschnitte, aufgetretene Probleme, getroffene Entscheidungen, Pläne und Beschreibungen möglicher Lösungen, eine Liste mit Codeänderungen, Links zum Code-Repository-Verzeichnis, E-Mails für das Projekt und Links zu Projektdokumentation.

Wenn ich also zu einem Projekt zurückkehre, kann ich meine Notizen öffnen und fast sofort sehen, wie viel Fortschritt im Projekt erzielt wurde, wie viel Arbeit noch zu tun ist und sogar meinen Gedankengang sehen.


-2

Für einfache Projekte mache ich das:

  1. Eine einfache README-Datei im Stammverzeichnis (die daher auch in der Versionskontrolle landet), in der ich alles notiere, was während der Entwicklung auftaucht: Dinge, die zu tun sind, Fehler, Verbesserungen / Ideen. Dies ist die erste Datei, die ich lesen werde, falls ich das Projekt auf den Backburner stellen muss.
  2. TODO / FIXME / XXX-Kommentare
  3. Ich benutze oft auch ToDoList
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.