Come riutilizzare il codice spaghetti

-1

Stiamo lavorando su un nuovo firmware per il nostro nuovo dispositivo V2. La società ha un vecchio firmware V1 (e hardware). Gli hardware sono simili tra loro (ma ci sono alcune differenze) quindi in pratica potremmo usare il firmware V1 con "alcune" modifiche. Sfortunatamente il firmware V1 è un codice spaghetti. Dobbiamo supportare sia l'hardware che le nuove funzionalità, quindi il codice dovrebbe essere manutenibile.

Abbiamo cercato di creare un backlog con piccole storie. Ogni storia mostrerebbe una nuova funzione di lavoro all'utente mentre estrae una parte riutilizzabile del codice V1 in un progetto di libreria e la usa in V2. Sarebbe stato possibile mantenere entrambi i firmware V1 e V2 sempre rilasciabili e saremmo stati in grado di mostrare una demo funzionante in anticipo (con funzionalità limitate all'inizio).

Nel tempo si è scoperto che il management si aspetta che sia un progetto breve (dato che hws è simile) e suggerisce un altro approccio: spostare tutto nel progetto della libreria e modificare solo quelle parti che sono diverse. Questo approccio sembra più rischioso perché non saremo in grado di dimostrare alcun progresso (la prima demo sarà successiva, è piuttosto tutto o niente, ogni modulo deve lavorare più o meno per la prima demo) e immagino che potrebbe portare a imprevedibili correzione dei bug.

Che cosa dovrei prendere in considerazione prima di decidere tra i due approcci? C'è un terzo?

    
posta user124017 20.03.2014 - 08:46
fonte

1 risposta

6

Is there a third one?

Se l'hardware V2 è "compatibile verso il basso" in qualche misura con l'hardware V1, potrebbe esserci. C'è la possibilità di far funzionare il firmware V1 su un hardware V2 con minimo sforzo , non supportando nessuna delle nuove funzionalità V2? Forse aggiungendo un po 'di "livello di compatibilità" al codice V1 non modificato? Se è così, ti suggerisco di provare prima questo - con un periodo di tempo limitato. Se quell'approccio fallisce, avrai tutte le discussioni a portata di mano per dire alla tua direzione perché il tuo approccio di cherry-picking funzionerà meglio.

E se l'approccio "prendi il firmware V1 così com'è", la tua gestione probabilmente ha ragione. Le nuove funzionalità V2 devono essere aggiunte dopo la "porta", e potresti dover convivere con un codice spaghetti più lungo di quello che vuoi, ma invece di refactoring di tutto il codice (con la possibilità di introdurre nuovi bug), puoi refactoring pezzi che devi cambiare, ma non di più (che ha un prezzo molto migliore)

Un altro fattore è se provi a creare due codebase (per hardware V1 e V2), che devi mantenere entrambi in futuro, o se il tuo nuovo codice base per l'hardware V2 deve essere in grado di gestire il dispositivo V1 (e si desidera avere solo una base di codice da mantenere o entrambe le versioni del dispositivo). Se quest'ultimo è il caso, e provi l'approccio "riscrivi a piccoli passi", è probabile che il tuo nuovo codice introduca nuovi bug alla funzionalità V1 esistente. Quindi devi testare accuratamente su entrambi i tipi di dispositivi, e perdere la qualità esistente su V1 per le prime versioni. Il nuovo codice non sarà realmente rilasciabile all'inizio (non come un aggiornamento del firmware per l'hardware V1 esistente in produzione), poiché all'inizio mancherà parte delle funzionalità esistenti e funzionanti. D'altra parte, riutilizzando il codice V1 per lo più non modificato fornirai una versione pronta per la produzione per V1 dal primo giorno.

    
risposta data 20.03.2014 - 10:21
fonte

Leggi altre domande sui tag