Cosa dovresti lasciare per i tuoi successori?

• Account e amp; Le password
• Informazioni sul server
• Buon codice
• Documentazione
  • Diagrammi di database e amp; le spiegazioni sono incredibili
  • Elenco di stranezze nel codice
• Procedure
• Spiegazione di processi manuali o di lavoro occasionale, non ovvio
• Elenco di programmi utilizzati o trovati utili
• Informazioni di contatto;)

Una tazza di caffè strong e una nota di scuse.

È stato lasciato ciò che desidero I .

• Documentazione. Quanto è difficile scrivere alcuni commenti? Crea note, note di distribuzione, spostando le note di sistema. Cosa fare quando si riavvia e tutto è andato.
• Carte. Scrivi perché è stato fatto in questo modo, quindi non devo chiedermi perché non lo stai facendo in un altro modo. Come funziona il sistema di backup, in che modo il server risponde a carichi, test, casi di test, casi d'uso.
• Note. "Quando si utilizza il database, non dire mai SELECT * FROM clients . Non siamo sicuri del motivo, ma scarica il database" .

Il mio indirizzo email, o forse anche il numero di telefono.

Nella mia esperienza è difficile ottenere ogni dettaglio scritto, quindi la cosa migliore è essere disponibili (in una certa misura) se i tuoi successori hanno bisogno di maggiori informazioni.

Documentazione dei programmi che hai scritto, ad es. il loro scopo, la posizione dei file di origine per lo sviluppo futuro, le password, ecc.

Questo può essere all'interno del codice come un commento o all'esterno in bella vista.

Più che documentazione, mi piacerebbe sapere perché alcune decisioni sono state prese quando sono state fatte. Attualmente stiamo usando SWIG su un progetto e uno degli altri sviluppatori voleva sapere perché non abbiamo usato Boost :: Python. La semplice risposta è stata che il cliente non ha consentito l'uso di Boost al momento. Ora è una storia diversa.

Tali cose li aiuteranno non solo nella comprensione del progetto, ma anche quali limitazioni / vincoli / sfide avranno superato. Darà loro un punto di partenza per la manutenzione futura e l'aumento delle funzionalità.

Una cosa che non ho visto nominare nessun altro (anche se avrei potuto trascurarlo) è documentare come configurare un ambiente di sviluppo. Mi rendo conto che la maggior parte delle volte si tratta solo di installare alcune cose, ottenere l'ultima, compilare e il gioco è fatto. Tuttavia a volte c'è molto di più (SharePoint è una situazione che viene in mente) e documentare quale condensatore di flusso deve essere configurato in che modo sarà molto utile per la povera anima che ti segue.

Se si tratta di un programma desktop, come creare l'intero sistema da zero (possono essere diversi programmi separati), come creare un pacchetto per la distribuzione (quali dipendenze ha, ad esempio versioni di .NET) e come distribuire a server per il download se applicabile o masterizzarlo su un CD o DVD.

Se si tratta di un programma basato sul Web, FTP e (se applicabile) l'accesso SSH al server e quali strumenti sono utilizzati per creare e testare il codice localmente.

Se si tratta di un sistema integrato, istruzioni complete sulla creazione dell'immagine binaria, quali strumenti sono utilizzati, come scaricare e flashare il codice nel prodotto, come configurare il filesystem sul dispositivo, se presente.

Recentemente ho lasciato un lavoro in circostanze simili a te (non ero lo sviluppatore solo , ma in realtà c'erano solo due di noi, quindi avevo molta conoscenza che l'altro ragazzo non ha avuto (e viceversa, ovviamente)).

In termini di documentazione normale, è importante documentare una panoramica dell'intero sistema. I singoli componenti sono già documentati nel codice, ma l'interazione tra i componenti e il motivo per cui ciò è necessario o perché è necessario parlare con quel componente è importante e non è sempre facile individuarlo solo eseguendo il debug / guardando il codice.

Poi, per circa un mese prima che me ne andassi, ogni volta che facevo qualcosa che solo io potrei fare, ho scritto esattamente cosa è successo, cosa dovevo fare e perché. Solitamente si trattava di "un errore nel componente xyz, per risolverlo sapevo di cercare nel file abc a causa di X, quindi dovevo fare questo, questo e questo".

Naturalmente, ho lasciato il mio indirizzo e-mail e il numero di telefono nel caso in cui qualcosa fosse venuto fuori che non riuscivano a capire da soli. Ho ricevuto alcune chiamate nelle prime settimane, ma lentamente sono scese.

Vorremmo tutti un diagramma di flusso dati completo del sistema con un elenco di requisiti funzionali. Più che probabilmente non l'hai mai capito quando hai scritto il sistema in primo luogo! Come la maggior parte dei posti, la migliore documentazione è probabilmente il codice stesso, quindi quello che mi piacerebbe di più è un codice ben documentato. Linee e righe di commenti nel codice che spiegano cosa stai cercando di fare sia tecnicamente che funzionalmente.

La regola numero 1 per la documentazione non è cosa fa ma perché . Qual è il retroscena dei programmi che vengono eseguiti e cosa fanno?

Penso che ciò che mi piacerebbe vedere nelle documentazioni oltre al solito sarebbe quello che le caratteristiche sono state tralasciate. Per quale motivo alcune idee sono state NOT implementate o una determinata piattaforma o metodo NON utilizzato (che in caso contrario era una scelta ovvia).

Questo assicura che il successore sappia sempre cosa non fare o se è più capace, quindi forse può escogitare un lavoro e far funzionare alcune funzioni.

Questo è particolarmente applicabile ai progetti open source. Puoi risparmiare un sacco di tempo e potenza del cervello!