Gestione dei progetti personali come sviluppatore autonomo - Esaurimento di progetti in profondità e in mancanza [chiuso]

Aveva lo stesso identico problema:

Se avessi messo da parte il mio progetto per qualche giorno, sarei tornato a farlo e avrei avuto difficoltà a riprenderlo. Avevo dovuto ri-familiarizzarmi con esso, provare a ri-capire dove andava il mio treno dei pensieri ea volte chiedermi perché mai ho deciso di programmarlo come ho fatto finora. Molto spesso questo mi fa semplicemente abbandonare il progetto o riavviarlo da zero. Tutto ciò è diventato un vero problema quando ho capito che la situazione mi ha costretto a:

1. avvia solo progetti piccoli e semplici. Avviare un grande progetto mi porterebbe oltre la soglia di confusione in cui non potrei più riprenderlo dopo averlo lasciato da solo per qualche giorno

2. se volevo davvero fare qualcosa di più complesso e complesso avrei dovuto fare tutto in "una sola seduta", cioè lavorare su di esso tutti i giorni fino a quando non è stato fatto senza pause

Questo era solo stressante. Ho deciso che prima di continuare a realizzare progetti personali da solista dovrei cercare di risolvere questo problema.

Ho iniziato di proposito progetti complessi, solo per vedere esattamente perché stavo avendo difficoltà a riprenderli dopo una pausa di pochi giorni. Avrei iniziato a implementare un algoritmo con cui non avevo familiarità fino ad allora (come A * o Mini-max, ecc.), Interrompere la codifica nel mezzo di tutto e provare a terminarlo alcuni giorni dopo.

Ecco alcune delle mie conclusioni su questo:

• tutto monolitico è male . Fai piccole funzioni / metodi concisi, classi, pacchetti, moduli. Non mai, non una volta, tagliamo gli angoli su questo, pensando "oh dai, aggiungerò solo il codice draw.sprite alla funzione updateGameState() questa volta solo, quanto può essere cattivo" o "I" semplicemente aggiungiamo questa funzione calculateArea direttamente nella classe SelectButtonWidget , solo per una volta, sarà molto più veloce di una classe separata e un'istanza per essa ". Questo rende il codice difficile da seguire e quindi difficile da riprendere dopo alcuni giorni di pausa, quando non ricordi più tutti gli "alias mentali" che hai appena fatto "tutto il codice di disegno si trova nel pacchetto drawables tranne quello per disegnare uno sprite che si trova nella funzione updateState() della classe X del pacchetto Y ".

I test unitari

• rendono il codice molto più leggibile dei commenti Hai, per disperazione, aggiunto "pagine e pagine" di commenti al tuo codice nella speranza che sia più leggibile la prossima settimana quando riprendi il tuo progetto dopo essere tornato dalle vacanze? So che l'ho fatto. Mai aiutato Non solo non rendeva il codice più leggibile (a volte lo rendeva meno, in quanto non mi aiutava a capire di nuovo cosa stava facendo il mio codice mentre allo stesso tempo riordinava il mio codice), ma richiedeva MOLTO di tempo di aggiungere commenti ovunque. Anche questo porta a simili enigmi come "faccio commenti a livello di classe, metodo / livello di funzione, per ogni riga di codice, solo per quelli importanti, ecc. Ecc.". Investire tutti i commenti sul tempo di scrittura in test unitari è stato molto meglio. I test unitari verificano qualcosa, e puoi facilmente capire che cosa stanno controllando e quindi cosa dovrebbe fare il codice. Inoltre, l'enigma "dove inserire i commenti" era scomparso. Unit test di tutto. Inizia con qualsiasi cosa tu pensi sia più importante, ma fai un obiettivo di testare l'unità su qualsiasi cosa.

• unit test just rock Non solo il tuo codice è più leggibile e più facile da (ri) capire, non avrai nemmeno bisogno di (ri) capire tutto quando torni ad esso, ma solo quelle aree su cui vuoi lavorare al momento. Basta dare un'occhiata ai test unitari delle parti del codice che vuoi modificare in questo momento per vedere cosa dovrebbero fare esattamente. Quindi modificali, aggiungi ulteriori test di unità, se necessario, ed esegui di nuovo l'intera batteria di test dell'unità per assicurarti di non aver rotto nulla. Se passano tutti, sai immediatamente che tutto va bene con il tuo codice, senza doverlo esaminare a mano.

• non ottimizzare mai fino alla fine Nel grande schema di tutto questo, questo punto è discutibile . Il mio codice verrà eseguito più rapidamente se ritardare il più possibile le ottimizzazioni o se le eseguo in modo incrementale mentre implemento le cose? Onestamente non lo so. Ma rigorosamente dal punto di vista della leggibilità del codice e di quanto sia facile riprendere un progetto dopo averlo messo da parte per un po ', sono abbastanza sicuro che la pratica di ritardare l'ottimizzazione fino alla fine è il modo migliore per andare. Ciò che intendo è: fino a quando la tua implementazione non è vicina alla realizzazione, concentrati su un codice bello, leggibile e modulare. Una volta che la funzionalità è tutta in, debug, unità e test funzionali, è possibile ottenere il compito di ottimizzare il codice. Avrai una bella versione del tuo codice che sei sicuro che funzioni, ed è chiara e facile da leggere, e alla quale puoi sempre tornare se il refactoring ai fini dell'ottimizzazione ti dà problemi.

Proprio dalla pura prospettiva del prodotto, vorrei chiedere qual è la logica alla base della creazione di tali progetti? Qual è l'obiettivo finale che cerchi di raggiungere?

Se lo fai per hobby, allora direi che probabilmente non hai una buona motivazione e motivazione per fare quei progetti (annoiarsi ecc.). E se non c'è una chiara comprensione del perché uno fa alcune cose, è molto difficile aspettarsi che questo sia coinvolgente per un lungo periodo di tempo.

Se lo fai per soldi, personalmente consiglierei seriamente di dare un'occhiata al tuo modello di business e sosterrei che ci sono inefficienze che devono essere superate. Ogni azienda o prodotto ha bisogno di un gruppo di persone diverse per avere successo, ci sono buoni eserciti per un solo uomo, ma molto raramente.

Sento che il problema qui è più generale e non può essere risolto con un semplice adattamento a nuovi strumenti o metodologie di sviluppo.

In qualche modo tangente, ma trovo che avere progetti personali dello stesso tipo che faccio al lavoro (ad esempio lo sviluppatore di Rails di giorno, i progetti personali di Rails di notte) possa portare a un maggiore rischio di esaurimento, affaticamento e solo totale riluttanza a lavorarci sopra.

Concentrarsi sulle parti che sono diverse (ad esempio l'interfaccia utente o le cose del server) può aiutare con la motivazione che penso, piuttosto che fare "solo più dello stesso".

Per me la soluzione non è avviare grandi progetti. Invece faccio un piccolo progetto e lo sviluppo.

Potrebbe non essere pubblicabile dopo il primo passaggio, ma su ogni passaggio ha qualche stato conosciuto, elenco di miglioramenti futuri, potrebbero essere alcuni piani.

La motivazione può influire sul tempo che trascorro, ma il codice e altre cose (piani, bug, funzionalità) dovrebbero essere mantenuti in uno stato che permetta di continuare facilmente dopo almeno un mese di ritardo (il ritardo di un anno richiederà probabilmente un aggiornamento ).

But then pride kicks in, and I don't feel at one with a project I haven't completed myself. Does this make sense?

Qual è la tua motivazione per questi progetti? Divertimento? Apprendimento? Allora forse ha senso, così potresti discutere che impareresti a lavorare con gli altri. Realmente fare una cosa finita o obiettivi aziendali? Quindi assolutamente non ha senso. Trova un modo per superarlo.