Le migliori pratiche per mantenere ben documentate le modifiche nel progetto

Gestire il cambiamento è molto più che usare il controllo del codice sorgente. Il controllo del codice sorgente è una necessità assoluta anche se non vi è alcun cambiamento nei requisiti. Ogni volta che è necessario "cambiare" qualcosa nel progetto, è necessario considerare molte cose.

• Devi analizzare l' impatto del Cambiamento suggerito [come quello che tutti i moduli sono interessati a causa di questo]
• Se il progetto sta andando sotto una struttura temporale fissa, allora devi analizzare gli ulteriori sforzi richiesti per implementare questa modifica e ottenere poi lo stesso approvato dal cliente.
• Branching deve essere eseguito nel controllo del codice sorgente se necessario, oppure puoi taggare i file utilizzando alcune convenzioni di denominazione. Qui puoi evitare un semplice backup che in seguito sarà difficile da gestire.
• Il documento del requisito dovrebbe tracciare tutte le modifiche in ordine cronologico. Le modifiche al documento di requisito possono anche essere tracciate sotto il controllo di versione o qualsiasi sistema di gestione dei documenti applicabile all'ambiente di lavoro.

Per riepilogare in base alle tue sottoregioni.

• Esegui il backup completo prima dell'elaborazione. Questo backup sarà documentato. Se sì, allora come?
  • Puoi usare tag / rami se usi SVN, i backup manuali saranno difficili da gestire
• Come verrà documentata la modifica? Qualsiasi modello? Come sarà condiviso tra i pari?
  • Il cambiamento dovrebbe essere sicuramente documentato. Se non si prevede di disporre di un documento di gestione del controllo delle modifiche, il documento dei requisiti deve contenere la cronologia delle versioni e tutte le revisioni dei documenti devono essere sotto controllo di versione / sistema di gestione dei documenti.

• Quale sarà il contenuto della procedura di richiesta di modifica?

  • La procedura di richiesta di modifica sarà simile a questa
    • Il cliente avvia la richiesta di modifica.
    • Il documento obbligatorio è aggiornato.
    • L'analisi dell'impatto è stata eseguita.
    • Ulteriori sforzi / ambito / costo sono discussi e finalizzati.
    • Il codice è taggato / ramificato
    • Gli sviluppatori possono citare l'id del controllo delle modifiche come commenti nel codice, se necessario.
    • Tutto quanto sopra dovrebbe essere documentato.

• Mantieni il codice, le query, ecc. in qualche cartella / documento?

  • Tutto il codice sarà disponibile nel controllo Sorgente, Dovrebbero essere opportunamente taggati.

Molto semplicemente, usa controllo del codice sorgente . Per rispondere in modo specifico alle tue domande:

1. Se i progetti non sono attualmente nel controllo del codice sorgente, inizia a utilizzare Subversion (modello classico) o Mercurial (modello distribuito) e metti i tuoi progetti nel controllo del codice sorgente. Documenta inviando un'email alla direzione, modificando un wiki o scrivendo un documento semplice che spiega come accedere ai file nei repository di controllo dei sorgenti.
2. Le modifiche sono documentate automaticamente dal controllo del codice sorgente. Ogni volta che apporti una modifica, fornisci un buon commento che spiega le modifiche apportate e perché.
3. Se qualcuno richiede modifiche, esporta la cronologia dal repository con svn log (Subversion) o hg log (Mercurial). È possibile scrivere uno script per analizzare l'output del registro e stampare piuttosto nel formato desiderato.
4. Il controllo del codice sorgente tiene traccia del codice interessato. Le query del database, se non sono direttamente nel codice, devono essere inserite in file che sono anche archiviati nel controllo del codice sorgente.

Oltre al controllo del codice sorgente, è assolutamente essenziale disporre di un bug e di uno strumento di rilevamento delle caratteristiche. Se riesci a legare lo strumento di tracciamento dei bug allo strumento di controllo del codice sorgente, ancora meglio.

Tra i due strumenti, avrai tutta la documentazione di cui avrai bisogno. Finché li usi, naturalmente. Usarli può essere un po 'difficile perché alcuni lo vedranno come "lavoro extra".

www.fogcreek.com crea un bug tracker e il controllo del codice sorgente (FogBugz e Kiln) che sono ben legati con poco sforzo. Sono entrambi super facili da usare.

Joel Spolsky ha fatto un bel tutorial sull'uso del controllo del codice sorgente basato su Mercurial. È una serie fantastica, specialmente se sei nuovo nel controllo del codice sorgente. www.hginit.com

Primo passo: assicurati di avere una Change Control Board che rappresenta tutti gli stakeholder del progetto .

Ciò garantisce la visibilità del cambiamento proposto e la decisione sul cambiamento.

Nel progetto WikiEngine , ho creato una piccola "applicazione wiki" che utilizza una cartella con file per dati e collegamenti / link a ritroso, che in realtà sono abbastanza adatti per l'inserimento in sistemi di controllo di versione basati su testo come SVN o Git.

Quando apporto le modifiche, aggiorno qualsiasi pagina dal wiki e le inserisco / le spingo insieme con le modifiche nel codice.