Supponi di dover sviluppare un software di dimensioni medie +, completamente da solo. Come se fosse un progetto personale che vuoi realizzare.
Quali metodologie / strumenti useresti per definire ciò che deve essere sviluppato, imparato e avere un'idea globale di ciò che il sistema è anche nei suoi dettagli?
Fondamentalmente per tenersi in pista e non perdersi per strada.
Solitamente uso Mercurial, se voglio una funzionalità, la aggiungo e se non la voglio più la rimuovo. Inoltre, cerco di scrivere bene i miei commenti di commit in modo da non perdersi.
Potrebbe facilmente crescere oltre la portata della tua attenzione. Not the span , larghezza .
È difficile considerare troppi elementi contemporaneamente .
E poi ... diventa una regressione sulle montagne russe .
Tutto ciò che fai rompe le cose precedenti e il rollback non aiuta.
Per evitare che tu debba testare aggressivamente la regressione .
Automaticamente. (Non puoi farlo diversamente e rimanere sano di mente)
I test aggiungeranno uno sforzo difficile alle tue energie.
Se il progetto riguarda interamente l'interfaccia utente, probabilmente stai brindando:
Untested last minute idea for UI focused projects
Enroll a relative with spare time and a fondness of clicking his mouse as a UI tester.
I'm thinking "teenager" here.
Altri problemi:
Se hai usato e amato una specie di controllo di versione , usalo.
Iniziare a imparare distraiti .
Rappresentare graficamente le tue idee, come già sottolineato, può aiutarti.
Ho usato Freemind , CMaps , XMind , yEd , graphviz , e ... qualcos'altro.
XMind è il meno inutile:
Una matita e un taccuino sono ancora buoni nella mia top ten:
Rendo molti piccoli disegni esplicativi.
Come ultima risorsa, puoi sempre preparare powerpoints per il tuo consumo:)
Programmazione letterale.
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.
Se stai scrivendo un documento (o prenota o segnala o documenta) sul tuo progetto, allora tendi a rimanere in attività.
Inizia con uno schema di ciò che stai facendo: usa la panoramica dei casi, versione 1, versione 2, versione n. Annota un riassunto dei casi d'uso. Dai la priorità a loro. Falli coinvolgere in scatti e uscite.
Ogni versione ha una vista caso d'uso, vista logica, vista elaborazione, vista componente, vista di distribuzione. Per lo sprint, dettagli i casi d'uso. Pubblica il documento HTML per mostrare cosa stai per fare. Dopo aver dettagliato i casi d'uso per lo sprint, scrivere il modello logico. Scrivi il codice per supportare questo. Scrivi la documentazione di elaborazione. Scrivi il codice per supportarlo. Crea moduli. Scrivi la documentazione della vista del componente. Scrivi i test e la documentazione di supporto. Pubblica i risultati dello sprint come documento HTML.
Ripeti per ogni sprint. Rivedi e modifica il tuo documento di volta in volta.
Ci sono molti e molti strumenti di programmazione. Possono aiutarti a produrre una fonte che crei la e del codice della documentazione sia da un singolo testo.
Uso sfinge e PyLit ma è perché sono un programmatore Python.
Se vuoi scrivere le tue idee, puoi utilizzare uno strumento di mind mapping come XMind o FreeMind . Entrambi gli strumenti sono gratuiti (per gli utenti di XMind) e sono ottimi per il brainstorming e l'organizzazione delle tue idee. La cosa su questi strumenti è solo che hai meno possibilità di dimenticare qualcosa.
Personalmente ho usato Freemind prima di iniziare il mio ultimo progetto personale. Non avevo una particolare metodologia di per sé . Ho appena esposto le mie idee durante le sessioni di un'ora una volta ogni due giorni. Penso che la spaziatura tra le sessioni di brainstorming mi abbia aiutato a vedere meglio cosa c'era di sbagliato, cosa non era essenziale ma poteva essere utile nelle versioni successive, ecc.
Sul mio primo commit di codice ho anche salvato il file di brainstorming nel repository del codice sorgente (ho usato bitbucket ) e l'ho tenuto aggiornato appuntamento con le mie ultime idee.
Tratta come un vero progetto software (perché è uno). Ci sono solo alcune cose che cambiano perché il numero di sviluppatori è uno. Hai ancora bisogno del controllo del codice sorgente. Hai ancora bisogno di un modo per organizzare le funzionalità da aggiungere un bug da correggere. Hai ancora bisogno di test automatici per verificare di non creare regressioni nel codice. Dovresti anche avere un modo automatico per compilare il codice (se necessario), eseguire i test e visualizzare i rapporti.
Sto lavorando a un progetto personale proprio come hai descritto tu. Sto usando Git, Redmine, JUnit e Jenkins per soddisfare tutte le categorie che ho descritto. Il mio flusso di lavoro è:
Mantenere tutto gestito e organizzato è tanto importante quanto quando ci sono molti sviluppatori. Con molti sviluppatori, è necessario organizzarsi in modo che le informazioni siano diffuse a tutti. Quando sei solo tu, hai già tutte le informazioni, ma ricordare ogni parte del sistema è difficile. Un sistema gestito ti rende più facile per te e puoi concentrarti sull'attività da svolgere.
Strumenti:
Sistema di controllo versione (anche se si è l'unico sviluppatore nel proprio garage o in casa P.C.): GIT, Mercurial, Tourtoise
Editor con evidenziazione del codice sorgente, anche se disponi di un I.D.E. (Scintilla, Vim, Blocco note)
Lavagna del mondo reale, lavagna bianca, alcune cose non sono compatibili con l'applicazione Strumenti per designer.
Strumento di progettazione: Rational Rose, Umbrello, (U.M.L., E-R,) Visio o "Strumenti di progettazione per sviluppatori scadenti" come Power Point, Corel Draw, Open Office Draw
Strumento di confronto del testo codice sorgente / codice, ad es. WinMerge
Dipende da come puoi distinguere e gestire diversi compiti, perché dovrai dare un'occhiata a ogni singola fase del processo di sviluppo.
Penso che gli strumenti siano utili solo se sai già come usarli e uno dei peggiori errori è imparare a capire come funziona uno strumento piuttosto che imparare come utilizzarlo.
In primo luogo, a mio parere, devi annotare ciò che pensi che il software farà e specialmente ciò che non farà. Questo è un punto cruciale. Il passo successivo è dividere il sistema finale in sottosistemi inferiori, rendendo più facile il processo di costruzione. E, ultimo ma non meno importante, dovrai scegliere i tuoi strumenti. Fondamentalmente un buon IDE, un VCS e un modellatore di dati. Puoi aggiungere molti altri strumenti per aiutarti, ma fai attenzione a non iniziare sulla traccia sbagliata.
Bene, l'inizio non sembra così attraente, ma il processo diventerà divertente nel tempo.
Leggi altre domande sui tag methodology tools