Come determinare la priorità e la gravità di un "miglioramento del codice"?

Abbiamo campi "prioritari" e "severi" nel nostro sistema di tracciamento dei bug. Definiamo la gravità come "come influenza l'utente" e la priorità come "come influenza il prodotto".

La mia domanda è su come classificare un'attività di "miglioramento del codice" in ordine di gravità e priorità. Supponiamo che il miglioramento non cambi alcun comportamento ma lo renda un "codice migliore". Prevediamo un miglioramento della manutenzione a lungo termine, ma è difficile da quantificare.

Quando utilizziamo le nostre definizioni per priorità e severità, un miglioramento del codice ottiene i valori più bassi per entrambi, a meno che non introduciate nell'immagine alcuni vantaggi a lungo termine difficili da prevedere. Pertanto implica che il miglioramento del codice è un compito delicato e non dovrebbe mai essere tentato.

Tuttavia, credo che sia cruciale migliorare e riformattare costantemente il codice, perché:

• Lo sviluppo del software è di per sé un processo di apprendimento continuo e senza migliorare il codice non è possibile migliorarlo.
• Una squadra dovrebbe essere orgogliosa del proprio codice.
• La manutenzione futura richiederà meno tempo e nel lungo periodo i risparmi saranno significativi.

O pensi che tali attività non dovrebbero mai essere create e tali miglioramenti eseguiti solo "su richiesta", "se associati a un bug"? Anche se è associato a un bug, non sarebbe un punto di discussione su una revisione del codice, ad esempio "perché hai fatto questo drastico cambiamento nella struttura?".

In genere non mi piace vedere le attività di "miglioramento del codice" come un'attività assegnabile separata perché il miglioramento del codice stesso non ti avvicina direttamente al completamento delle storie o dei requisiti degli utenti. Questo è il motivo per cui le attività di miglioramento del codice avranno sempre una priorità così bassa che non verranno mai assegnate.

Vedo il miglioramento del codice come una costante, qualcosa che ogni sviluppatore dovrebbe fare in modo naturale come scrivere su una tastiera. Lo inserisco nelle mie stime per qualsiasi compito. Se il mio compito prevede che tocchi una classe o un codice sorgente che non è stato esaminato da molto tempo, supporrò che un po 'di lavoro bidirezionale sia probabilmente in ordine e aumenterò la mia stima di conseguenza.

Nel migliore dei casi, finisco presto l'attività e posso usare il tempo rimanente per migliorare il codice o persino la progettazione. Nel peggiore dei casi, l'attività richiede molto più tempo del previsto ma ho quel tempo extra come buffer.

Se si desidera riformattare il codice, impostare la priorità dell'attività in base alla propria definizione (ovvero "come influisce sul prodotto"). Alcuni refactoring non influiranno molto sul prodotto e altri lo faranno, a seconda della portata del lavoro richiesto. L'impostazione di una priorità più elevata indica che sarà necessario eseguire ulteriori test dopo il completamento del refactoring per garantire che non si sia verificato nulla di inaspettato.

Potresti anche voler introdurre una nuova categoria nel tuo sistema di tracciamento dei bug per classificare questi tipi di attività come attività di "refactoring". In questo modo saprai come interpretare il valore di priorità; vale a dire, una priorità più alta significa un impatto maggiore e quindi sono necessari più test.

Ciò che manca è la verifica delle ipotesi sul codice esistente: meno tempo e risparmi significativi possono essere raggiunti se miglioriamo il codice. Questo cosmetico o ci sono problemi seri?

Controlla le tue stime di debug e miglioramento. Se impiegano più tempo e ci sono commenti continui sulla necessità di refactoring prima del codice o di ripulirlo, questa potrebbe essere la misura migliore. Quindi puoi identificare la tua base di codice come: Buono, richiede una piccola modifica o un serio refactoring richiesto.

Tutto questo è relativo. È difficile dare la massima priorità quando ci sono clienti che desiderano più funzionalità e disposti a pagare immediatamente per le ore fatturabili.

Domanda interessante.

Penso che dovresti stimare quante righe di codice e quanti moduli potrebbero influire su una modifica.

Forse potresti vedere quanti test unitari, se li hai, verranno rotti apportando la modifica. Ciò significherebbe probabilmente provare prima il cambiamento in un ramo per avere un'idea.

Quindi avere soglie per questi livelli di corrispondenza priorità e gravità.

Dovresti anche prendere in considerazione la necessità di coinvolgere molti test dei tester. Se la modifica tocca un'ampia area dell'app, potrebbe essere necessario rivedere molti test di sistema.

Cominciamo con due ipotesi qui.

1. Per ogni nuova storia, scrivi il tuo codice al meglio delle tue capacità, possibilmente supportato dalla conoscenza ambientale della tua squadra.
2. Ogni volta che hai una storia che cambia la funzionalità del codice esistente, usi la tua nuova conoscenza del sistema e le migliori abilità per migliorare il codice nel processo di implementazione della nuova storia.

Alla luce di questi due presupposti, non è mai necessario un esplicito sforzo di "miglioramento del codice". Il tuo codice migliora mentre scrivi il sistema. Ciò significa che non tutto il codice è all'altezza dei più recenti e più elevati standard di manutenibilità, ma "Se non è rotto non risolverlo". Considero il codice di refactoring che non deve essere modificato come "placcatura in oro" tanto quanto l'aggiunta di funzionalità visibili non necessarie. Se il codice viene infranto in qualche modo, scrivi un test valido che fallisce; registra un bug; e quindi refactor per risolvere quel bug.

Vorrei rubare il voto dal movimento Agile:

Inserisci il bug, fai delle ipotesi approssimative per gravità e priorità,

Quindi, quotidianamente, settimanalmente o mensilmente rivedi tutti i nuovi bug e vota le loro valutazioni. Idealmente, lo fai durante una riunione di pianificazione dello sprint con gli utenti finali. Quindi puoi anche parlare delle prossime funzionalità in quel momento ed essere positivo,