Come convincere / dimostrare al mio manager che è necessaria una riscrittura piuttosto che un refactoring [duplicato]

Probabilmente ha ragione.

Se il codebase è così mostruoso, così giganticamente complicato, così difficile da capire ... cosa ti fa pensare di poter scrivere qualcosa che faccia la stessa cosa correttamente?

Generalmente un grande refactoring è il miglior punto di partenza: inizia a estrarre i bit e combinarli in blocchi riutilizzabili; riordinare il codice in modo che sia più semplice da visualizzare; appiattisci la gerarchia dell'ereditarietà e rimuovi i casi limite che pendono; combinare gli spazi dei nomi; srotolare i macro; tutto ciò che serve per trasformare il grande casino in un sistema ragionevolmente comprensibile.

Devi capirlo prima di poterlo riscrivere, altrimenti finirai con un altro pasticcio.

Prima di attaccare il codice, suggerirei di iniziare a definire i casi di test e scrivere i test delle unità per loro.

I test unitari sono utili in una situazione di refactoring, così come per una riscrittura. Aiutano ad assicurarsi che la funzionalità richiesta rimanga corretta, anche quando si cambia il codice.

Quando decidi di riscrivere, puoi eseguire i test di unità rispetto all'originale e al nuovo codice, assicurandoti che la funzionalità non venga modificata.

I test unitari ti salveranno il culo dopo diversi cicli di refactoring!

La riscrittura di un grande progetto da zero è spesso molto più difficile di quanto non sembri all'inizio. Le probabilità sono se il codice è un casino, quindi i requisiti e la documentazione sono in forma ancora peggiore. Trascorrerai molto tempo a trovare i requisiti e a capire come e perché ogni parte del codice degli spaghetti funziona. Stai chiedendo costantemente che questo particolare comportamento sia un bug, una funzionalità o semplicemente una comodità per il tizio che l'ha scritto.

Dal punto di vista del tuo manager e, spero, anche dal tuo, l'obiettivo finale è creare valore per l'azienda. Dopotutto come professionista non scriviamo codice solo per scrivere codice che scriviamo codice per fare soldi.

Qualcosa che potresti non guardare è il livello di rischio per l'azienda e per il tuo manager. Se si inizia a lavorare da zero e non si è in grado di completarlo per qualsiasi motivo, la nuova metà completata di riscrittura potrebbe finire abbandonata. Pensa a dove questa riscrittura sarebbe in termini di priorità se esiste già una versione funzionante e l'architetto principale parte nel bel mezzo del progetto. Ci sarebbe una ragione abbastanza strong per l'azienda con questo aggiornamento?

Confrontalo per rifattorizzare il codice esistente in cui esiste ancora una versione attivamente sviluppata del progetto. Se non sei più disponibile per lavorare al progetto non sarà l'ideale ma il rischio è molto più basso.

Affinché un manager ti lasci fare una riscrittura completa tieni molta fiducia e ogni tanto vale la pena farlo, anche se riscrivere è molto più divertente che ripulire il casino di qualcun altro.

Sono stato nella situazione in cui una riscrittura totale è la soluzione migliore. Dove il codice originale è un mucchio di mal progettato, poco compreso, hackerato da programmatori pigri spazzatura.

È quasi sempre possibile refactoring tale codice da posta indesiderata a codice utilizzabile. Ma il problema è la quantità di tempo che ci vorrà. Qualsiasi serie di refactoring avrà costi aggiuntivi. Questo è il tempo e il codice necessari per far funzionare ogni blocco di modifiche con il codice legacy che non è stato ancora modificato. Un altro kicker è che non è insolito che il codice originale sia originato dalla stessa identica cosa che stai guardando perché qualcuno ha iniziato a "refactoring" e ha fatto il minimo (leggi la metà arsed) o sinistra prima che fosse completato.

La maggior parte delle persone supporta il refactoring perché la sua comprensione di ciò è che mantiene le cose funzionanti e può essere fatto pezzo di pasto. Pertanto la percepiscono come l'opzione "Sicuro". Per lo più corretto, ma non sempre. Lo scelgono spesso perché sono troppo spaventati per accettare una riscrittura.

Detto questo, è necessario comprendere appieno cosa deve fare l'applicazione. Se non hai una visione chiara di questo. Quindi è improbabile che la tua riscrittura sia molto migliore dell'originale.