Sto programmando di lavorare / iniziare alcuni progetti personali che potrebbero finire come il mio lavoro quotidiano. Mi ha fatto pensare, da che parte dovrei iniziare?

• Solo un prototipo: scrivi solo codice di base funzionante che potrebbe costare tonnellate di tempo per l'ottimizzazione e il refactoring per una facile espansione.

• Scrivi codice pulito, ottimizzato e documentato fin dall'inizio, tenendo presente che se dopo qualche tempo non sarà conveniente, verrà eliminato.

Aggiornamento: Combinare YAGNI con sunpech e le risposte di M.Sameer ha perfettamente senso per me :) grazie a tutti per l'aiuto.

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

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

• Il tempo impiegato viene impiegato per aggiungere, testare o migliorare le funzionalità necessarie.
• Le nuove funzionalità devono essere sottoposte a debug, documentate e supportate.
• Qualsiasi nuova funzionalità impone vincoli su ciò che può essere fatto in futuro, quindi una funzione non necessaria ora può impedire l'implementazione di una funzione necessaria in un secondo momento.
• Fino a quando la funzionalità non è effettivamente necessaria, è difficile definire completamente cosa dovrebbe fare e testarla. Se la nuova funzionalità non è definita e testata correttamente, potrebbe non funzionare correttamente, anche se alla fine è necessaria.
• Porta a codice gonfio; il software diventa più grande e più complicato. A meno che non ci siano specifiche e un qualche tipo di controllo di revisione, la funzione potrebbe non essere nota ai programmatori che potrebbero farne uso.
• L'aggiunta della nuova funzionalità può suggerire altre nuove funzionalità. Se anche queste nuove funzionalità saranno implementate, ciò potrebbe tradursi in un effetto a palla di neve verso il featurism strisciante.

Di conseguenza, non dovresti limitarti a prototipare ... né scrivere codice pulito, ottimizzato e documentato sin dall'inizio, tenendo presente che se entro un certo periodo non sarà conveniente, verrà eliminato.

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

come di solito...

Dipende

Se stai prototipando per mitigare un rischio o esporre uno sconosciuto, basta codificarlo e aspettarti di buttarlo via quando hai finito

Se stai prototipando per un perfezionamento iterativo, basta codificarlo e aspettarti di modificarlo e riformattarlo frequentemente

Se stai iniziando a scrivere il prodotto reale ma lo chiami prototipazione in modo da poter essere pigro , allora non essere pigro e scriverlo bene la prima volta

Se stai prototipando, perché stai pensando al codice pulito? L'idea stessa del prototipo è 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 in fretta per la prototipazione, scegli quest'ultimo. Soprattutto quando si parla di sviluppo nella fase iniziale. Non sto dicendo di non scrivere mai un codice pulito, sto dicendo di tirar fuori l'idea, vedere che è la direzione da seguire, quindi tornare a ripulirlo-- refactor.

Come sviluppatori software, siamo così presi dal fare le cose giuste e pulite la prima volta, che non riusciamo a renderci conto che non è il codice che stiamo offrendo, è una soluzione a un problema .

Penso alla codifica come scriverei un articolo:

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

Esistono due tipi di prototipazione:

• Prototipo evolutivo che continua a evolversi attraverso miglioramenti e correzioni per diventare il prodotto finale.
• Prototipo usa e getta che esiste solo per rendere più efficiente la raccolta dei requisiti e il feedback dei clienti nelle prime fasi del progetto, per poi essere completamente abbandonato e lo sviluppo del prodotto finale inizia da zero.

Secondo Capers Jones, i prototipi evolutivi producono prodotti finali di bassa qualità che richiedono molto più sforzo e più tempo 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 usa e getta e fare lo sviluppo su codice pulito in seguito. Se non puoi permetterlo, scrivi un codice pulito dall'inizio e mantienilo attentamente, ma come altri hanno suggerito non ottimizzare eccessivamente e non aggiungere cose finché non ne hai bisogno.

Sono riluttante a scusare la programmazione sporca per qualsiasi motivo. Nella mia esperienza, le persone che dichiarano di essere pronte e sporche come una scusa per la prototipazione hanno questo atteggiamento nei confronti di qualsiasi codice, compresa la produzione. Se qualcuno crea un prototipo disordinato, crea disordine in qualsiasi codice. La prototipazione non significa codifica sporca, ma presupposti semplificati per testare i casi d'uso più importanti. Il codice potrebbe non essere testato formalmente o prendersi cura di tutti i dettagli, ma dovrebbe essere ancora ben progettato e ben implementato. La pulizia è un segno di competenza, i programmatori competenti provano naturale disgusto per il codice disordinato, indipendentemente dal suo scopo.

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

Un mio collega sostiene con entusiasmo la ripetizione della prototipazione, con l'avvertenza che si deve avere abbastanza disciplina per buttare via ogni prototipo e scrivere di nuovo da zero - e non solo, assicurarsi che non si sia influenzati dai dettagli di implementazione decisi l'ultima volta , come si finisce per scrivere più volte lo stesso prototipo in uno stile banalmente diverso. Ha suggerito semi-seriamente che se tu fossi davvero attaccato a un brillante pezzo di codice che non potevi scartare, dovresti stamparlo, eliminare il repository di controllo del codice sorgente e pubblicare la stampa per te - sarà sparito abbastanza a lungo da non poter infiltrarsi nella prossima iterazione.

Puoi sempre iniziare facendolo funzionare (a tutti), quindi rivederlo per renderlo pulito e quindi farlo veloce / piccolo se ha senso economico farlo. Vorrei iniziare con alcuni esperimenti che butti via, poi TDD ritorna in esistenza quando hai un controllo su ciò che funziona.

Entrambi sono buoni. Mi piacciono entrambi. Non si contraddicono a vicenda.

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

Mi piace scrivere codice pulito e ben testato. Sviluppa le mie competenze chiave. Di solito scelgo uno dei prototipi e lo perfeziono o 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. Nella migliore delle ipotesi, esegui tutta la prototipazione nella tua filiale.

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 libreria o piattaforma non hai esperienza con me vado più nella direzione della prototipazione. Ciò è particolarmente vero all'inizio e per le piattaforme, ad esempio Android o container, 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 funzione. Prima o poi (la maggior parte delle volte prima) è necessario rielaborare / rifattorizzare il codice esistente a causa della funzione successiva in cui vengono riordinate soprattutto le parti con cui è complicato lavorare. Prestare attenzione a disporre di test automatici adeguati per rendere possibile il refactoring senza problemi. Appartenenti alle piattaforme sopra menzionate come Android: spesso rendono i test automatizzati non facili a causa dello stretto accoppiamento e della mancanza di design per la testabilità. Quindi è possibile elevare la base di test a un livello superiore, ad esempio test di integrazione.

Ho scritto un articolo che potrebbe dare alcuni suggerimenti sull'avvio: https://medium.com/@ewaldbenes/start-lean-why-its-best-to-split-your-next-coding-project-by-feature-70019290036d