Determinare la giusta quantità di documentazione


10

Dove attualmente lavoro l'approccio generale è -

evitare la documentazione il più possibile

Documenta solo se una squadra diversa ne avrà bisogno

solo per chiarimenti, non intendo la documentazione in codice - questo lo facciamo, intendo tutta la documentazione che circonda il processo di progettazione - se si tratta di schemi UML o DB, diagrammi di classe e documenti di parole con specifiche e simili.

Elencherò il motivo del mio capo per non documentare:

  1. richiede tempo: concentrarsi sull'attuazione
  2. se il design cambia, allora la documentazione dovrebbe cambiare, doppio problema
  3. alla fine ottieni solo centinaia di pagine che nessuno vuole leggere, e nessuno le modifica davvero, quindi col tempo diventerà obsoleto
  4. È un dolore - nessuno vuole davvero farlo

Ora mi rendo conto che lavoriamo più velocemente, ma ricordo anche il tempo in cui sono arrivato e mi sono immerso direttamente in un vecchio codice, senza capire nulla.

In realtà, ancora non ricevo la maggior parte di questo vecchio codice, e a volte quando arrivo vedo molte patch di diversi sviluppatori che cercano di apportare piccole modifiche.

Penso davvero che la mancanza di documentazione promuova questo tipo di patch e la mancanza di comprensione del sistema in senso lato.

la mia domanda è:

Come possiamo bilanciare la documentazione in modo da promuovere la conoscenza continua tra il team ed essere ancora veloci ed efficienti?


Ho lo stesso problema al mio posto, tranne per il fatto che il mio team non scrive nemmeno commenti sul codice!
MattDavey,

1
Documentano almeno i requisiti minimi e le specifiche? In caso contrario, come fai a sapere che hai codificato la cosa giusta se non ci sono requisiti per confrontare il prodotto finito?
FrustratedWithFormsDesigner,

specialmente con le lingue moderne la documentazione tecnica è molto più importante della documentazione del codice. il codice dovrebbe essere autoesplicativo.
AK_

Mentre è davvero una buona idea evitare troppa documentazione, il tuo capo lo fa solo per tutte le ragioni sbagliate.
Chris dice di reintegrare Monica il

Puoi dare un'idea del settore in cui opera la tua azienda? Alcuni settori hanno requisiti legali per quanto riguarda il livello minimo di documentazione richiesto.
tehnyit,

Risposte:


5

Ho trovato QUALUNQUE documentazione migliore di NESSUNA documentazione. La quantità appropriata è di solito determinata dalla quantità di tempo che dobbiamo fare o da quanto odiamo le telefonate e le e-mail di supporto.

Sembra che i membri del tuo team abbiano aspettative non realistiche sui loro ricordi, o si vergognino delle loro capacità di scrittura e non sono disposti a esercitarsi.

Mi rendo conto di essere in una minoranza (specialista inglese che ha studiato ingegneria del software nella scuola di specializzazione) qui, poiché non trovo la documentazione come un lavoro di routine. È uno strumento professionale prezioso. Potrei non trovare la scrittura così difficile da fare come alcuni dei miei colleghi, ma è soprattutto perché ho più pratica. Non considero un progetto finito a meno che non abbia documentazione, e di solito lo scrivo per motivi puramente egoistici: così posso dare alla gente qualcosa da leggere invece di prendere telefonate ed e-mail, o così posso ricordare di cosa stavamo parlando per ultimo mese o giù di lì, posso fare riferimento a come ho fatto qualcosa se ho bisogno di sostenerlo nel cuore della notte.

Il modo migliore per avvicinarsi alla documentazione è scriverlo COME SI VA, esattamente come scrivere codice di prova. È sorprendente come alcuni modelli pre-scritti (con intestazioni, matrici di codice, ecc.) Possano rendere la documentazione più semplice e veloce da eseguire. In questo modo è possibile acquisire il cambiamento in tempo reale e avere meno terreno da percorrere nel tempo. In questo modo sei più efficiente, poiché puoi fare riferimento alla documentazione di cui hai bisogno e cambiarla lungo il percorso. Farlo in un wiki, ad esempio, semplifica gli aggiornamenti e puoi evitare problemi con la versione del documento se l'ultimo e il più grande sono sempre online nello stesso posto e puoi semplicemente inviare collegamenti a persone che hanno bisogno di leggerlo.

Se trascorri un po 'di tempo a documentare, TUTTI lavorerai più velocemente, specialmente quando qualcuno nuovo si unisce al team, dal momento che non dovranno passare tutto quel tempo a capire tutto. Capire le cose è una parte divertente del nostro lavoro, ma non è divertente quando devi farlo in fretta per sistemare la produzione. Tutti risparmeremmo molto tempo se tutti scrivessimo un paio di note in più.

Il tuo team ha gli stessi problemi con i test o la scrittura del codice di test? In caso contrario, sarà una vendita più semplice.

La tua documentazione è utile in molti modi:
1) Per te, proprio ora e per i tuoi colleghi, mentre lavori al progetto.

2) Ai tuoi clienti. La documentazione (inclusi i diagrammi) che puoi mostrare agli utenti semplifica le discussioni durante le riunioni, soprattutto se stai discutendo di sistemi complicati. Anche se la documentazione è incompleta, è un punto di partenza.

3) Alle persone che erediteranno il tuo lavoro (che potresti anche essere tu, tra tre anni). Molti dei miei colleghi più giovani pensano che ricorderanno le cose per sempre. So che non lo ricorderò oltre questa settimana se non lo scrivo. Avere la documentazione ti evita di dover passare mezza giornata a ricordare come hai strutturato qualcosa e a doverlo capire di nuovo.

4) A te e agli altri, se la situazione diventa politica o controversa. Come qualcuno che prende appunti durante le riunioni, per tenermi sveglio e combattere la noia, sono stato spesso l'unico con la versione scritta di una decisione. La persona che l'ha scritto vince la disputa. Ricordalo la prossima volta che qualcuno dice "Ricordi quell'incontro che abbiamo avuto lo scorso inverno nella sala conferenze 4, quando stavamo andando oltre X? Fred era lì, e chi è quel tizio della contabilità?"


1
+1 per il punto 3. La mia documentazione personale mi ha salvato moltissime volte.
Brandon,

Lancio il mio nello stesso repository git del codice, di solito in Markdown (occasionalmente in LaTeX, quando sono coinvolti un po 'di matematica).
TRiG

4

Ai miei ultimi datori di lavoro, abbiamo avuto un wiki "di sviluppo". Pezzi significativi di funzionalità (nuovo feed di importazione / esportazione, come funziona il sottosistema di sicurezza, dove il sistema memorizza i documenti caricati, ecc.) Vengono tutti documentati lì. Di solito è un elemento obbligatorio da completare prima del passaggio di revisione del codice. Di solito c'è un po 'di resistenza all'inizio, ma una volta che qualcuno ha bisogno di andare a cercare un po' di informazioni ed è lì, hai un altro convertito.

La cosa bella di averlo in un formato wiki è che sei molto meno incline a fare tutta la bella formattazione di Word e così e solo scrivere le informazioni reali che devi salvare. La maggior parte (se non tutti) i pacchetti wiki ti permetteranno di caricare documenti o immagini (come diagrammi UML di Visio o wireframe dell'interfaccia utente), in modo da poter avere anche pezzi visivi.

Come la maggior parte delle cose, penso che dovresti mirare a fare l'importo minimo che potrebbe funzionare. Non è la stessa cosa di nessuno però.


Questo è un ottimo suggerimento. Alcune wiki consentono di esportare i contenuti in un documento .rtf. Quasi perfetto per il PHB.
tehnyit,

Utilizziamo XWiki, in particolare per la sua capacità di generare documenti in PDF, RTF e HTML. Malvagio.
Jennifer S,

2

Non è possibile evitare di allocare tempo per scrivere la documentazione corretta. Equilibralo come desideri in base alla quantità di lavoro che ti viene dato, ma lascia un buon 15-20% del tuo tempo per documentare ciò che hai fatto. Tutti i membri del team devono essere d'accordo con questo, incluso il proprio manager, altrimenti documenterai solo a beneficio degli altri e non otterrai nulla in cambio. La documentazione deve essere parte integrante del processo di sviluppo.


1

La documentazione dovrebbe dirti PERCHÉ hai fatto qualcosa mentre lasciavi la parte HOW al codice attuale e QUALE parte ai test unitari. Nulla di più è un dolore. Questo di solito è abbastanza buono per le persone intelligenti che vogliono solo un punto di partenza.

Inoltre, non dimenticare di mantenere un'architettura generale di alto livello di ogni grande componente della tua base di codice. Rende molto facile indurre nuovi membri del team.

Infine, ogni volta che aggiungi una correzione stravagante, collega al tuo database di bug da un commento - molto utile.


1

Il tuo capo ha ragione, non stampare alcuna documentazione UML che nessuno leggerà. Quello che facciamo nel nostro team è navigare dal vivo nel modello usando le viste del diagramma di classe. Il principio è aggiornare sempre MOF, il modello UML vive dal codice e lascia che il diagramma di classe sia solo un visualizzatore del modello ma non del modello stesso.

Funziona davvero bene perché tutta la complessità è fatta nel backoffice a livello di modello. Posso riformattare il mio progetto, scrivere java doc o scrivere documentazione uml nel modello. È una specie di click and go. Quando fai clic ottieni la documentazione live. Se qualcosa non è chiaro, apro il diagramma di classe e inizio a giocarci. Elimina dai classificatori di diagrammi, aggiungi nuovi classificatori, ingrandisci e rimpicciolisci, mostra associazione, elimina associazione ecc ... Il modello non viene modificato perché non creo alcuna nuova informazione sul modello, li utilizzo e basta.

È davvero importante aprire il diagramma di un pacchetto ed essere in grado di leggere direttamente nel diagramma di classe un commento su ciò che questa classe dovrebbe essere. Cosa dovrebbe fare questo metodo e qual è il flusso ecc ....

UML è eccezionale, molto utile, ma dovremmo smettere di usare lo sviluppo guidato dal modello al fine di dare maggiore flessibilità e più iterazione nelle fasi di modellazione / sviluppo. Il diagramma delle classi è aggiornato in tempo reale dal codice e la documentazione è sempre accurata e disponibile solo con un clic. Non menzionerò uno strumento, ma se usi Java ed Eclipse è facile trovare quale strumento che uso :-)

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.