Attualmente troviamo che abbiamo un sacco di codice che a volte si sovrappone a una funzione dell'utente finale, in alcuni casi contribuisce solo a un decimo di una funzione, o sembra addirittura che non dovrebbe esserci più
Il codebase è abbastanza grande, quindi non ci sentiamo abbastanza sicuri da strappare le cose senza una solida ragione.
Esiste un approccio consigliato che aiuta a identificare gli obiettivi aziendali e quanto contribuisce a tale obiettivo?
Generalmente non è possibile decodificare i requisiti originali dal codice. Spesso, questo codice è "cresciuto organicamente" in un pasticcio incomprensibile, o è stato copiato da altri componenti, senza eliminare parti non necessarie.
Esistono tuttavia diverse tecniche che possono essere utili per comprendere lo scopo di questo codice e decidere se rimuoverlo.
Esamina la cronologia del controllo della versione e confrontala con i record storici nel database dei bug. Quando è stata scritta questa riga di codice? Su quali bug venivano lavorati in quel momento?
Scrivi casi di test per questo codice. In quali circostanze verrà esercitato questo codice? I test end-to-end oi test di integrazione sono più utili qui, poiché i test unitari potrebbero essere in grado di esercitare un codice irraggiungibile durante il normale funzionamento.
Aggiungi la registrazione a queste parti e osserva se vengono mai utilizzate durante l'utilizzo del mondo reale. Il pericolo è che alcuni casi d'uso potrebbero essere stagionali, quindi potresti non osservare il loro utilizzo nella finestra di osservazione scelta. Questo dipende molto dalla natura del tuo prodotto.
Eseguire un refactoring sicuro per rimuovere la duplicazione. Con un po 'di esperienza, è possibile estrapolare in sicurezza il codice comune da più componenti, anche quando la copertura del test è parziale. Quindi, considera quali differenze rimangono. Perché queste differenze potrebbero essere importanti? Forse non c'è una buona ragione, e le differenze dovrebbero essere corrette.
Senza copertura del test questa è ancora una manovra ad alto rischio, quindi assicurati di procedere in piccoli passaggi, rivedere il tuo lavoro e preferibilmente aggiungere dei test mentre stai prendendo il codice.
Alla fine, un bel po 'di codice sarà di solito lì solo per vari casi limite: le funzionalità sono anche una responsabilità. Questo non significa che questi casi limite non siano importanti. Se ogni utente ha solo il 60% delle sue funzionalità ma tutti usano un diverso 60%, quindi limitare il prodotto al sottoinsieme comune di funzionalità significa creare un prodotto per nessuno. Quindi i casi limite hanno valore, ma a volte non valgono l'onere aggiuntivo di manutenzione.
Leggi altre domande sui tag requirements agile