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

In genere non mi piace visualizzare le attività di "miglioramento del codice" come un'attività assegnabile separatamente, poiché il miglioramento del codice in sé non ti avvicina mai 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 da non essere mai assegnate.

Vedo il miglioramento del codice come una costante, qualcosa che ogni sviluppatore dovrebbe fare come naturalmente digitando su una tastiera. Lo considero nelle mie stime per qualsiasi compito. Se il mio compito mi coinvolge toccando una classe o qualche codice sorgente che non è stato visto da molto tempo, allora supporrò che un lavoro di pulizia sia probabilmente in ordine e aumenti di conseguenza la mia stima.

Scenario migliore Finisco il compito in anticipo e posso usare il tempo rimanente per migliorare il codice o anche il design. Nel peggiore dei casi, l'attività richiede molto più tempo del previsto, ma ho il tempo extra come buffer.

Se si desidera ridefinire il codice, impostare la priorità dell'attività in base alla propria definizione (ad es. "come influisce sul prodotto"). Alcuni refactoring non influiranno molto sul prodotto e alcuni lo faranno, a seconda dello scopo del lavoro richiesto. L'impostazione di una priorità più alta indica che sarà necessario eseguire più test dopo che il refactoring è stato completato per garantire che non si sia verificato nulla di imprevisto.

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 è verificare le ipotesi sul codice esistente: meno tempo e notevoli risparmi possono essere raggiunti se miglioriamo il codice. È questo cosmetico o ci sono problemi seri?

Verifica le stime di debug e di miglioramento. Se impiegano più tempo e ci sono continue osservazioni su come dover prima rifattorizzare il codice o ripulirlo, questa potrebbe essere la tua misura migliore. Quindi puoi identificare il tuo codice come: Buono, necessita di una piccola rilavorazione o di un serio refactoring richiesto.

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

Domanda interessante.

Penso che dovresti stimare quante linee di codice e quanti moduli potrebbe influire su una modifica.

Forse potresti vedere quanti test unitari, se li hai, si romperanno apportando la modifica. Questo probabilmente significherebbe 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 sui tester. Se la modifica tocca una vasta area della app, potrebbe essere necessario rivedere molti test di sistema.

Iniziamo con due presupposti qui.

1. Per ogni nuova storia, scrivi il tuo codice al meglio delle tue capacità, possibilmente puntato sulla conoscenza dell'ambiente del tuo team.
2. Ogni volta che hai una storia che cambia la funzionalità del codice esistente, usi la tua nuova conoscenza del sistema e le migliori competenze per migliorare il codice nel processo di implementazione della nuova storia.

Dati questi due presupposti, non è mai necessario un esplicito sforzo di "miglioramento del codice". Il tuo codice migliora man mano che scrivi il sistema. Ciò significa che non tutto il codice è conforme ai tuoi ultimi e più grandi standard di manutenzione, ma "Se non è rotto non aggiustarlo". Considero il codice di refactoring che non ha bisogno di essere modificato per essere "placcatura in oro" tanto quanto aggiungere funzionalità visibili non necessarie. Se il codice è rotto in qualche modo, scrivi un test valido che fallisce; registra un bug; e poi refactoring per risolvere quel bug.

Vorrei rubare il voto al movimento Agile:

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

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