Quando dovresti riscrivere? [duplicare]

Come per qualsiasi affermazione dura e veloce che Joel Spolsky sputa fuori ...

Non dovresti prenderlo alla lettera!

Gli piace dipingere un argomento drammatico per un problema comune e una situazione comune, ma come qualsiasi cosa nel mondo reale c'è sempre quell'area grigia, non importa quanto piccola.

Intende convincere la gente a pensare e a creare un'avversione per essere "riscritta felice" che sono completamente d'accordo. Il 95% delle situazioni di riscrittura non lo giustifica, ma ovviamente avrai questo caso eccezionale in cui "il nostro cliente si sta spostando su server Linux e non installerà Mono. Dovremmo riscrivere questa app .NET in qualche altra tecnologia. "

Il fatto che ciò che ha detto ti abbia preoccupato abbastanza da pubblicare una domanda significa che fa bene il suo lavoro. Ti ha fatto pensare e questo è il suo obiettivo finale, credo.

La mia vista è questa: dovresti riscrivere quando sarebbe più facile iniziare da zero che a refactoring. Ad esempio, se lo sforzo di refactoring implicherebbe mesi di retrofitting del codice OOP proceduralmente scritto all'OPO corretto prima ancora di poter iniziare a rifattorizzare il codice, allora una riscrittura è l'opzione migliore perché devi cambiare < em> tutto . Un altro esempio potrebbe essere se non ci sono test unitari e l'infrastruttura non supporta il test delle unità (cioè codice strettamente accoppiato, nessuna separazione dei problemi), non è possibile iniziare a rifattorizzare il codice senza una suite di test, ma la creazione della suite di test richiede prendendo il coraggio dell'applicazione e apportando alcune modifiche piuttosto serie per consentire la creazione di tali test in primo luogo. È un ciclo infinito, di tipo: non puoi refactoring senza i test, ma i test non possono esistere senza refactoring.

Non sono d'accordo con veemenza sull'articolo di Joel sulla riscrittura, perché sono stato in molte situazioni in cui un serio refactoring non può accadere perché letteralmente NOTHING è fatto correttamente per supportare il refactoring a tutti. In una situazione come questa, le scelte sono spesso: 1) Riscrivi l'applicazione, oppure 2) Non toccare nulla e continua a far scorrere il codice.

Dovresti anche prendere in considerazione una riscrittura quando devi introdurre alcune modifiche architettoniche del codice che non possono essere adattate, di nuovo l'esempio per eccellenza potrebbe funzionare su un'app che è stata lanciata insieme senza virgola o motivo, nessun test unitario , nessuna separazione, SQL codificato, numeri magici ovunque ... hai un'idea. Cercare di cambiare una bestia del genere è come Sisyphus che cerca di spingere il masso, soprattutto se vuoi introdurre concetti di progettazione appropriati come SOLID, o introdurre un ORM appropriato, o dire di passare a ASP.NET MVC quando tutto è WebForm con tutta la logica in code-code ad esso.

Per rimanere con l'intero tema del "debito tecnico", ho esposto questo:

Refactoring sta attraversando un consolidamento (tecnico) del debito e lentamente restituendo il debito per un periodo di tempo (solitamente lungo).

Riscrivere è una bancarotta (tecnica).

Proprio come nelle finanze reali, a volte il tuo debito è così grande che la bancarotta è la migliore (se non la sola) opzione per cancellare tutto pulito e ricominciare da capo, a patto di non ripetere gli stessi errori.

Probabilmente ... ma

Ci sono probabilmente ulteriori eccezioni - ad un certo punto "refactoring su larga scala" e "riscrittura" sono indistinguibili - quando cambia ogni riga di codice!

Ma quello che mi chiedo è: qual è lo scopo di creare regole rigide per situazioni che devi ancora incontrare? L'esempio di Joel era un caso estremo (NetScape) non comune Astuccio. Se hai una progettazione sbagliata o hai superato l'architettura o cambiato piattaforme e altri, riscrivere potrebbe essere un'opzione valida. Se la tua squadra non arriva mai a quel punto, allora il dibattito sulle regole è uno spreco di respiro. Quando arrivi a quel punto, la situazione potrebbe essere così diversa che le regole combattute con cui ti trovi oggi non si applicano più.

Ho letto il suo articolo, e 1,2 e 4 sono buoni punti, ma 3 è un argomento circolare. Inoltre, i suoi esempi di codice non sono nemmeno close per il codice peggiore che ho visto. Sicuramente, a un certo punto, ci deve essere un codice che riscrive da zero? Una cosa è dire che non farlo mai, ma sarebbe più utile cercare di trovare un modo per decidere in modo ragionevole dove tracciare la linea.

Che cosa succede se qualcuno vuole aggiornare uno stack software obsoleto che utilizza file invece di un database, è scritto in una lingua privata con un compilatore buggy personalizzato in COBOL, non ha commenti, non ha test di alcun tipo e non usa nient'altro che GOTO per flusso di controllo e variabili globali per lo stato, ed è un'intera applicazione aziendale in un livello con tutto dipende da tutto il resto (ma gli utenti lo adorano)? Ci sto riuscendo, ma in quella situazione, sarebbe davvero più economico sistemare che riscrivere?

Penso che il punto numero 3, sia più economico ricominciare da capo a riparare (compreso qualsiasi porting), è il punto chiave. Nel tuo caso, se una porta linea per riga non funzionasse, forse potresti ammettere la tua riscrittura e pianificare di conseguenza.

Se il tuo progetto si trasforma in spaghetti non mantenibili (problema comune con un programmatore singolo / piccoli progetti di code-base) e sei ancora all'inizio del progetto (o la parte interessata è abbastanza piccola) è meglio eliminare la spazzatura e riavviare

ma è praticamente l'unica ragione per cui dovresti riscrivere

e quando inizi a riscrivere fai un piano chiaro su quale sarà il nuovo design e STICK TO IT, dovresti già avere un'idea di cosa è necessario e dove è andato male la prima volta e creare un disegno da quello senno di poi (mantieni vecchie segnalazioni di bug e ricrea le circostanze con il nuovo progetto coughunittestscough per correggere i bug di respawning

se vuoi ricreare un progetto precedente esistente come la prossima versione principale mantienilo come un progetto collaterale e mantenere attivo e supportato il progetto principale per un backup quando la riscrittura fallisce e spedisci solo la riscrittura quando soddisfa i requisiti che il vecchio ha raggiunto o lo getta quando fallisce; L'articolo di Joel menzionava che M $ provava a riscrivere la parola, ma non funzionava, ma mantenevano attivo il vecchio codice base, quindi andava bene oltre al tempo di sviluppo perduto.