La documentazione dovrebbe essere una politica aziendale o la responsabilità di ogni programmatore? [chiuso]

Comprendo il tuo dolore quando si tratta della mancanza di documentazione. Mi trovo costantemente su progetti senza requisiti chiaramente definiti perché il documento dei requisiti esiste a qualcuno da qualche parte in seguito a una conversazione che ha avuto luogo quattro anni fa.

Sento che dipende in parte dal progetto, dalla documentazione e dalla tua posizione, tra gli altri fattori. Se sei nella parte inferiore della tua catena alimentare, direi che ci sono dei limiti a quanto puoi imporre una documentazione adeguata, oltre a documentare il tuo codice tanto quanto ti è stato assegnato il tempo. Le persone per cui lavoro ... beh, in genere sono piuttosto prive di codice, quindi quando metto da parte il tempo per fare documenti specifici per la progettazione e cose del genere, tendo a ottenere "oh .. giusto sì ... è così importante ... giusto "e non riesco a farlo restare con il resto dell'equipaggio.

La migliore sommatoria di una risposta che posso fornire è che la responsabilità risiede in entrambe le parti in una certa misura. Sì, la compagnia dovrebbe avere delle politiche che dettano la documentazione, ma al posto di ciò, non aver paura di intervenire e fare ciò che puoi, così quando un progetto di quattro anni finisce nelle mani di qualcun altro hanno qualcosa su cui lavorare. / p>     

Gli standard di documentazione dovrebbero essere controllati dalla società. Se non esiste ancora una politica del genere, la direzione dovrebbe riunirsi con gli sviluppatori e concordare un ragionevole insieme di documenti che è obbligatorio per ogni singolo progetto.

Dovrebbe essere la politica aziendale, assolutamente.

Ecco perché (come hai accennato): turnover.

Affinché un team di software competente funzioni senza intoppi, dovrebbe sempre presumere che ogni singolo sviluppatore possa essere colpito da un camion in qualsiasi momento. La documentazione dovrebbe essere fatta in modo tale che ogni programmatore decente possa essere lasciato cadere nello sfortunato ruolo dello sviluppatore morto in qualsiasi momento - con un minimo di fastidi e tempi di accelerazione.

La cosa complicata è che non puoi facilmente misurarlo. Dipende davvero dalla situazione e dalla squadra. I negozi Agile potrebbero non avere molta documentazione formale, ad esempio, ma se hanno processi validi, non avrà molta importanza. Sul rovescio della medaglia, un negozio di Waterfall hardcore che fa affidamento su una documentazione strong sarà molto più difficile se la documentazione viene trascurata e non aggiornata e alcuni sviluppatori senior vengono investiti da un camion.

In ogni caso, questo dovrebbe essere dettato dalla compagnia. Dopotutto, se la compagnia è un negozio Agile o un negozio Waterfall, ovviamente indurranno i loro nuovi sviluppatori in qualsiasi processo abbiano, quindi non spetta ai singoli sviluppatori scalare la barca (a meno che, naturalmente, la situazione di documentazione / processo è così lugubre che stai provando a introdurne uno in primo luogo!).

Se stai creando qualcosa come una piattaforma. quindi, sicuramente, è responsabilità di ogni programmatore documentare il suo codice. dal momento che i programmatori lo creano, e il creatore del codice capisce meglio il codice.

Per qualcun altro sarà un disastro documentare il tuo codice.

E, anche il documento di scrittura del progrommer dovrebbe essere un criterio aziendale.

Se comprendo correttamente la tua domanda, la documentazione a cui ti riferisci sarebbe simile a fornire ai tuoi clienti manuali su come utilizzare il tuo prodotto o altri dati di natura simile? Se si tratta di quel tipo di documentazione, ho scoperto che è più la responsabilità dello scrittore tecnico, o, in mancanza, lo sviluppatore principale / project manager.

Come per la documentazione del codice, sì, questa è la responsabilità degli sviluppatori. Per lo meno ti risparmierà chiedendoti cosa ha fatto il tuo codice se il codice non viene toccato per un po '.