Come vengono tracciati i requisiti esistenti nel tempo?

6

Sono un ingegnere informatico che lavora su un sito Web complesso e in corso. Ha un sacco di parti in movimento e un piccolo team di progettisti dell'interfaccia utente e uomini d'affari che aggiungono nuove funzionalità e modificano quelle vecchie. Nell'ultimo anno circa abbiamo aggiunto centinaia di interessanti piccoli casi. Pianificare, implementare e testarli non è un problema.

Il problema viene dopo, quando vogliamo refactoring o aggiungere un'altra nuova funzionalità. Nessuno ricorda la metà delle vecchie funzionalità e dei casi limite di un anno fa. Quando vogliamo aggiungere una nuova modifica, notiamo che il codice fa ogni sorta di cose lì dentro, e non siamo del tutto sicuri di quali siano i requisiti intenzionali e quali siano gli effetti collaterali privi di significato. Qualcuno l'anno scorso ha chiesto che il token di accesso fosse valido solo per 30 minuti, o alcuni programmatori hanno semplicemente scelto un valore ragionevole? Possiamo cambiarlo?

All'inizio del progetto, abbiamo creato una documentazione che descrive come funzionava il sito. Da allora abbiamo creato alcuni documenti aggiuntivi che descrivono le nuove funzionalità, ma nessuno torna mai indietro e aggiorna quei documenti quando vengono richieste nuove funzionalità, quindi l'unica documentazione autorevole è il codice stesso. Ma il codice non fornisce alcuna giustificazione, nessuna ragione per le sue azioni: solo il come, mai il perché.

Che cosa fanno gli altri team di lunga data per tenere traccia di quali erano i requisiti e perché?

    
posta Brandon Yarbrough 20.03.2012 - 01:47
fonte

2 risposte

5

I test unitari sono tuoi amici.

Uno dei motivi principali per cui scrivere test di unità è proteggere il tuo codice da modifiche future. Se si dispone di un test unitario collegato a ciascun comportamento richiesto, non vi è alcuna possibilità che un miglioramento futuro causerà al codice "cose strane".

È interessante notare che i test unitari diventano anche la documentazione vivente che i programmatori altrimenti trovano così difficile da mantenere. Se hai un test unitario chiamato DisableAccountAfterThreeWrongPasswords , il requisito viene catturato proprio lì. Se lo cambi in futuro con quattro password errate (per esempio), il test fallirà e sarai costretto ad aggiornarlo - e presumibilmente anche il nome del test.

Ovviamente, aggiungere test unitari in un sistema legacy complesso non è facile, e il codice di solito deve essere architettato in un modo che lo renda possibile. Vorrei iniziare con il refactoring delle parti più "rigide" del codice e la creazione di test come refactoring, e quindi far crescere il set di test mentre continui a migliorare l'applicazione.

    
risposta data 20.03.2012 - 05:53
fonte
3

Spero che tu abbia qualche VCS (preferibilmente DVCS) - i messaggi di commit e i log delle modifiche sono un ottimo punto di partenza.

Crea un Wiki interno: i documenti sono troppo pesanti per essere modificati e mantenuti. (Sharepoint 2010 è un'eccezione, se usato correttamente). Sforzati di mantenerli aggiornati (non richiede molto sforzo) per decisioni di progettazione di alto livello.

Avere un buon database di bug / funzionalità come JIRA e mantenerlo aggiornato sul lavoro corrente. La parte migliore di questo è la storia che viene fornita. Crea attività / bug copiando le e-mail incollate / dalle note della riunione del team.

Aggiungi un sacco di commenti sul codice, con riferimenti al database dei bug sopra.

Rivedi il tuo codice usando uno strumento di revisione del codice, mantenendo i commenti cr lì. Collega l'attività JIRA a questo, assicurandoti così di ricordare le decisioni sul codice.

Backup di tutto! :)

    
risposta data 20.03.2012 - 02:08
fonte

Leggi altre domande sui tag