È normale pensare a un problema di progettazione per giorni senza codice scritto? [chiuso]

A volte guardo in bianco nello spazio o disegno idee e scrivo alcuni pseudo codici su carta. Quindi lo gratto e ricomincio, quindi quando penso di avere la soluzione corretta per il problema, inizio a scrivere il codice.

È normale pensare per giorni senza scrivere alcun codice? È questo un segno che sto affrontando il problema completamente sbagliato? Mi rende nervoso non avere alcun codice tangibile scritto nel mio IDE.

A seconda del problema che si sta tentando di risolvere, la fase di progettazione può richiedere settimane e mesi (se non anni), non solo giorni.

Ci vuole esperienza per non iniziare a scartare immediatamente il codice. Pensare all'architettura e al design di alto livello dovrebbe richiedere giorni se non di più, sicuramente qualcosa che dovrebbe accadere prima di iniziare a scrivere il codice.

Questo è comunemente indicato come "Paralisi dell'analisi"

È comune ma sbagliato. Ad un certo punto è necessario testare le varie idee per vedere cosa funzionerà meglio per te, quindi migliorarlo progressivamente.

Si consiglia di leggere il programmatore Pragmatic, in particolare il capitolo 2, la sezione "Proiettili da tracer"

Questo è completamente comune. Tuttavia, se segui un approccio "Prova prima" o TDD, è meno comune e potrebbe aiutarti a formulare meglio le tue idee.

Le abitudini di solito sono il risultato di approcci di prova ed errore alle cose e di continuare ciò che ci dà i risultati desiderati ed evitare ciò che non lo fa. Entra in gioco anche fare ciò che ci piace ed evitare ciò che non ci piace. Funziona fino a un certo punto perché alla fine, faremo qualcosa che non ci piace per ottenere l'affitto pagato.

Dipende da cosa ti porta a questo e alle tue ragioni. Eccone alcuni:

• Troppo spesso, hai dovuto cambiare codice a causa delle modifiche di progettazione
• Non si modifica un design scadente perché la soluzione minore era già codificata
• Preferiresti disegnare e progettare piuttosto che scrivere procrastinazione di codice
• doversi preoccupare della sintassi e dei dettagli della codifica, ti distrae dal pensare a progetti migliori.

Spero che tu abbia scoperto che se progetti più a lungo, il tuo codice è migliore. Se riesci a guardare indietro e vedere che non importa quanto tempo dedichi alla progettazione, potresti voler cambiare. Un'altra considerazione è la frequenza con cui riscontri problemi dopo aver scritto il codice rispetto a lavorare con i tuoi progetti. Se non riscontri problemi fino a dopo aver scritto del codice, dovresti prendere in considerazione un equilibrio e iniziare a scrivere qualcosa prima o poi. Forse questo approccio potrebbe essere applicato all'uso di tecnologie più recenti o una funzionalità molto complessa.

Non so se ho la disciplina di attenermi a un approccio o all'altro anche quando scopro che uno funziona meglio dell'altro. A volte sento il bisogno di andare alla lavagna; altri la tastiera.

È molto comune e ritengo sia un modo migliore di gestire e comprendere le cose. Mentre lavoro su un progetto, rimango bloccato molte volte e ci vogliono un giorno o due per capire come posso affrontarlo meglio. Anche dopo che il problema è stato risolto, aspetto che passi un giorno. Questo mi rende più rinfrescato e andare avanti.

È un fenomeno naturale e utile per uno sviluppatore intercettare il tempo della sua mente e in mezzo.

Quando ho seguito un corso di project management, una delle cose che l'istruttore ci ha riferito sulla pianificazione, che mi è rimasto impresso nella testa, era che la regola empirica che insegnavano ai militari era di calcolare 1/3 del tempo per la pianificazione . Quindi, se hai avuto un'operazione che ti ha richiesto di essere completato tra 3 mesi, pensa a dedicare un mese alla pianificazione prima di iniziare l'esecuzione.

A mio avviso, ci sono tre approcci, ognuno adatto per una specifica situazione di codifica

1. Ho già visto un problema simile in precedenza, quindi ho una buona idea degli schemi da applicare, ed è chiaro come la soluzione dovrebbe comportarsi e rispondere.

   => Usa BDD / TDD partendo dalle soluzioni desiderate e lavorando al codice. (Ok, a volte imbroglio e scrivo un po 'di codice e poi il test - tipo di approccio annidato 2. -> 1.).

2. Ho una buona idea dei modelli da applicare, ma non sono sicuro di come dovrebbe essere la soluzione.

   => Prototipo per vedere quali tipi di cose interessanti spuntano. Passa a 1. quando capisco quali cose interessanti sono desiderate.

3. Non sono sicuro di quali schemi applicare.

   => Pensaci al problema e in che modo i vari modi di affrontare il problema influenzano il codice. Passa a 2) o 1) a seconda del risultato di quell'esercizio.

In altre parole, la risposta è la preferita dell'ingegnere: dipende.

Meglio dedicare un mese a pensare e progettare piuttosto che creare un prototipo rapido basato su un design scadente che devi poi rimettere in forma. Soprattutto se fai parte di una squadra; quando altri iniziano a seconda del codice, è molto più difficile implementare un design migliore con un'API diversa.

Concordo con le altre risposte che, in linea di principio, prendere tempo per riflettere su un problema / soluzione è una buona idea. Tuttavia, se ti senti bloccato, ho alcuni consigli su come rendere il processo di pianificazione un po 'più coerente:

• Crea artefatti di design. E se non scrivessi codice? Forse hai appena scritto un diario dei tuoi pensieri. O uno schizzo di una soluzione generale. O anche solo un ottimo riassunto del problema che affini nel tempo. Mentre consideri le idee e le accetti / le rifiuti, tieni un registro dei tuoi ragionamenti sull'argomento. In questo modo, alla fine della giornata, puoi ancora indicare i risultati del mondo reale come prova del tuo lavoro.

• Parlare alle persone! Non c'è niente come avere un essere umano vivente e che respira con cui discutere idee. Se pensi di essere bloccato, parlane con qualcuno. Prendi qualcuno - chiunque! - e spiega loro il problema. Disegna i tuoi pensieri su come risolvere il problema. Anche se tutto ciò che fanno è inspirare, espirare e battere le palpebre per dieci minuti mentre borbotti, è probabile che scoprirai nuove intuizioni proprio nel processo di spiegazione del problema .

Come diceva Satchel Paige, "A volte mi siedo e penso, a volte mi siedo".

Immagino che quello a cui stava arrivando è che a volte è bello schiarirsi le idee poiché potrebbe portarti a pensare al tuo problema in modo diverso. Quindi, se non stai sbagliando via al codice, potresti trovare una soluzione o un'idea che potrebbe esserti sfuggito altrimenti. Quindi, sì, è normale e una buona pratica non saltare direttamente al codice.

Ci sono due modi in cui eseguo questo processo da solo. Creo una cartella in cui ho un file di testo e tutti i disegni relativi al progetto. Annoto lì le mie idee e cerco di salvare l'intero processo di pensiero nel miglior modo possibile. Creerò anche un progetto scratchpad in cui posso testare rapidamente idee semplici dagli algoritmi ai layout CSS.

Programma = Algoritmo + Struttura dati

IMHO, il processo di progettazione (risoluzione dei problemi) governa totalmente. I dettagli di implementazione (problema tecnico) seguono e si risolvono naturalmente.

Ecco il mio caso di pensiero.

1. A partire da zero Innanzitutto è necessaria un'idea approssimativa di ciò che si desidera. Prova a ottenere un elenco di alcuni requisiti o crearli. Dovrebbe volerci un po 'di tempo per capire le cose qui. Una volta che hai almeno un pezzo che sei sicuro di volere, conoscendo la maggior parte dell'interfaccia di quel pezzo, quindi inizia a scrivere codice.

2. Risolvere un problema con il codice esistente Prima di tutto, tenere traccia del problema. Ciò potrebbe richiedere del tempo per non scrivere codice reale (potrebbe essere scritto un codice di debug, ma in genere questo non verrà mantenuto). Una volta trovato il problema, a seconda della complessità, inizia a scrivere codice per provare a risolverlo. Una piccola riflessione dovrebbe essere richiesta una volta che il bug è noto. Se il problema risulta essere un grave difetto di progettazione, consultare la sezione successiva.

3. Cambiamenti di progettazione / caratteristiche principali Questo è molto probabilmente quello che richiederà più attenzione. Pensare a preservare la struttura, la retrocompatibilità, ecc. Deve essere incluso. Pensare per il miglior cambiamento potrebbe far risparmiare un tempo significativo, ma in genere per me non è più di qualche giorno.

4. Aggiunta di una funzione semplice Se non è richiesta alcuna modifica significativa della progettazione, è sufficiente codificare la funzione, utilizzando alcune prove / errori. Ciò non dovrebbe richiedere un sacco di tempo in generale.

Non sarò d'accordo con il consenso su questo. Preferirei iniziare a prototipare qualcosa non appena avrò anche la più vaga idea scritta su un tovagliolo di come voglio che il mio sistema funzioni. È quasi impossibile per me pensare a tutti i piccoli dettagli che potrebbero causare problemi a meno che non specifichi le cose in modo molto preciso. Se sto solo discutendo di design con le persone, è troppo facile fare un cenno con la mano su alcuni dei problemi più complessi. Una volta specificato cose come queste, potrebbe anche essere direttamente nel codice sorgente piuttosto che in qualche altro mezzo di espressione altrettanto preciso e formale ma che non può essere compilato ed eseguito.

Dipende da cosa intendi per "normale" . A proposito di me stesso, penso che il codice sia un ottimo strumento di apprendimento. Quindi, di fronte a un problema complesso, faccio schizzi su carta ma faccio anche un po 'di codifica test-driven. Il codice mi dice che una lavagna non può dire e viceversa, e forse il risultato è intuizione o la necessità di un paio di domande in più all'esperto del dominio.

Quindi il vero consiglio è: "Usa tutti gli strumenti di apprendimento necessari per avvicinarti alla definizione del problema" , ma anche "ricorda che questi sono strumenti di apprendimento, quindi non innamorartene" sia il codice che gli schizzi devono essere gettati via .

In questa era di programmazione RAD e agile, dovresti iniziare a sviluppare non appena puoi identificare le parti principali del sistema, i dettagli arriveranno. Poiché i software stanno diventando più grandi, concentrarsi prematuramente su ogni singolo dettaglio non ti porterà da nessuna parte.