Conciliare i consigli di programmazione contraddittori: far funzionare qualcosa e iterare vs. pensarci davvero prima di scrivere codice

Sono un programmatore intermedio con alcuni anni di esperienza professionale che è a metà di un master. Nell'imparare a programmare ho sentito spesso due consigli apparentemente contraddittori.

Il primo consiglio è stato far funzionare qualcosa velocemente, vedere come funziona (tramite prototipazione o test informali), migliorare la versione, vedere come funziona di nuovo, migliorarlo di nuovo ... e quindi ripetere il ciclo fino a quando non hai finito . Questo a volte viene chiamato "sviluppo a spirale" o definito come "rilascio anticipato, rilascio spesso".

Il secondo consiglio è stato: pensare davvero a un progetto prima di scrivere mai un codice.

Ho avuto successo con entrambi i metodi e direi che sono d'accordo con ogni filosofia.

Ma ora sto iniziando ad affrontare progetti molto più complessi che non ho idea di come completare (come applicazioni distribuite e programmazione grafica basata sulle prestazioni).

Come posso fare per questi progetti?

Comincio semplicemente a programmare QUALCOSA e imparo (piattaforme / metodi / lingue / architetture) man mano che vado - o mi fermo dalla programmazione e faccio un sacco di ricerche / letture prima ancora di aprire l'IDE?

Come riconciliare questi consigli contraddittori di programmazione?

Non sono sicuro che pensare a un problema in anticipo rispetto all'approccio iterativo siano contraddittori tra loro. Proprio come molte altre cose, penso che dovresti sforzarti di raggiungere l'equilibrio tra i due. Come trovi l'equilibrio? È qualcosa che impari con l'esperienza e spesso le lezioni migliori (ad es. Cose che ti danno esperienza) è quando non la capisci nel modo giusto (o lezione ancora migliore: semplicemente sbagli). Come hai già sottolineato, c'è un detto "rilascio veloce, rilascio spesso". Ce n'è un altro simile, "fallisci presto, fallisci velocemente, fallisci spesso"

Pensare in anticipo è fantastico e dovresti assolutamente farlo. Ma con l'esperienza, impara quando smettere di pensare e costruire semplicemente qualcosa anche se non hai tutti i dati. Costruendolo, sarai in grado di ottenere maggiori informazioni sul dominio problematico e potenzialmente trovare una soluzione molto migliore. Quindi ti consiglio di non escludere l'uno dall'altro, ma di rendere la "testa pensante" parte delle tue iterazioni e nel tempo penso che troverai tu stesso la risposta giusta a questa domanda.

Solo un piccolo esempio. L'altro giorno stavo lottando con una decisione di progettazione del software. Con il senno di poi è stato relativamente banale ma avevo due alternative e sembrava che funzionassero entrambi. Ho continuato a tornare indietro ai pro / contro di ciascuno e poi a tornare indietro e riconsiderare le mie decisioni. Guardando indietro, è un po 'imbarazzante quanto tempo ho trascorso a pensare. Poi mi sono detto, f # @ k! E invece di utilizzare uno dei due progetti, sono andato avanti e ho hackerato un po 'di codice insieme, ignorando completamente tutte le cose buone che impari sul buon design. Ho funzionato in circa 45 minuti. Poi sono tornato, ho guardato il mio codice e lo ho trasformato in qualcosa di solido e qualcosa di cui non mi vergognerei di controllare il controllo del codice sorgente. La parte divertente è che dopo che ho fatto funzionare l'hacking, ho escogitato "

Un'altra cosa che consiglierei specificamente per i problemi che stai affrontando ora (ad es. Compiti grandi e complessi che si profilano davanti). Invece di fare cose in serie, fatele in parallelo. Rompi la tua giornata in pezzi in cui fai ricerche e poi fermati, cambia marcia e codice per un po ', almeno su parti del progetto che non sono incognite complete. In questo modo stare vicino al codice ti darà una prospettiva migliore e non ti esaurirai tentando di assorbire troppe informazioni troppo velocemente. Almeno per me, dopo poche ore di ricerca, è bene lasciare che il cervello digerisca le cose, cambi i compiti e faccia qualcos'altro per un po '. Quindi torna a ulteriori ricerche.

Ci sono alcune decisioni che devono essere prese in anticipo.

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

Stai scrivendo qualche tipo di applicazione che coinvolge raccolte di oggetti o dati? Quindi dovrai sapere quali tipi di strutture dati sono più appropriate per il tuo particolare scenario e quali sono le loro caratteristiche prestazionali. Hai bisogno di tempi di ricerca rapidi? Che ne dici di set di dati ordinati? Farà una raccolta in memoria o hai bisogno di qualcosa di più industriale come un database? Non puoi semplicemente iniziare a scrivere codice 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à nel quadro che hai stabilito. L'obiettivo quindi è di rimanere flessibile, iterativo e (oserei dire) abbastanza agile in modo tale che quando il cliente cambia idea su ciò che desidera, è possibile soddisfarlo con un minimo sforzo.

Come si fa a farlo? Esperienza, principalmente. Come qualcuno ha detto una volta, l'esperienza è ciò che ottieni subito dopo averne bisogno. Ma se segui le decisioni di progettazione di successo di altri (come incarnato nelle piattaforme, nelle biblioteche e in altri strumenti del commercio), puoi imparare da loro e ridurre il rischio.

Non li vedo come reciprocamente esclusivi.

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

Senza il primo finirai per perdere tempo, ad esempio con funzionalità che potrebbero non essere mai utilizzate e senza il secondo passerai tutto il giorno a pensare a come creare l'applicazione perfetta senza finire il tuo progetto.

Con quale frequenza rilasci / etc. dipende dalla metodologia specifica che si sta utilizzando.

Ciò che devi cercare dipende da ciò che conosci e da ciò con cui non ti senti a tuo agio.

"Iterazione" e "pensarci su" non sono contraddittori, ma sono complementari.

Anche ai loro estremi, riflettono due percorsi per raggiungere lo stesso posto.

• L'estremo di Iteration è un migliaio di scimmie che bussano a mille tastiere. Con abbastanza tempo forse otterrai qualcosa che soddisfa i requisiti.
• L'estremo di "pensarci bene" è un approccio a cascata. Se sei fortunato, i requisiti non sono cambiati radicalmente dall'inizio del progetto al momento della consegna del codice. Oppure finirai con la paralisi dell'analisi e non avrai prodotto nulla.

Devi avere una certa comprensione del dominio e del problema prima di iniziare a scrivere codice. Questa è la parte "pensaci bene". 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 fermate lungo il percorso. È qui che entra in gioco l'iterazione. Puoi iniziare a iterare attraverso le versioni dell'applicazione e cercare feedback per:

• Identifica i blocchi stradali che emergono nei livelli più bassi di dettaglio
• Vedi il feedback delle parti interessate per chiarire quelle aree oscure nel percorso di alto livello.

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

Quindi devi riflettere attentamente sul problema per capire cosa farai. Ma poi è necessario scorrere le versioni dell'applicazione per trasformare effettivamente l'idea in codice reale.

La mia regola empirica: se non capisci completamente qualsiasi parte del problema, devi fare un passo indietro e pensarci a fondo (includo la prototipazione e il codice usa e getta per comprendere le API ecc. Come parte di "pensaci su") . Se è fondamentalmente una raccolta di problemi che hai risolto in precedenza e devi solo trovare il modo migliore per adattare tutto insieme in questo particolare caso, quindi iterare.

Onestamente, non è una regola dura e veloce. Penso davvero che tu debba fare un mix di entrambi per ogni dato progetto. Quanto di ognuno di voi probabilmente dipenderà principalmente da quanto è vicino il progetto a uno che avete già completato in passato.