Come convincere la compagnia a iniziare la documentazione per il software legacy [duplicato]

Sento il tuo dolore. Sono stato in questa esatta posizione prima.

Il mio suggerimento è di dare l'esempio. Avvia un wiki o un documento e inizia a prendere appunti. Fai ripetuti riferimenti a questo documento che stai mettendo insieme. Se qualcuno ti fa una domanda, fai una dimostrazione di guardare prima il documento per la risposta. Se la domanda non è presente, aggiungila alla sezione delle domande senza risposta. Man mano che cresce, condividerlo con tutti. Aggiungi tempo per documentare le tue attività di manutenzione.

Devi crescere organicamente. Ha bisogno di un campione. Non sono a conoscenza di alcun argomento guidato dallo sviluppatore che possa far improvvisamente capitare a una società che non si preoccupa della documentazione. Una volta che è sul posto, tutti si chiederanno come sono andati avanti senza di essa. Purtroppo, una volta che avanzi, probabilmente diventerà obsoleto e morirà.

Questo tipo di negozi sono orribili per cui lavorare. Li compiango come farei con un animale ferito che sta morendo.

Tecnologia obsoleta, traboccante di debito tecnico, che emette costantemente fuochi, una base di clienti sempre più insoddisfatta, arrabbiata ea volte bloccata dai venditori ... sembra familiare?

Hai presente quel leggero sorriso che hai ricevuto dal manager sovraccarico che probabilmente ha un'aspettativa di vita inferiore a causa del casino che deve affrontare ogni giorno? Questo è il sorriso di qualcuno che ha avuto quasi 10 anni di programmatori nuovi in compagnia dicendogli esattamente la stessa cosa. Non pensare per un secondo che con tutto il giro d'affari non ci sia stata almeno una manciata di altri sviluppatori che sono venuti alla stessa conclusione.

Non ci sono più perché non sono riusciti a cambiare le cose per il meglio e si sono frustrati e sono partiti come tutti gli altri. Ma in ogni caso cerca di farlo da solo, tendiamo a imparare di più dai nostri fallimenti, non dai nostri successi.

Stanno soffocando sotto il pantano delle loro ferite autoinflitte e alla fine quando i loro clienti trovano una via d'uscita o un concorrente migliore arriva, questo posto non ci sarà più.

Se fossi in te, inizierei a cercare. Non ho più pazienza per questo tipo di negozi di software.

Oltre a spingere per la documentazione (che è importante), suggerirei anche di spingere per i test da scrivere (se non sono già stati e sono pronto a scommettere che non lo sono stati). Come Michael C. Feathers parla nel suo libro Lavorare efficacemente con il codice legacy , i test sono un buon modo per gestire il codice ingombrante in un'applicazione legacy. Scrivi test che ti aiuteranno a capire come funzionano certe parti del codice. Questo a sua volta ti aiuterà a documentare l'architettura dell'applicazione in quanto dovresti acquisire una migliore comprensione del codice, così come aiutare con qualsiasi refactoring che dovrai fare.

Buona fortuna! Sento anche il tuo dolore.

Probabilmente hai il nocciolo del perché hanno un alto turnover nel tuo post. Hai già sollevato le tue preoccupazioni con il management, assicurati di averlo fatto in modo formale indicando i motivi di business della documentazione (costi di supporto ridotti e risorse sprecate nel tentativo di capire il codice).

Se hai sollevato le tue preoccupazioni nel modo corretto e il management ti ignora ancora, allora le tue scelte sono a) succhialo b) Cerca un nuovo lavoro (vorrei raccomandare b)

Non penso che tu abbia davvero bisogno del permesso del tuo capo per fare la qualche documentazione. Il posto più ovvio per iniziare la documentazione è il codice.

Non è necessario lanciare un attacco di sola documentazione. Concentrati solo sull'integrazione della documentazione come parte del tuo lavoro quotidiano. Quando lavori su un metodo senza commenti JavaDoc, aggiungili. Quando aggiungi qualcosa di complicato ma necessario, aggiungi alcuni commenti da spiegare. E, naturalmente, assicurati che qualsiasi nuovo codice o funzionalità che aggiungi siano completamente documentati.

Farlo al codice su cui stai già lavorando non aggiungerà più di un paio di minuti a una determinata attività e migliorerà gradualmente la qualità complessiva del codice.