Come organizzare un progetto individuale? [chiuso]

Ogni tanto (leggi: ogni giorno circa) mi viene in mente una nuova idea, inizio un nuovo progetto nel mio editor / IDE preferito, inizio a scrivere codice e il giorno dopo lo cancello e inizio qualcosa di nuovo. Sto programmando da circa sei anni e in quei sei anni ho davvero completato solo un progetto molto piccolo (un widget Dashboard per Pastebin.com). Anche se questo potrebbe essere ottimo per l'apprendimento del codice, voglio davvero completare qualcosa.

Quali sono alcune cose che dovrei fare prima, mentre e dopo l'effettiva codifica? Quali sono le buone risorse che mi insegnano come organizzare tali progetti personali?

Se è importante, voglio fare sviluppo Web o Mac.

Penso che il vero problema, a lungo termine, sia la motivazione, piuttosto che l'organizzazione.

1. Trova utenti e parla con loro. Visualizza il tuo progetto come una sorta di regalo (o prodotto vendibile) per quelle persone. (Anche qualcuno con cui far rimbalzare le idee è fantastico, anche se in realtà non sviluppa codice con te.)

   Avere quella motivazione sociale sarà enormemente più potente nel mantenere il progetto interessante a lungo termine rispetto alla semplice curiosità personale.

2. Il tuo obiettivo dovrebbe essere piccoli pezzi di piccole dimensioni di funzionalità utili. Mettilo su SourceForge o GitHub e tratta il progetto come qualcosa che ha bisogno di una possibilità di sopravvivenza anche se improvvisamente sei colpito da una meteora.

   Questo porta a un numero maggiore di rilasci (che significa più feedback ed entusiasmo da parte degli utenti) e anche una maggiore probabilità che un'altra persona possa decidere di contribuire al progetto.

3. Scegli un obiettivo di apprendimento specifico per te stesso. Quale tecnologia o tecnica ti aiuta a imparare il progetto? Se si scopre che la tecnica non è adatta all'area problematica, ti interesserà abbastanza per finire almeno la versione 1.0 prima di metterla da parte?

   Esempi di tali obiettivi includono la scrittura di parser, protocolli di rete, aspetti dell'IA di gioco, framework di apprendimento o toolkit, una nuova lingua, ecc.

Lo scenario peggiore significa che mancano tutti e tre, in cui si esegue ripetutamente una "riscrittura di massa" di uno strumento mai rilasciato che coinvolge codice che non si trova interessante per le persone di cui non si è sicuri.

Quando ti viene in mente un'idea per un nuovo progetto mentre lavori su un progetto, annotalo in un elenco di idee progettuali. Quindi torna al progetto corrente. Se il progetto vale la pena, non lasciarti distrarre da un nuovo progetto. Utilizzare i passaggi seguenti solo se si tratta di un'idea eccezionale.

Prima di iniziare il nostro progetto, pianificalo. Che cosa farà? Quanto sarà difficile fare? Quali sono i noti e gli sconosciuti? Cosa potrebbe andare storto? Quanto tempo ci vorrà? [Ora puoi decidere se andare avanti o fermarti ora.] Mantieni il tuo piano. [Se stai lavorando a un progetto, metti da parte il nuovo progetto e vai avanti con l'altro progetto originale.]

Quando si avvia il progetto, impostarlo come progetto separato nell'IDE. (Quindi non è necessario eliminarlo per avviare il prossimo progetto.) Effettuare il check-in in alcuni software di controllo versione come nuovo progetto. (Ora puoi eliminarlo se lo trovi ostacolare un altro progetto.) Controlla il tuo progetto ogni volta che hai fatto qualcosa di corretto. (Ora puoi tornare indietro se esci di pista.)

Tieni traccia dei problemi che sorgono nel tuo progetto. Questo può essere fatto con alcuni file di testo all'interno del progetto. File come TODO, Changelog, README (possono includere bug e problemi noti) potrebbero essere appropriati.

Quando il tuo codice funziona, taggalo nel controllo della versione. Se vale la pena condividerlo, fallo.

Torna al tuo piano e guarda quanto hai fatto bene. Fai un documento sulle lezioni apprese per te stesso. Cosa hai imparato, quanto hai stimato? Quali problemi ti sei perso? Quali problemi hai sopravvalutato? Qualsiasi altra cosa tu ritenga importante.

Quando si abbandona un progetto, seguire le lezioni apprese. Aggiungi una nota sul perché hai abbandonato il progetto.

Rivedi le tue lezioni apprese circa una volta al mese. Col passare del tempo è possibile aumentare l'intervallo tra le recensioni.

Ecco un link a " Fare Agile in una squadra di uno ". È una lettura interessante!

Inoltre, potresti voler considerare perché le discipline degli sviluppatori di software che facciamo "al lavoro" sono importanti. Sono importanti solo se ci sono 10 persone nella squadra? No, sono importanti perché ti aiutano a pensare al tuo progetto.

chi è il tuo pubblico di riferimento? (Se sei tu, allora fantastico - ma ricorda a cosa volevi originariamente l'app)

Se stai eseguendo un'interfaccia utente, pensa alle esigenze del tuo pubblico, quindi esegui alcuni prototipi prima di entrare nello sviluppo dell'interfaccia utente hard core.

Se stai osservando la tua logica aziendale, prova TDD o BDD. Pensa a come vuoi che la tua app funzioni prima di attaccarla. Considera di avvolgerlo in un'imbracatura come Fitnesse o simili. Se vuoi testare la tua app, il punto più semplice da cui iniziare è all'inizio .

Dato il tuo commento, smetti di eliminare i tuoi progetti!

In genere non mantengo progetti che non sto attivamente sviluppando (o prevedo di sviluppare attivamente nel prossimo futuro) sul mio computer, ma i file di origine esistono in un repository SVN e tutto il backup (inclusi i file di configurazione IDE) viene eseguito il backup un HDD esterno. Non risponde a questiStop, eliminando il tuo lavoro e concentrandoti sulla motivazione.

Se stai cercando un repository ospitato, guarda Google Code, SourceForge, GitHub e BitBucket. Carica i tuoi file, conservali da qualche parte e, quando hai un rinnovato interesse, abbattili. Anche se puoi renderli privati, puoi renderli pubblici se non ti vergogni di loro. Forse qualcuno sarà interessato a riavviare il tuo lavoro o apprendere dai tuoi esempi (specialmente se stai utilizzando una libreria o un framework interessante).

Nel tempo, lavora sulla tua motivazione. Cerca di concentrarti su una cosa alla volta. Potresti non ottenere il tuo codice per la qualità della produzione, ma forse puoi ottenerlo come esempio di qualità, o qualcosa che altre persone possono guardare per vedere il tuo set di abilità, conoscenze o per conoscere un particolare modo di fare le cose.

Prima di tutto, ci sono progetti e progetti. Se provi qualche tecnologia o libreria, o altro, probabilmente crei un progetto nel tuo IDE, scopri se questa cosa ti interessa o no, quindi elimina il tuo progetto. Va bene, lo fanno tutti.

Un altro tipo di progetto è il vero software / siti / ecc., Che è business, in cui quei "progetti", file, programmi sono solo strumenti e lo sviluppo di cose così complesse richiede motivazione e obiettivi :

• cosa sviluppi (sito web / editor di testo / app mobile / ...)
• a cosa ti serve (fare soldi, raccogliere alcune nuove tecnologie / contribuire all'open source / ...)
• quando faresti (quanto tempo dedichi al tuo progetto, per quanto tempo pensi di farlo)

Ciò che sviluppi dovrebbe essere nuovo . Se vuoi creare solo un altro editor di testo perché ritieni che manchi qualche funzione richiesta, probabilmente non devi farlo. Esistono centinaia di strumenti open source, che contribuiscono a uno di questi.

Anche se crei un piccolo strumento monouso come uno script, dovresti indicare quelle cose elencate, sarebbe più facile risolvere il problema stesso.

Se sei bloccato a scrivere codice (ad esempio, riscrivere in modo massiccio il tuo codice) probabilmente non hai abbastanza esperienza per farlo. Prendi un buon libro sull'ingegneria del software, sulla tua piattaforma (mac / web / ecc.), Leggi il codice scritto da sviluppatori più esperti che fa cose simili. Ora ci sono molti posti dove farlo (github, codice google, blog di programmazione, stackoverflow).

Non cercare di risolvere un problema molto complesso (ad es. Scrivere un compilatore o un sistema operativo) da zero, prima di tutto scomponilo in attività più piccole, per lo più spesso, qualcuno ha già creato librerie che ti aiutano a risolvere il tuo problema.

Hai mai pensato di chiedere a una persona cara ciò di cui aveva veramente bisogno per un webtool, e poi farlo davvero per lui?

Questo dovrebbe fornire la motivazione per finire e consegnare, che è la parte difficile in questo. Inoltre ottieni il vantaggio di supportare e mantenere l'applicazione se è utile alla persona amata. Se non è utile, puoi imparare dall'esperienza cosa può andare storto.