Riconciliazione di consigli di programmazione contraddittori: ottenere qualcosa di funzionante e iterativo, confrontarlo davvero prima della codifica

Non sono sicuro che pensare a un problema in anticipo rispetto all'approccio iterativo sia contraddittorio l'uno con l'altro. Proprio come molte altre cose, penso che dovresti sforzarti di raggiungere l'equilibrio tra i due. Come trovi il saldo? È qualcosa che impari con l'esperienza e spesso le migliori lezioni del tempo (cioè roba che ti dà l'esperienza) è quando non hai capito bene (o anche una lezione migliore: è chiaro che hai sbagliato). Come hai già sottolineato, c'è un detto "rilascio veloce, rilascio frequente". Ce n'è un'altra simile, "fallisci presto, fallisci veloce, fallisci spesso "

Pensare in anticipo è grande e dovresti assolutamente farlo. Ma con l'esperienza, impara a smettere di pensare ea costruire qualcosa anche se non hai tutti i dati. Costruendolo, sarai in grado di ottenere maggiori informazioni sul dominio del problema e potenzialmente trovare una soluzione molto migliore. Quindi consiglierei di non escludere gli uni dagli altri, ma di fare una "testa pensante" parte delle tue iterazioni e nel tempo penso che troverai la risposta giusta a questa domanda da solo.

Solo un piccolo esempio. L'altro giorno stavo lottando con una decisione di progettazione del software. Col senno di poi era relativamente banale ma avevo due alternative e sembrava che entrambi avrebbero funzionato. Continuavo a tornare ai pro / contro di ognuno e poi tornavo indietro e riconsiderando le mie decisioni. Guardando indietro, è un po 'imbarazzante quanto tempo ho passato a pensare. Allora mi sono detto, f # @ k! E invece di usare uno dei due progetti, sono andato avanti e ho hackerato un po 'di codice insieme, ignorando completamente tutte le cose buone che hai imparato sul buon design. Ho fatto funzionare la funzione in circa 45 minuti. Poi sono tornato indietro, ho guardato il mio codice e l'ho rifatto in qualcosa di solido e qualcosa che non mi vergognerei di controllare nel controllo del codice sorgente. La parte divertente è che dopo aver ottenuto il trucco, per elaborare un "progetto corretto" sono necessari circa 15 minuti.

Un'altra cosa che consiglierei specificamente per i problemi che stai affrontando ora (cioè un'attività complessa e complessa che si profila all'orizzonte). Invece di fare le cose in serie, fallo in parallelo. Rompi la tua giornata in blocchi dove fai ricerche e poi fermati, cambia marcia e codice per un po ', almeno su parti del progetto che non sono complete sconosciute. In questo modo, rimanere vicino al codice ti darà una prospettiva migliore e non ti brucerai cercando di assorbire troppe informazioni troppo velocemente. Almeno per me, dopo poche ore di ricerca, è bene lasciare che il cervello digerisca le cose, cambi attività e faccia qualcos'altro per un po '. Quindi torna a ulteriori ricerche.

Ci sono alcune decisioni che devono essere prese in anticipo.

Stai facendo un'applicazione web? Quindi è necessario sapere come sarà l'architettura generale. Architetture come MVC già definiscono quali saranno i tuoi pezzi funzionali di grandi dimensioni (come routing, controller, modelli, livelli di servizio, protocolli di comunicazione e così via); inventare tutto ciò da zero sarà lungo, inutile e probabilmente inferiore a quello che è già stato inventato.

Stai scrivendo qualsiasi tipo di applicazione che coinvolge raccolte di oggetti o dati? Quindi avrai bisogno di sapere quali tipi di strutture di dati sono più appropriate per il tuo particolare scenario e quali sono le loro caratteristiche di prestazione. Hai bisogno di un tempo di ricerca veloce? Che ne dici di set di dati ordinati? Farà una raccolta in memoria o hai bisogno di qualcosa di più industriale come una banca dati? Non puoi iniziare a programmare senza pensare a queste decisioni, perché se fai la scelta sbagliata, dovrai ricominciare da capo.

Detto questo, una volta prese le decisioni tecnologiche, hai la libertà all'interno del quadro che hai stabilito. L'obiettivo è quindi quello di rimanere flessibili, iterativi e (oserei dire) abbastanza agili in modo che quando il cliente cambia idea su ciò che vogliono, puoi soddisfarli con un minimo sforzo.

Come si fa? Esperienza, soprattutto. Come qualcuno ha detto una volta, l'esperienza è ciò che ottieni subito dopo averne bisogno. Ma se segui le decisioni progettuali di successo degli altri (come incorporate nelle piattaforme, nelle librerie e in altri strumenti del mestiere), puoi imparare da loro e ridurre il rischio.

Non vedo i due come mutuamente esclusivi.

Come ogni tipo di gestione dei progetti, hai bisogno sia di una visione a lungo termine che di obiettivi a breve termine.

Senza il primo, per esempio, perderai tempo perdendo le funzionalità che potrebbero non essere mai utilizzate e senza il secondo, passerai tutto il giorno a pensare a come creare l'applicazione perfetta senza terminare il tuo progetto.

Quanto spesso rilascia / etc. dipende dalla metodologia specifica che stai utilizzando.

Ciò che devi ricercare dipende da ciò che sai rispetto a ciò che non ti piace.

"Iteration" e "thinking it through" non sono contraddittori, ma sono complementari.

Anche ai loro estremi, riflettono due percorsi per arrivare allo stesso posto.

• L'estremo dell'iterazione è un migliaio di scimmie che battono le migliaia di tastiere. Con abbastanza tempo forse otterrai qualcosa che soddisfi i requisiti.
• L'estremo di "pensarci" è un approccio a cascata. Se sei fortunato, i requisiti non sono cambiati drasticamente dall'inizio del progetto al momento della consegna del codice. Oppure finirai con la paralisi dell'analisi e non avrai consegnato nulla.

Devi avere una certa comprensione del dominio e del problema prima di iniziare la codifica. Questa è la parte del "pensare attraverso". Idealmente, vedrai il percorso di alto livello dall'inizio alla fine su come risolvere il problema.

Ma potresti vedere solo parti importanti di quel percorso, e certamente non tutte le tappe lungo il percorso. Ecco dove entra in gioco l'iterazione. Puoi iniziare a scorrere le versioni dell'applicazione e cercare feedback per:

• Identifica i roadblock che appaiono nei livelli più bassi di dettaglio
• Vedi il feedback degli stakeholder per chiarire le aree torbide nel percorso di alto livello.

La radice latina di decidere significa "tagliare". L'iterazione ti consente di decidere cosa funziona in pratica invece che solo la teoria e l'iterazione ti consente di ritagliare le altre opzioni che non sono fattibili.

Quindi devi pensare al problema per capire cosa intendi fare. Ma poi è necessario scorrere le versioni dell'applicazione per trasformare effettivamente l'idea in codice reale.

La mia regola empirica: se non comprendi completamente qualsiasi parte del problema, devi fare un passo indietro e pensarlo a fondo (includo la prototipazione e il codice throw-away per capire le API ecc. come parte di "pensa attraverso"). Se è fondamentalmente una raccolta di problemi che hai già risolto e devi solo capire il modo migliore per adattare tutto insieme in questa particolare istanza, quindi itera.

Onestamente, questa non è una regola dura e veloce. Penso davvero che sia necessario fare un mix di entrambi per un dato progetto. Quanto di ciascuno di voi farà dipenderà in gran parte da quanto il progetto è vicino a quello che avete già completato in passato.