A volte fisso lo sguardo nello spazio o disegna idee e scrivo sulla carta alcuni pseudo codici. Poi lo gratto e ricomincio, poi quando penso di avere la soluzione corretta per il problema comincio a scrivere il codice.
È normale pensare per giorni senza scrivere alcun codice? È un segno che sto affrontando il problema completamente nel modo sbagliato? Mi rende nervoso non ricevere alcun codice tangibile scritto nel mio IDE.
A seconda del problema che stai cercando di risolvere, la fase di progettazione può richiedere settimane e mesi (se non anni), non solo giorni.
Ci vuole esperienza per non iniziare a battere immediatamente il codice. Pensare all'architettura e al design di alto livello dovrebbe impiegare giorni se non di più, sicuramente qualcosa che dovrebbe accadere prima di iniziare a scrivere il codice.
Questo è comunemente definito "Analisi della paralisi"
È comune ma sbagliato. A un certo punto è necessario testare le varie idee per vedere cosa funzionerà meglio per voi, quindi migliorare in modo incrementale su di esso.
Lettura consigliata il programmatore Pragmatico In particolare il capitolo 2 la sezione su "Tracer Bullets"
Questo è completamente comune. Tuttavia, se utilizzi un approccio "Test prima" o TDD, è meno comune e potrebbe aiutarti a formulare meglio le tue idee.
Le abitudini sono di solito il risultato di approcci di prova ed errori alle cose e continuando ciò che ci dà i risultati desiderati ed evitando ciò che non fa. Fa ciò che ci piace ed evitiamo ciò che non ci piace entra in gioco. Funziona fino a un certo punto perché alla fine, faremo qualcosa che non ci piace per ottenere l'affitto pagato.
Dipende da cosa ti ha portato a questo e ai tuoi motivi. Eccone alcuni:
Spero che tu abbia scoperto che se progetti più a lungo, il tuo codice è migliore. Se puoi guardare indietro e vedere che non importa quanto tempo dedichi al design, potresti voler cambiare. Un'altra considerazione è la frequenza con cui si scoprono problemi dopo aver scritto codice rispetto a lavorare con i propri progetti. Se non trovi problemi fino a dopo aver scritto del codice, dovresti prendere in considerazione un equilibrio e iniziare a programmare qualcosa prima o poi. Forse questo approccio potrebbe essere applicato all'uso di tecnologie più recenti o di una funzionalità molto complessa.
Non so se ho la disciplina per seguire un approccio o l'altro anche quando scopro che uno funziona meglio dell'altro. A volte sento il bisogno di andare alla lavagna bianca; altri la tastiera.
È molto comune e ritengo sia un modo migliore per gestire e comprendere le cose. Mentre lavoro su un progetto, mi blocco molte volte e ci vuole un giorno o due per capire come posso avvicinarmi meglio. Anche dopo che il problema è stato risolto, aspetto che passi un giorno. Questo mi rende più aggiornato e andare avanti.
È un fenomeno naturale e buono per uno sviluppatore di intercettare il suo tempo mentale e tra.
Quando ho seguito un corso di project management, una delle cose che l'istruttore ci ha riferito sulla pianificazione, che mi è rimasta impressa nella testa, era che la regola empirica che insegnavano nell'esercito era quella di calcolare 1/3 del tempo per la pianificazione. Quindi, se hai avuto un'operazione che ti ha richiesto di essere completata entro 3 mesi, calcola di dedicare un mese alla pianificazione prima di iniziare l'esecuzione.
A mio avviso, ci sono tre approcci, ciascuno adatto per una specifica situazione di codifica
Ho già visto un problema simile prima quindi ho una buona idea dei pattern 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 - un tipo di approccio nidificato 2. - > 1.)
Ho una buona idea dei pattern 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.
Non sono sicuro dei motivi da applicare.
= > Pensaci al problema e come i vari modi di affrontare il problema influenzano il codice. Passa a 2) o 1) a seconda dell'esito di quell'esercizio.
In altre parole, la risposta è la preferita dell'ingegnere: dipende.
Meglio passare un mese a pensare e progettare piuttosto che montare un prototipo veloce basato su un design scadente che dovrai poi modellare. Soprattutto se sei in una squadra; quando gli altri iniziano a dipendere dal tuo codice, è molto più difficile implementare un design migliore con un'API diversa.
Sono d'accordo con le altre risposte che, in linea di principio, prendere tempo per pensare a un problema / soluzione è una buona idea. Tuttavia, se ti senti bloccato, ho alcune raccomandazioni su come rendere il processo di pianificazione un po 'più coerente:
Crea artefatti di design. Quindi cosa succede se non si scrive codice? Forse scrivi solo un diario dei tuoi pensieri. O uno schizzo di una soluzione generale. O anche solo un buon riassunto del problema che si raffina nel tempo. Mentre consideri le idee e le accetti / rifiuti, tieni un registro dei tuoi ragionamenti sull'argomento. In questo modo, alla fine della giornata puoi ancora indicare i risultati reali come prova del tuo lavoro.
Parla con le persone! Non c'è niente come avere un essere umano vivente e respirante 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 chiacchiera, è probabile che scoprirai nuove intuizioni solo nel processo di spiegazione del problema .
Come ha detto Satchel Paige, "A volte mi siedo e penso, ea volte mi siedo."
Immagino che quello che stava facendo è che a volte è bene svuotare la mente poiché potrebbe indurti a pensare al tuo problema in un modo diverso. Quindi, se non stai battendo il codice potresti trovare una soluzione o un'idea che potrebbe averti sfuggito altrimenti. Quindi, sì, è normale e una buona pratica non saltare direttamente nella codifica.
Ci sono due modi in cui io stesso faccio questo processo. Creo una cartella in cui ho un file di testo e tutti i disegni relativi al progetto. Annoto le mie idee e provo a salvare l'intero processo di pensiero nel miglior modo possibile. Creerò anche un progetto scratchpad in cui posso testare rapidamente le idee semplici dagli algoritmi ai layout CSS.
Programma = Algoritmo + Struttura dati
IMHO, il processo di progettazione (risoluzione dei problemi) regola totalmente. I dettagli di implementazione (problemi tecnici) seguono e risolvono in modo naturale.
Ecco il mio pensiero.
A partire da zero per prima cosa è necessaria un'idea approssimativa di ciò che desideri. Cerca di ottenere un elenco di alcuni requisiti o crearli. Ci vorrà un po 'di tempo per capire le cose qui. Una volta che hai almeno un pezzo di cui sei sicuro di te, conoscendo la maggior parte dell'interfaccia di quel pezzo, quindi inizia a programmare.
Risolve un problema con il codice esistente Prima di tutto, monitora il problema. Questo potrebbe richiedere un po 'di tempo per non scrivere codice reale (potrebbe essere scritto del codice di debug, ma questo in genere non verrà mantenuto). Una volta trovato il problema, a seconda della complessità, inizia a scrivere il codice per provare a risolverlo. Poche cose dovrebbero essere richieste una volta che l'errore è noto. Se il problema si risolve in un difetto di progettazione importante, consulta la sezione successiva.
Cambiamenti di design / caratteristiche principali è molto probabilmente quello che richiederà più pensiero. Il pensiero di preservare la struttura, la compatibilità all'indietro, ecc. Devono essere inclusi. Pensare al miglior cambiamento potrebbe far risparmiare un tempo significativo, ma in genere per me non è più di pochi giorni.
Aggiunta di una funzione semplice Se non è richiesta alcuna modifica significativa del progetto, è sufficiente codificare la funzione, utilizzando alcuni tentativi / errori. Questo non dovrebbe richiedere un sacco di tempo in generale.
Non sono d'accordo con il consenso su questo. Preferirei iniziare la prototipazione di qualcosa non appena avrò 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 un modo molto preciso. Se sto solo discutendo di design con le persone, è troppo facile sfogliare alcuni dei problemi più complessi. Una volta che sto specificando cose come questa, potrebbe anche essere direttamente nel codice sorgente piuttosto che in altri modi di espressione che sono altrettanto precisi e formali ma non possono essere compilati ed eseguiti.
Dipende da cosa intendi per "normale" . Parlando di me stesso, penso che il codice sia un ottimo strumento di apprendimento. Quindi, quando si affronta un problema complesso, faccio schizzi su carta ma eseguo anche alcune codifiche testate. Il codice mi dice che una lavagna non può dire e viceversa, e forse il risultato è l'intuizione o la necessità di un paio di altre domande all'esperto di dominio.
Quindi il vero consiglio è: "Usa ogni strumento di apprendimento necessario per avvicinarti alla definizione del problema" , ma anche "ricorda che questi sono strumenti di apprendimento, quindi non cadere in amo con loro " sia il codice che gli schizzi sono pensati per essere gettati via.
In questa era di programmazione RAD e agile, è necessario iniziare a sviluppare non appena è possibile identificare le parti principali del sistema, i dettagli arriveranno. Poiché i software si stanno ingrandendo, concentrarsi prematuramente su ogni singolo dettaglio non ti porterà da nessuna parte.
Leggi altre domande sui tag design