Come gestisco la paralisi dell'analisi?

Molto spesso, sono bloccato nella scelta della migliore decisione di progettazione. Anche per piccoli dettagli, come definizioni di funzioni, flusso di controllo e nomi di variabili, trascorro periodi insolitamente lunghi a esaminare i vantaggi e gli svantaggi delle mie scelte.

Mi sento come se stessi perdendo molta efficienza trascorrendo le mie ore su dettagli insignificanti come questi. Anche se, nella parte posteriore della mia mente, so che posso cambiare queste cose se il mio progetto attuale non funziona, ho difficoltà a decidere con fermezza su una scelta.

Cosa devo fare per combattere questo problema?

Due semplici regole:

1. Fai la cosa più semplice che potrebbe funzionare.
2. Refactor continuamente.

Quando inizi a fare ognuna di queste cose, avrai la certezza di poter prendere semplici decisioni ora senza compromettere la tua capacità di rispondere ai cambiamenti in seguito.

Ricorda che la correzione futura significa rendere il codice facile da modificare, non cercare di anticipare ogni possibile modo in cui potrebbe essere necessario modificare il codice.

Di solito quando mi sento così significa che devo provare:

1. Alzati, cammina e assicurati che tutta la biologia funzioni correttamente.
2. Vai su una lavagna e disegna finché non ho una sensazione di fiducia.
3. Trova un "compagno di reclamo per il design" con cui puoi semplicemente risolvere il problema.

Se il problema riguarda la sintassi e piccoli pezzi, allora:

1. Soddisfa te stesso che, anche se brutto, è ben incapsulato da qualche parte e rappresenta un tipo di innesto puramente locale.
2. Aggiungi marcatori TODO o solo commenti che spiegano perché il codice ti infastidisce.
3. Passa alla prossima attività.

È molto facile pensare a te stesso inazione. Anche se riesci, in qualche modo, a trovare la migliore soluzione in questo momento che potrebbe facilmente cambiare prima di completare il progetto, e poi?

È meglio scegliere una soluzione decente e correre con essa, piuttosto che sedersi e meditare su quale sarebbe la soluzione migliore . La soluzione migliore è sfuggente e peggio, soggettiva. Se i requisiti cambiano anche leggermente, la tua soluzione potrebbe rivelarsi peggiore di una soluzione che hai scartato perché non era la migliore in quel momento.

Sto imparando a evitare anche la paralisi dell'analisi, quindi complimenti a noi =) Questo succede spesso perché vogliamo fare il "miglior design". In realtà, "il migliore" è negli occhi di chi guarda . La mia formula per evitare la paralisi dell'analisi è applicare il principio di progettazione abbastanza buono . Come lo faccio? Porto variabili come vincoli temporali, pianifico e mi chiedo qual è il progetto più semplice che può svolgere il lavoro (questo non significa il più semplice) senza compromettere la qualità, ma allo stesso tempo, mi assicuro che sia un test e un aperto per estensione chiuso per modifica (OCP)anche il design. Cosa intendo per testabile e OCP? Bene, invece di cercare ciò che ho considerato meglio, ho considerato un design che può dirmi quando le cose vanno male e provare a fare il codice sufficiente che mi consente di refactoring e migliorare in seguito. Inoltre, prova a separare il codice che cambierà con il codice che rimane lo stesso. Il refactoring diventa più facile, perché il codice che non dovrebbe cambiare è più sicuro dal tuo futuro tu o qualcun altro.

Che ne dici di lasciare che il tuo istinto decida per una delle opzioni? Dovrebbe andare abbastanza veloce e combinarsi bene con il timeboxing , che anche AmmoQ ha proposto . Puoi provare un limite di 1 minuto se le opzioni sono già stabilite o 2 minuti se devi prima definirle. O qualunque cosa sembri appropriata (definita in anticipo). Quando impari ad ascoltare il tuo istinto, la tua scelta intuitiva diventerà più veloce e migliore con la pratica .

Nel caso in cui tu sia afflitto da preoccupazioni per la possibilità di scegliere non perfettamente, ecco alcuni pensieri per affrontarlo:

• Se ci fosse un'opzione con un margine netto rispetto agli altri, non ti chiederesti quale scegliere. Quindi, da quel ragionamento, ogni volta che non sei decisivo su una scelta su una questione non troppo complicata, ciò indica che le opzioni sono nel complesso abbastanza uguali; quindi non c'è molto da perdere semplicemente optando per uno di loro.
• Detto questo, l' intuizione non è affatto casuale, ma un'ipotesi piuttosto buona ed educata per la soluzione ottimale. Spesso meglio di quello che si sarebbe inventato attraverso un continuo rovistare.
• Per soddisfare il perfezionismo, quando si valuta semi-coscientemente la propria performance si può valutare la rapidità della decisione più dell'ottimalità della scelta. Il che ha perfettamente senso con scelte non importanti, ma non è banale da tenere a mente.

In bocca al lupo! :)

Penso che vada via con una piccola esperienza. La maggior parte della mia paralisi si verifica perché provo a immaginare quale sarà la base di codice molto più avanti di quanto sia necessario, quindi per superarla faccio solo la cosa più semplice possibile che funzionerà e poi proseguirò. Una volta che il progetto ha una forma definita, le unità di codice ripetitivo iniziano a emergere ed è abbastanza facile astrarre i modelli ripetitivi e semplificare il codice.

Per superare la tua riluttanza a decidere, applica il timeboxing : imposta una sveglia che si spenga in pochi minuti; tormenta la tua mente fino ad allora, ma quando suona la sveglia, scegli l'opzione migliore che hai trovato fino ad allora.

Crea un prototipo. Ricorda, un prototipo viene creato per essere gettato via, quindi non importa quali funzioni, nome di variabile o persino architettura generale usi. Lo stai solo costruendo per dimostrare che funziona.

Una volta che l'hai creato e buttato fuori, sarei disposto a scommettere che avresti un tempo più facile a prendere quelle decisioni.

Soffro anche di questo problema. Quello che direi è che non hai abbastanza incentivi per il completamento.

Ad esempio, quando stavo scrivendo il codice di rendering, ho avuto un grande incentivo per il completamento perché sapevo che se avessi avuto successo, avrei potuto vedere il sistema in azione e pensare a quanto fossi fantastico per la trama di un quad, o trasformando un vert. Ma ora che sto ri-factoring (tentativo 4, se vuoi sapere), allora sto soffrendo perché è un sacco di lavoro e anche se finisco, vedrò lo stesso vecchio quad. E davvero non voglio dover rifattare di nuovo e sono stufo di vedere lo stesso vecchio quad più e più volte, e non è più una ricompensa per me.

Devi scomporlo in componenti e ricompensarti per averli finiti, anche se è solo con qualche console i / o che mostra che funziona.

Stavo leggendo la tua domanda e pensando a cose simili a quelle degli altri poster: non sei adatto a questo lavoro; concediti un limite di tempo; fai qualcos'altro per un momento. Dopo qualche riflessione, non sono sicuro che nessuna delle risposte sia davvero così utile

Il problema con problemi mentali come questo è che non sono facili da risolvere, fanno parte di te e ovviamente ti preoccupi (troppo forse) del tuo lavoro, non hai la fiducia di essere d'accordo con te stesso, lo sono anche inesperto nel ritenere che la prima scelta sia stata giusta da sempre, oppure stressarsi troppo per farla diventare perfettamente giusta. Perché altrimenti ti preoccuperesti di queste banalità ?!

Ora ho problemi simili, ma non con il codice così tanto .. di solito è cosa avere per cena .. pizza o curry .. hmm ... pizza ma poi il curry è carino, ma mi sento come un curry, la pizza è più economica , ma poi ottieni più curry, ma ... e così via. :)

Quindi ho pensato: perché non ho problemi simili con la programmazione, e penso che sia semplicemente perché ho una serie di schemi che uso regolarmente. Se ho bisogno di una definizione di funzione, è facile ... sarà nella stessa vena di ogni altra definizione di funzione che abbia mai codificato. Se ho bisogno di un flusso di controllo, per prima cosa decido se ho bisogno di un ciclo for o di un ciclo while e quindi creare lo stesso vecchio codice che ho usato l'ultima volta che avevo bisogno di una di queste cose. Lo stesso vale per tutto, voglio una coda? Certo: andiamo a tagliare e incollare il mio codice di coda "standard" (cancellato dall'ultimo progetto a cui ho lavorato, o da qualcuno che ricordo di aver usato una di queste cose). Risultato finale ... mi preoccupo solo di cose nuove, e ad essere sincero, è un piacere.

Quindi, il mio consiglio è di iniziare a costruire una libreria di frammenti di codice - ero solito inviarli via email a me stesso e metterli in una cartella, ma qualunque cosa tu lavori meglio è - e allora inizierai a sapere cosa fare ogni volta. Passerai sempre al vecchio codice che hai scritto e toglierai il problema, pronto per il prossimo problema. Scoprirai di diventare uno sviluppatore molto più veloce (sul serio, questo è l'unico modo per aumentare la produttività del programmatore) e speriamo di trovare il tempo per i pezzi divertenti, non per le cose quotidiane lugubri che hai già risolto molte volte al di sopra di.

Certo, anche l'ultima parte di tutto ciò che è importante - più lavoro hai, meno lusso devi passare il tempo a pensare.

Ecco una strategia che combina i suggerimenti di Rein Henrichs ( inizio semplice, refactor ) e ammoQ ( timeboxing ):

1. Concediti un limite di tempo piuttosto rigoroso per una prima soluzione che funziona. Ad esempio 30 secondi per un nome variabile. Potresti prima trovare qualcosa di simile x, quindi perfezionarlo string, quindi namefino allo scadere del tempo.
2. Quindi passare ad altre attività per un determinato periodo di tempo, ad esempio 10 minuti.
3. Solo allora concediti un'altra finestra temporale per migliorare ulteriormente la tua decisione, ad esuserHandle

Possibili vantaggi di questo approccio:

• la conoscenza di tornare a questo in seguito potrebbe facilitare il rilascio del problema per ora
• mentre continui altre attività, potresti semplicemente trovare una buona soluzione soddisfacente senza perdere tempo a rovistare
• dopo aver lasciato andare il passaggio 1 ed essere nel flusso del passaggio 2 , può essere facile mantenere il passaggio 3 davvero rapido, poiché si desidera continuare con il passaggio 2, e quindi felicemente basta scegliere una soluzione decente e accettarla

Quando ho fatto la ricerca e non mi è stata data la migliore scelta chiara, mi concedo un limite di tempo (di solito 5 minuti) per sceglierne uno, quindi vado avanti. Anche quando incontri ostacoli, a questo punto non c'è garanzia, non avresti colto un ostacolo uguale prendendo una decisione diversa. Non riesco a pensare a una volta in cui mi sono pentito della mia decisione.

Di solito il motivo per cui non puoi decidere è che la differenza è insignificante o non hai abbastanza informazioni.

Nel caso a) Impostare un limite di tempo per elaborare opzioni ragionevoli da considerare. Non decidere quale ancora. Alla fine del tempo, scegli una delle opzioni identificate (a caso se non chiaramente preferibile) e un altro limite di tempo. Se non viene presa una decisione chiara alla fine dei tempi, quella già scelta è. Inizia la codifica e refactoring se hai chiaramente sbagliato. Se il capo chiede perché, dì "Ho lanciato una moneta, hai un modo migliore?"

Nel caso b) - hai bisogno di ulteriori informazioni e ti stai seduto sul tuo grosso grasso A .... tutto il giorno non lo fornirà. Esci dalla modalità di progettazione e passa alla modalità di raccolta delle informazioni. Prototipi, porre domande, leggere riviste tecniche. Qualunque cosa tu faccia, non dormirci troppo a lungo.

Spesso, la soluzione migliore è provare a spiegare la tua decisione a un collega. Tuttavia, poiché non vuoi farlo molto spesso, la cosa migliore da fare è pensare sulla carta - con una carta / penna o una finestra di blocco note vuota.

Inizia scrivendo assolutamente qualsiasi cosa - solo per entrare nel ritmo della scrittura. In una finestra di blocco note puoi semplicemente digitare "Sto pensando sulla carta" e poi continuare con un flusso di coscienza. Dopo alcuni secondi sarai al ritmo della scrittura, quindi premi Invio alcune volte e inizia a spiegare il tuo dilemma.

Indica il problema, quindi indica le possibili soluzioni, cosa c'è di buono in ognuna, ecc.

Anche se non sempre funziona, il processo di estrarre pensieri dalla tua testa (RAM) e su supporti esterni (il documento del blocco note) ti dà più libertà di fare nuove connessioni e visualizzare la decisione da diverse prospettive.

Soffro dello stesso problema. Per piccoli problemi, il modo in cui cerco di affrontarlo è quello di seguire il primo progetto che penso non sia stupido. Non ha senso cercare di trovare un design ottimale; è difficile, se non impossibile, ragionare su tutte le sfumature di qualsiasi disegno a cui potresti pensare senza scriverlo. Mentre codifichi, scoprirai che puoi apportare piccoli miglioramenti. Fatto bene, trovo abbastanza facile convergere su una soluzione ragionevolmente buona in questo modo.

Per problemi più grandi, penso che ci sia merito nel pensare prima attraverso le tue opzioni, ma cronometra. I grandi problemi hanno grandi spazi di soluzione, non puoi valutare ogni possibilità, né dovresti provare.

TLDR; Scegli una soluzione ragionevole, migliorala mentre procedi.

Questo è anche rilevante:

L'insegnante di ceramica ha annunciato il giorno di apertura che stava dividendo la classe in due gruppi. Tutti quelli sul lato sinistro dello studio, ha detto, sarebbero stati valutati solo in base alla quantità di lavoro che hanno prodotto, tutti quelli a destra unicamente in base alla sua qualità. La sua procedura era semplice: l'ultimo giorno di lezione portava le sue bilance da bagno e soppesava il lavoro del gruppo "quantità": cinquanta libbre di pentole valutavano una "A", quaranta libbre una "B" e così via. Coloro che venivano valutati in base alla "qualità", tuttavia, dovevano produrre solo una pentola - sebbene perfetta - per ottenere una "A".

Bene, sono arrivati ​​i tempi di valutazione ed è emerso un fatto curioso: le opere di alta qualità sono state tutte prodotte dal gruppo in base alla quantità. Sembra che mentre il gruppo "quantità" stava sfornando impegnato pile di lavoro - e imparando dai propri errori - il gruppo "qualità" aveva teorizzato sulla perfezione e alla fine aveva poco più da mostrare per i suoi sforzi di grandiose teorie e un mucchio di argilla morta.

da http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html .

Non l'ho mai capito. Quando ero un istruttore, dicevo qualcosa del tipo:

"OK, create an integer variable and assign the return value of strlen() to it."

Non troppo complicato, potresti pensare, e il 95% delle persone ha scritto qualcosa del tipo:

int x;   // or y, or len, or whatever
x = strlen( s );

Ma a volte ce n'era uno che sedeva come un coniglio paralizzato dai fari. Vorrei chiedere simpaticamente quale fosse il problema e avrebbero detto "Non so come chiamarlo!".

Queste sono le persone che dovrebbero cercare un'altra carriera. Come forse dovresti.