Avanzamento con Iterazione del codice

Il mio consiglio è di non rimanere "bloccato" nel cercare di trovare il modo migliore per fare qualcosa. Fallo e basta! Potrebbe totalmente succhiare, ma la linea di fondo è che hai ancora fatto qualcosa. Niente trionfi esperienza ... quindi fallo e impara dai tuoi errori.

In realtà, scrivendolo nel modo sbagliato e poi dover tornare indietro e rielaborarlo può essere una buona esperienza di apprendimento. Possiamo stare seduti tutto il giorno e pensare sul modo migliore per implementare la funzione, ma non sarà quasi altrettanto informativo come in realtà scrivere il codice e osservare come funziona.

Quindi vai con la tua prima idea e vedi come funziona. Scopri cosa è giusto e cosa c'è che non va. Quindi puoi rielaborarlo o riscriverlo se necessario; sarà più facile la seconda volta perché hai esperienza.

Direi di scrivere un test di accettazione (BDD / TDD) per confermare che la funzione è completa e quindi scrivere la soluzione più semplice possibile e quando si tratta di volte al refactoring hai la conferma dell'accettazione che non lo hai rotto

Questo è lo stesso problema che ho avuto. È un disturbo di personalità. Sto tentando di iscrivermi alla filosofia Sit down and do it . È difficile, in quanto risulta in alcuni refactoring. MA, nello stesso tempo in cui non avrei potuto fare nulla ("pensando"), ho realizzato qualcosa e ho spostato lo sviluppo in avanti.

Questo di solito accade quando le specifiche non sono correttamente enunciate. Poiché siamo single-developers , definiamo le specifiche e abbiamo troppe opzioni. Basta inchiodarne uno (il primo che viene in mente) e seguirlo.

Ho avuto molte volte in cui mi sono costretto a sedermi e ad implementare l'Opzione 1, solo per rendermi conto (dall'effettivo utilizzo dell'opzione 1), che è una cattiva opzione. Ho dovuto scartare tutte le modifiche e ricominciare. Ma non avrei mai potuto saperlo a meno che non l'avessi implementato (o avrei potuto indovinare come e dove andrà male in futuro - molto difficile senza specifiche strette e una sfera di cristallo.) Ma in Nel frattempo ho programmato qualcosa e so che il risultato non funzionerà. Vs. spendendo quel giorno pensando e realizzando nulla.

Inoltre, se sei sovraccarico di lavoro, non confonderlo con "pensare" a una soluzione. Se hai bisogno di riposarti dalla programmazione e dal ciclo di sviluppo, prenditi una pausa. Non fare alcun pensiero attivo. Basta scrivere un breve da fare / "cosa stavo pensando" prima di prendere la pausa del giorno. Impostare un allarme in pochi giorni per iniziare il backup e programmare l'Opzione 1. Refactor. Scartare. Opzione 2. Avanti.

Due strategie: 1) lavorare su altre parti del progetto mentre si dà quella volta per "spezzare". 2) Scrivi qualcosa con cui puoi convivere, anche se potrebbe essere non ottimale. Preferisco la prima di solito, ma a volte decido di vivere con quest'ultima, almeno per un breve periodo. Spesso, soprattutto dopo che gli utenti giocano un po 'con le cose, risulta che l'intera area generale ha bisogno di una revisione sufficiente che la direzione generale che stavo pensando sarebbe migliore è del tutto irrilevante.

Io faccio Cerco di evitare di scrivere codice finché non sembra perfetto. Una volta ho realizzato che quasi ogni progetto personale (se è abbastanza grande) è destinato a un'evoluzione senza fine, così ho deciso di concentrarmi sulla creazione di una libreria di classi utili: animatore, sottosistema degli eventi personalizzati, alcuni ui, wrapper per riprodurre contenuti ecc. da quel momento ogni volta che ho bisogno di implementare qualsiasi cosa - nuove funzionalità o progetti - scrivere un nuovo codice e creare nuove entità arriva insieme all'evoluzione della mia amata lib. Dal modo in cui ho intenzione di condividerlo quando lo considero perfetto;)

Come qualcuno ha detto, Just Do it - Avrai problemi e sfide, ma continui ad andare avanti, ogni giorno implementa funzionalità molto piccole e vedi che funziona, questo ti darà molte e molte motivazioni per andare avanti.

Ho bisogno di vedere qualche successo, non importa se è anche piccolo, per tenermi motivato e in movimento.

Non mollare mai.

Scrivi un'implementazione semplice / ingenua che funzioni. Roba di codice duro se necessario. Controlla il codice Quindi rifattalo per renderlo più bello. Oppure, se ti piace, scrivi alcuni test prima di refactoring.