C'è una terza opzione ... scrivere codice pulito attraverso lo sviluppo basato su test per implementare i requisiti che sono necessari oggi perché YAGNI.

La tentazione di scrivere codice che al momento non è necessario ma che potrebbe essere in futuro soffre di diversi svantaggi ... da Non ne avrai bisogno :

• Il tempo impiegato è preso dall'aggiunta, dal test o dal miglioramento delle funzionalità necessarie.
• Le nuove funzionalità devono essere debug, documentate e supportate.
• Ogni nuova funzione impone vincoli su ciò che può essere fatto in futuro, quindi una funzionalità non necessaria ora potrebbe impedire l'implementazione di una funzionalità necessaria in seguito.
• Finché la funzione non è effettivamente necessaria, è difficile definire completamente cosa dovrebbe fare e verificarla. Se la nuova funzione non è definita e testata correttamente, potrebbe non funzionare correttamente, anche se alla fine è necessario.
• Porta a gonfiare il codice; il software diventa più grande e più complicato. A meno che non ci siano specifiche e qualche tipo di controllo di revisione, la funzione potrebbe non essere nota ai programmatori che potrebbero farne uso.
• L'aggiunta della nuova funzione potrebbe suggerire altre nuove funzionalità. Se anche queste nuove funzionalità vengono implementate, ciò potrebbe provocare un effetto valanga verso il featurism strisciante.

Di conseguenza, non dovresti solo prototipare ... né scrivere un codice pulito, ottimizzato e documentato fin dall'inizio, avendo in mente che se in futuro non sarà economicamente conveniente, verrà eliminato .

Scrivi il codice di cui hai bisogno ora sapendo di essere in grado di soddisfare al meglio le esigenze di oggi e di domani.

come al solito ...

Dipende

Se stai prototipando per mitigare un rischio o esporre uno sconosciuto, codificalo e aspettati di buttarlo via quando hai finito

Se stai realizzando prototipi per perfezionamento iterativo, codificalo e aspettati di modificarlo e refactarlo frequentemente

Se stai iniziando a scrivere il prodotto ma lo chiamerai prototipazione in modo da essere pigro , allora non essere pigro e scrivilo bene la prima volta

Se stai realizzando prototipi, perché stai pensando al codice pulito? L'idea stessa di prototipazione è che ha lo scopo di dimostrare un concetto o un'idea, e di essere gettato via in seguito.

Non sono d'accordo con la maggior parte di tutti qui dicendo che se stai già pensando alla scelta tra scrivere codice pulito o fare qualcosa velocemente per la prototipazione, scegli quest'ultimo. Soprattutto quando parli di sviluppo della fase iniziale. Non sto dicendo di non scrivere mai un codice pulito, sto dicendo di prendere l'idea, vedere che è la direzione da seguire, quindi tornare a ripulirlo ... refactoring.

Come sviluppatori di software, siamo così coinvolti nel fare le cose giuste e pulite la prima volta, che non ci rendiamo conto che non è il codice che stiamo fornendo, è una soluzione a un problema .

Penso al codice mentre scrivo un articolo:

Quando scriviamo un foglio, iniziamo da qualche parte, abbozziamo idee, contorni, ecc. Non conterrà tutti i dettagli o non avrà alcun aspetto finito - è essenzialmente una prima bozza, seguita da un secondo, e così via. Molto sarà riscritto, sostituito e / o persino rimosso lungo la strada per una carta più raffinata e finita. (Ovviamente questa analogia non arriva al punto di dire che il codice è mai veramente finito o definitivo come un foglio.)

Esistono due tipi di prototipazione:

• Prototipo evolutivo che continua ad evolversi tramite miglioramenti e correzioni per diventare il prodotto finale.
• Prototipo monouso che esiste solo per rendere la raccolta dei requisiti e il feed back dei clienti più efficaci nelle prime fasi del progetto e quindi essere completamente abbandonati e lo sviluppo del prodotto finale inizia da zero.

Secondo Capers Jones, i prototipi evolutivi producono prodotti di bassa qualità che richiedono molto più impegno e tempi più lunghi per raggiungere la stabilità.

Quindi, se stai pensando alla prototipazione in modo che il cliente possa vedere qualcosa il più rapidamente possibile per aiutarti a ottenere un'idea migliore e maggiori dettagli sui requisiti, è meglio essere un prototipo monouso e avere lo sviluppo fatto sul codice pulito in seguito. Se non puoi permettertelo, scrivi un codice pulito dall'inizio e mantienilo con cura ma, come altri hanno suggerito, non ottimizzarlo eccessivamente e non aggiungere cose finché non ne hai bisogno.

Sono riluttante a scusare la codifica sporca per qualsiasi motivo. Nella mia esperienza, le persone che affermano rapidamente e & sporca come una scusa per la prototipazione ha quell'attitudine verso qualsiasi codice, inclusa la produzione. Se qualcuno crea un prototipo disordinato, crea disordine in qualsiasi codice. La prototipazione non significa codifica sporca, significa assunzioni semplificate per testare i casi d'uso più importanti. Il codice potrebbe non essere formalmente testato, o occuparsi di tutti i dettagli, ma dovrebbe essere ancora ben progettato e ben implementato. La pulizia è un segno di competenza, i programmatori competenti provano un naturale disgusto verso il codice disordinato, indipendentemente dal suo scopo.

Scrivi codice pulito, ottimizzato e documentato fin dall'inizio. Sono incapace di farlo da solo ed è un vero problema. Non sono un programmatore, ma ho lavorato per aziende di sviluppo software in ruoli gestionali rivolti ai clienti in modo equo e dato che mi danno molte buone idee di tanto in tanto costruisco un prototipo per qualcosa. Quasi ogni volta quel prototipo veniva consegnato a uno sviluppatore che lo "puliva" e lo trasformava in un prodotto di spedizione. Quando controllerò il codice sorgente, sarà comunque l'80-90% del mio codice scadente.

Un mio collega appoggia entusiasticamente la prototipazione ripetuta, con l'avvertenza che un deve avere sufficiente disciplina per gettare via ogni prototipo e scrivere di nuovo da zero - e non solo, assicurarsi che non si influenzato dai dettagli di implementazione decisi l'ultima volta, come quello che poi si finisce a fare è scrivere lo stesso prototipo in uno stile banalmente diverso più volte. Ha suggerito semi-seriamente che se tu fossi davvero attaccato ad un pezzo di codice geniale che non potresti mai scartare, che dovresti stamparlo, eliminare il repository di controllo del codice sorgente e postare la stampa a te stesso - non ci sarà più abbastanza a lungo da non poter infiltrarsi nella successiva iterazione.

Puoi sempre iniziare a farlo funzionare (del tutto), quindi rivederlo per renderlo pulito, e quindi renderlo veloce / piccolo se ha senso economico farlo. Vorrei iniziare con alcuni esperimenti che butta via, poi TDD ritorna in esistenza quando si ha una mano su ciò che funziona.

Entrambi sono buoni. Entrambi mi piacciono Non si contraddicono l'un l'altro.

Mi piace il prototipo. Il prototipo sta sviluppando le mie capacità creative. Sto testando molte possibili soluzioni. Farlo in breve mi dà la possibilità di testare un sacco di modi possibili per risolvere il problema.

Mi piace scrivere un codice pulito, buono e testato. Sviluppa le mie abilità principali. Di solito scelgo uno dei prototipi e lo miglioro o lo riscrivo da zero.

Ma non dovresti mai confondere il prototipo con il codice di produzione. Il prototipo non dovrebbe mai entrare in produzione. Dovrebbe essere sempre contrassegnato come prototipo. Al massimo fai tutti i prototipi nel tuo ramo.

Tendo a dire che gli estremi sono quasi sempre cattivi.

Consiglio di mantenere l'equilibrio tra pulito, ben documentato e prototipazione. Quando sviluppi per una biblioteca o una piattaforma che non hai esperienza, vado più nella direzione della prototipazione. Questo è particolarmente vero all'inizio e per le piattaforme, ad es. Android o contenitori, che ti mettono nel loro corsetto. Ciò significa che implementi le loro interfacce e ti chiamano.

Dalla mia esperienza, la maggior parte del codice non vive molto a lungo. Detto questo, vai veloce implementando la tua funzionalità. Quando prima o poi (la maggior parte del tempo prima) è necessario rielaborare / rifattorizzare il codice esistente a causa della funzione successiva che riordinare, in particolare le parti con cui è complicato lavorare. Prestare attenzione a test automatici adeguati per rendere possibile il refactoring senza problemi. Per quanto riguarda le piattaforme sopra menzionate come Android: spesso rendono i test automatici non altrettanto facili a causa dell'accoppiamento ravvicinato e dell'assenza di progettazione per la testabilità. Quindi puoi sollevare la tua base di prova a un livello superiore, ad es. test di integrazione.

Ho scritto un articolo che potrebbe fornire alcuni suggerimenti su come iniziare: link