Va bene scrivere un programma software rapido e poi refactarlo? [duplicare]

Qualcuno, credo che sia stato Steve McConnell, probabilmente nella prima edizione di Code Complete, a fare una distinzione molto importante. Esistono due tipi di prototipi, usa e getta ed evolutivi, ed entrambi sono preziosi. E facciamo un grave errore quando confondiamo i due.

Un prototipo usa e getta dovrebbe essere molto veloce da scrivere; è quello che penso quando sento "proof of concept" (preferisco la frase "test of concept" perché la dimostrazione sembra implicare un risultato atteso, e se conosci il risultato, perché preoccuparti?) Perché è veloce da scrivere, tu può buttarlo via senza dubbi. E dovresti, perché la sua qualità del codice non sarà all'altezza dei tuoi standard abituali. Imparerai ciò che ti serve dal prototipo "usa e getta" e poi lo butti via e applichi ciò che hai imparato al tuo codice di produzione (ricorda, quello che potresti aver appreso è "questo non funziona", questa è una lezione molto buona ).

Un prototipo evolutivo, al contrario, è progettato per evolversi nel tuo codice di produzione. Questo è più lento, perché deve essere scritto per soddisfare gli standard di codifica: devono essere gestiti casi eccezionali, devono essere effettuati test, commenti e nomi appropriati, ecc. Questo può essere un buon modo per andare, ma è ovviamente un investimento più grande di il prototipo usa e getta.

L'errore critico che molte organizzazioni e sviluppatori fanno - un errore suona come la tua organizzazione sta facendo - è di iniziare con un prototipo usa e getta, e non riescono a buttarlo via. Perché ora hai codice criptato (apposta) e stai provando a metterlo in produzione. Non farlo. Buttare via il throwaway; questo è quello che era per.

Se trascorri così tanto tempo a rielaborare il tuo POC (quasi completo di funzionalità) per soddisfare gli standard di codifica, è giunto il momento di valutare se quegli standard di codifica siano effettivamente di aiuto. Gli standard di denominazione ti aiutano effettivamente a scrivere codice di qualità migliore più rapidamente o aggiungono inutilmente un lavoro intenso?

Ovviamente, si dice "molto vicino al vero risultato finale in termini di funzionalità" - la prossima domanda è, ovviamente, quanto tempo impieghi a schiacciare i bug. Se il POC è in realtà quasi privo di bug e quasi completo di funzionalità, e con un po 'di lavoro in più (se salta tutte le cazzate degli standard di codifica) soddisferà tutte le esigenze del cliente, quindi non è un POC tanto quanto un alfa o versione beta.

In ogni caso, se questo approccio avrà successo può dipendere dalla tua squadra. Se funziona per te - fantastico! Ma se passi molto tempo a "refactoring" che in realtà non aiuta , potrebbe valere la pena di riconsiderare se tale refactoring sia effettivamente utile.

Questo non vuol dire che il refactoring sia necessariamente negativo. Potrebbe essere che il tuo codice "quick mode" sia un disordine irraggiungibile e che sia necessario il refactoring, nel qual caso forse questa "modalità rapida" non è una buona idea. Questo, di nuovo, dipende dal fatto che la tua squadra sia in grado di realizzare codice più o meno gestibile la prima volta. Ma, dalla tua descrizione, potrebbe altrettanto facilmente essere una grande perdita di tempo.

È bello avere il tempo di ridefinire il POC.

In molti ambienti, se il POC è abbastanza buono, viene comunque distribuito, non si ha il tempo di ripulirlo, e i problemi non emergono finché non si finisce per fare manutenzione o aggiungere un alcune funzionalità, tra un anno o due.

Se questo approccio funziona nel tuo ambiente, allora non ti suggerirei di smettere di usarlo. Ma se provi a portarlo in un altro ambiente, fai attenzione.

Per me, una "prova del concetto" sarebbe un codice sufficiente per dimostrare a me stesso che potrei far funzionare qualcosa. Niente campane, niente fischi, nessuna gestione degli errori, nessuna caratteristica con cui mi sentissi a mio agio a meno che non fossero assolutamente critici per provare qualunque cosa fosse la cosa principale. Peggio era, meglio era, con la motivazione che sarebbe stato meno probabile essere spinto verso la produzione.

Quindi ricominciavo da capo con la mia normale metodologia di sviluppo, usando il POC (o spike) come modello al momento opportuno. Forse qualunque idea avessi appena dimostrato sarebbe stata la prima caratteristica che ho creato in questa seconda versione, ma più probabilmente avrei dovuto fare altre cose prima di preparare il terreno.

Se avessi il permesso, preferirei personalmente lavorare secondo la moda che hai descritto: prendi prima qualcosa che funzioni e poi progetta una bella lezione o qualsiasi cosa secondo i principi del design. Dopotutto, a cosa serve un bel design se non riesci a farlo funzionare.

In effetti Bruce Eckel raccomanda anche "buid one to throw" come tecnica di programmazione efficace. Questo è molto utile quando stai facendo qualcosa che è tecnicamente complicato o molto poco familiare (forse una nuova libreria). Doing a POc ti dà un'ottima idea su come dovrebbe essere il tuo design.

Se hai già una buona conoscenza dei requisiti del tuo progetto e il tuo design funziona bene, rispondi al 70-80% delle volte senza refactoring, quindi penso che tu stia meglio senza un PoC. Ma se passi più del 40% del tuo tempo a refactoring del tuo progetto per farlo funzionare, è meglio fare prima un PoC.

Come hai menzionato i test unitari, aggiungimi: se ti viene richiesto di fare TDD devi prima ottenere una "giusta progettazione" prima di iniziare la codifica. Se fai prima un POC, puoi risparmiarti il problema non facendo TDD insieme al POC. Prima fai un POC, quindi progetta le tue classi, poi scrivi i casi di test. In questo modo non devi scrivere due serie di casi di test.

Il mio approccio - o scriverlo "quasi bene" la prima volta o riscriverlo da zero usando POC come progetto / bozza, non il pezzo finale. A volte estraggo grandi pezzi di codice dal POC portandoli nel prodotto finale - quelli che li ritengo particolarmente riusciti e ben scritti. Ma la maggior parte del codice viene riscritta da zero.

Ovviamente il POC a volte funzionerà come una stub per l'ultima cosa per alcuni giorni (o mesi ... a seconda di quanto sia critico il pezzo mentre la scadenza su cose più importanti è incombente), prima che venga sostituita dal cosa vera. Ma non è una buona pratica.

you have the confidence to meet deadlines one so called POC is ready, then you can spend time on design.

La domanda corretta da porsi come azienda non è se si ha la certezza di rispettare le scadenze quando il POC è pronto, ma se si ha la disciplina per refactoring e scrivere test unitari prima di andare a produzione.

Soprattutto in un ambiente strongmente orientato alle preoccupazioni di vendita, la tentazione è troppo grande per consentire all'azienda di consegnare il prototipo come prodotto con piccole modifiche, in genere senza riguardo alla manutenibilità e al debito tecnico che maturerà in seguito . Quattro mesi dopo, quando il cliente torna e dice: "È necessario che il programma tenga traccia delle visite ad hoc alle strutture. allora quella situazione potrebbe forzare comunque la necessità di una riscrittura del prototipo. Un progetto che avrebbe dovuto richiedere alcuni mesi è ora quasi un progetto di 8 mesi e il cliente è arrabbiato per il tempo e il costo rispetto a ciò che a loro sembra una caratteristica abbastanza semplice.

Sembra che tu lavori per una buona compagnia che capisca i pericoli del NON refactoring del tuo POC prima di usarlo come prodotto.

Dirò di no. Parlando dall'esperienza, 9/10 volte se si scrive un programma in modo rapido e lo si distribuisce, non si sarà in grado di dedicare il tempo a un refactoring in quanto il management / cliente vede risultati rapidi in modo da essere sommerso da altro lavoro che è dovrebbe essere fatto altrettanto veloce. Finirai con un programma terribile che continua a diventare sempre più grande.

Meglio prendere il tempo extra e fare le cose per bene. È più lento all'inizio ma più veloce lungo la strada. Pensiero a breve termine e a lungo termine: il lungo termine dovrebbe sempre vincere, a meno che tu non sia serio riguardo a ciò che stai facendo.

I programmatori sono autori, e anche i migliori autori non riescono a capire bene la prima bozza. C'è una ragione molto semplice per questo: i programmatori che hanno lavorato a un progetto per un mese sono molto più informati sull'argomento rispetto ai programmatori che non ci hanno lavorato affatto.

Tuttavia, la pianificazione in una fase di refactoring non è la risposta. Devi fare un refactoring continuo mentre vai. Quando trovi un'alternativa più pulita a un'architettura che si è rivelata scomoda e soggetta a errori, rifatta proprio allora . Potresti pensare di risparmiare tempo rimandandolo, ma quello che stai facendo è condannare i programmatori a lavorare su un'architettura scomoda e soggetta a bug fino al completamento del POC. Ciò aumenta notevolmente il rischio che non funzioni, rende il lavoro più difficile, e quindi richiede più tempo, anche in un periodo relativamente breve.

Personalmente preferisco ottenere il deliverable principale da zero. Ho sempre a disposizione uno o due progetti throwaway per testare rapidamente o distillare alcune idee, ma anche lavorando in questo modo, il refactoring è inevitabile.

Di solito aspetto di scrivere test di unità finché non sono perfettamente soddisfatto di una lezione. Ho provato a scrivere i test prima dell'implementazione, ma il mio tempo di sviluppo è quadruplicato mantenendo tutti i mockup aggiornati a causa del mio bisogno di avere tutto compilabile in ogni momento (forse dovrei imparare a rilassarmi, ma sono un po 'arrugginito modo).

D'altra parte, probabilmente sono troppo perfezionista. Commercialmente il POC rapido e la patch potrebbero essere una scelta più economica.

Penso che questo sia ok a seconda della situazione. Scrivere un POC per ottenere da A a B il più rapidamente possibile, e poi ridimensionarlo e stirare le pieghe è sicuramente una strategia che può funzionare e ha funzionato per me in passato. Tuttavia, il refactoring non è un ripensamento, ma è necessario refactoring in modo aggressivo, fare un sacco di esso e allocare tempo significativo di progetto ad esso.

Penso che la tua decisione dipenda dalla qualità del tuo POC. Se è di alta qualità (potrebbe essere 'rustico', ma ciò non impedisce che sia di alta qualità) non dovresti ricominciare da zero. Fa perdere tempo - l'ho visto - e se si sbaglia il nuovo design è frustrante e dirai "se solo fossimo rimasti con ..." allora la gente dovrà comunque lavorare sodo per refactoring. Se è di bassa qualità, allora è più probabile che tu abbia sbagliato l'approccio in qualche modo e in un certo momento in futuro dovrai colpire uno stop-stopper. Ho scoperto che l'opinione della qualità della base di codice potrebbe variare tra i membri del team. Devi capire chi ha ragione. Stai cercando un buon design di alto livello, che soddisfi le preoccupazioni future, e puoi ignorare la maggior parte delle cose scritte su piccola scala / non idiomatiche / incoerenti in una certa misura.

Qualunque sia il tuo design, prova a guardare avanti con esso, identifica le modifiche più importanti e rendile subito. Una volta che sei in fondo allo sviluppo, sarà più difficile cambiare la struttura generale.

Lo scenario che descrivi non ha l'anello della verità per me. La mia ipotesi sarebbe che il tuo proof-of-concept è veloce da fare perché non è robusto, ed è probabilmente bacato. Questo è quello che mi piace chiamare "fumo e specchi" perché il software incompiuto può facilmente apparire finito nei client fino a quando non devono usarlo per fare il loro lavoro.

Se ho ragione, la pulizia che viene dopo non può essere definita "refactoring" tanto quanto tenere conto di tutti i casi limite, eliminando bug e rispondendo al feedback (che inevitabilmente richiede comunque l'80% delle volte) . Suppongo che potresti mescolare questo con la pulizia e quindi concludere che sei "solo refactoring".

È possibile che mi sbaglio. Il tipo di cosa che stai descrivendo non corrisponde alla mia esperienza personale. Un proof-of-concept è generalmente più prezioso nel ridurre il rischio e dimostrerà la fattibilità di quelle parti di un progetto che sembrano avere più probabilità di fallire a meno che non siano ben pensate in anticipo.

È incredibile quanti prototipi finiscono per essere il prodotto finale. Direi che segui le tue linee guida sulla codifica per creare il prototipo e una volta terminato non dovrebbe richiedere una grande quantità di refactoring, altrimenti le tue linee guida devono essere aggiornate. Fallo il più vicino possibile alla prima volta.