Come devo pianificare e avviare un progetto?

Ogni volta che avvio un progetto, decido in momenti cruciali di cambiare completamente le classi principali e rimanere invischiato in errori oscuri. Provo a pianificare in anticipo e di solito inizio con un buon piede, ma poi ci vado un altro giorno e decido che mi piacerebbe farlo "in un altro modo".

Esiste una sorta di standard quando si avvia un progetto come mappare le classi e iniziare con i test unitari? Qual è una buona convenzione durante la pianificazione e l'avvio di un progetto medio.

L'ultimo progetto avviato è stato un simulatore di movimento proiettile - lo so, prevedibile.

Quando pianifichi, non pianificare in anticipo ogni cosa possibile sull'applicazione. Pianifica a piccoli passi. Qual è la funzionalità minima assoluta necessaria per iniziare a utilizzare l'applicazione? Inizia lì.

Quando si avvia il progetto, codificare solo la funzionalità minima assoluta. Quando lo codifichi, assicurati di scrivere codice pulito e buono con incapsulamento intelligente . Ciò ridurrà al minimo gli errori che derivano dall'apportare modifiche in un secondo momento.

Passa alla funzionalità minima fino a quando non ne sei soddisfatto. Quindi inizia ad aggiungere nuove funzionalità e miglioramenti, uno alla volta. Ancora una volta concentrati sulla scrittura di codice buono e pulito con incapsulamento intelligente.

Se pianifichi in piccoli passi e scrivi un codice pulito, minimizzerai il numero di modifiche che devi effettivamente apportare. Dopo aver finito di scrivere quella prima funzione, avresti dovuto adottare gli schemi su cui si baseranno le basi della tua applicazione. Se ci sono problemi con quella base, le prossime funzionalità dovrebbero rivelare rapidamente il problema. Sarà più facile vedere come il pezzo si integri insieme. Le modifiche apportate dovrebbero, a questo punto, causare minime interruzioni.

Sembra che la tua pianificazione non ti aiuti. Non è una sorpresa perché non hai abbastanza esperienza per fare un piano fattibile. La soluzione è semplice Smetti di pianificare così tanto. Accetta semplicemente che stai per scrivere e riscrivere il codice mentre procedi. Va bene, perché il codice è gratuito, tranne che per il tuo tempo. Se stai scrivendo un'applicazione UI, inizia con una finestra vuota e aggiungi un po 'alla volta fino a quando non hai finito. Quando avrai più esperienza, i tuoi progetti andranno più veloci. Preoccuparsi perché stai cambiando codice è come uno studente di musica preoccuparsi di tutte le note sprecate in pratica.

Nessuno sa davvero quale sarà il miglior design fino a quando non ne avrà codificato una certa quantità. Pertanto, il segreto per una buona progettazione è riconoscere che la prima bozza è inevitabilmente non ottimale e pianificare di riscrivere porzioni più piccole prima e più frequentemente . Invece di eliminare un programma quasi completo, riscrivi righe o funzioni o classi non appena riconosci le loro carenze.

I programmatori di buona esperienza di solito non riescono a farlo bene anche sulla prima bozza. Ciò che viene fornito con l'esperienza è la capacità di riconoscere prima un cattivo design e la capacità di riscrivere più rapidamente.

Nella mia esperienza, questo problema scompare quando si ha più esperienza, si ha un'idea di cosa funziona e cosa no. Inoltre, un buon incapsulamento può ridurre i costi di modifica del design. Quanto più incapsulati sono i moduli, tanto più economico è cambiare in seguito. Consideralo un'ottima motivazione per tenere separate le tue lezioni.

http://nathanmarz.com/blog/suffering-oriented-programming.html

Questo risolve il tuo problema. Ha iniziato semplicemente assicurandosi che il software fosse possibile, prototipandolo e creandolo. Quindi, inizia a prendere il codice e a romperlo. Quindi, lo ottimizza.

Esistono due aspetti nella progettazione di un'applicazione. Il primo è decidere cosa può fare l'applicazione. Il secondo è progettare come farlo. Le modifiche a ciò che fa sono piuttosto significative e in base alla maturità dell'applicazione (e al cambiamento di direzione dell'applicazione) sono meglio affrontate come una riscrittura piuttosto che una rielaborazione.

Il secondo aspetto è il come. Utilizzando test unitari e pratiche di sviluppo agili, è possibile ridurre al minimo l'impatto del cambiamento su come una funzione specifica viene eseguita attraverso il refactoring. Parte dell'apprendimento di come sfruttare tali tecniche è la pratica pratica pratica.

Darò il consiglio che ho dato più volte. Scegli un progetto per animali domestici. Scrivilo al meglio delle tue capacità. Scopri qualcosa di nuovo e applica ciò che hai appreso per migliorare il modo in cui approcci lo sviluppo di quel progetto.

Ad esempio, inizia con un elenco di Todo. Semplifica ... non preoccuparti nemmeno dell'archiviazione del database all'inizio. Fallo funzionare. Ora inizia a costruire su quella base. Forse vuoi imparare MVVM e WPF ... sai già come implementare la todo list in memoria, quindi hai un problema in meno da risolvere. Ora vuoi farlo dove più utenti possono caricare le loro liste di cose da fare da un database. Hai risolto in memoria e una presentazione separata, così puoi concentrarti sull'apprendimento dei dati di accesso. Da lì puoi espandere l'applicazione in modo da avere un modello di dominio più complesso (ad esempio passando da un elenco Todo a una soluzione di gestione del progetto), un'interfaccia web o persino eseguirlo su un dispositivo mobile. La chiave per fare questo lavoro è scegliere qualcosa che è realizzabile da te su cui puoi segnare i progressi e che puoi crescere nel tempo.

Nella mia esperienza, la progettazione del sistema spesso richiede più o meno tempo rispetto alla codifica effettiva. Quando dici "pianificando in anticipo" cosa pianifichi realmente? Magari vai alla vecchia scuola e usa una delle metodologie di progettazione collaudate. Oppure vai alla vecchia scuola e scrivi lo pseudo codice prima di scrivere il vero codice.

Penso che devi chiederti perché stai cambiando le cose nei momenti cruciali piuttosto che attenersi al piano originale. Il piano originale era difettoso? O hai avuto un momento perspicace che ha mostrato un modo migliore di fare le cose. In realtà era meglio o semplicemente diverso?

Man mano che guadagni exp dovrai riscrivere / graffiare e ricominciare, meno spesso. Scrivi il problema che stai cercando di risolvere. Annota le vaghe descrizioni delle lezioni che ritieni necessarie, annota come sarà necessario interagire. Prendi un'idea di come funzionerà tutto, quindi codifica. Non perdere tonnellate di tempo scrivendo ogni proprietà, metodo delle tue lezioni. A questo punto stai cercando di ottenere una visione di 50K piedi di ciò che dovresti fare. Una volta che inizi a scrivere codice se devi scrivere più dettagli, procedi. Altrimenti inizia a scrivere codice.

Il motivo per cui lo trovi così difficile è che hai un'idea, ma in realtà non hai un'idea completa di ciò che vuoi che faccia. Se stai facendo il tuo progetto e non hai un cliente che ti dica quello che vuole, allora tocca a te essere il tuo cliente. Mettiti nei panni del cliente e inizia a costruire una lista dei desideri impossibile.

In altre parole, quando inizi Non progettare NIENTE !!! .

Una volta che hai una grande lista di cose che vuoi che il sistema faccia, dai la priorità a tutto e decidi quale sarà la funzionalità minima per avere un sistema base in esecuzione. Potrebbe trattarsi di una singola funzione di base o di un intero schermo, ma deve essere qualcosa che senti, poiché il cliente sarà abbastanza utile da testare.

Quindi, Lista dei desideri di funzionalità + priorità di base = Requisiti .

Una volta che hai tutto questo, fai un design di altissimo livello. Siediti e pensa a ciò di cui il tuo sistema avrà bisogno per mettere in funzione le prime priorità. Cambia idea se lo desideri, ma qui è dove potresti voler aggiungere un po 'di codice o una configurazione di sistema per saperne di più su ciò che è possibile. Vai solo abbastanza lontano per convalidare la tua idea di base di un design.

Vale a dire: ORA puoi soddisfare le sollecitazioni dei tuoi designer .

Una volta fatto, inizi a implementare le tue funzionalità. Crea per ogni caratteristica una specifica funzionale di base. Questo potrebbe essere semplice come una raccolta di dichiarazioni di funzionalità. Carte delle storie se vuoi. Ciò ti consente di sviluppare un po 'la tua idea nella tua mente e di creare una serie di dichiarazioni che diventeranno le specifiche su cui testerai e costruirai la tua implementazione.

Cry Havoc, lascia che i cani di ... Code !!

Da lì, implementa i tuoi test in modo che corrispondano alle tue specifiche, quindi per ogni test scrivi il tuo codice. Costruisci, "rilascia", quindi ripeti con la funzione successiva fino a quando decidi che il progetto non è abbastanza completo.

Dipende davvero dall'esperienza, ma questo approccio che ho trovato è una formula semplice per aiutarti a focalizzare la tua mente su ciò che deve essere fatto, piuttosto che rimanere bloccato in un ciclo infinito di procrastinazione a causa del tentativo di fare troppo una volta.

Dopo aver eseguito le nozioni di base come stabilire gli obiettivi del progetto, ottenere l'elenco dei requisiti e bloccare tutte le interfacce verso i sistemi esterni.

Quindi è necessario fare un caso d'uso o "storia" per ogni interazione dell'utente. Sono stati scritti dei volumi su ciò che rende un "buon" caso d'uso o storia e ci sono molte varianti. I casi d'uso sono il singolo strumento di progettazione più efficace che abbia mai incontrato. Aiutano a raccogliere funzionalità mancanti allo stesso tempo eliminando i requisiti non necessari e riducono il design ai suoi elementi essenziali. Come ho detto, le metodologie variano ma la maggior parte dei professionisti concorda su:

• testo inglese semplice e conciso.
• "Goal Driven" funziona meglio, ad es. "La scimmia prende un acino d'uva" è meglio del "bottone rosso".
• vietare la terminologia tecnica. Nessun "pulldown", "caselle di testo". Un buon caso d'uso dovrebbe essere indipendente da qualsiasi tecnologia di interfaccia. Dovresti essere in grado di prendere un caso d'uso per un sistema basato su HTML e utilizzarlo per un sistema ad attivazione vocale senza alcuna modifica al caso d'uso stesso. (Questo è molto difficile da fare ma ne vale la pena!).
• Cerca di ridurre del 50% il numero di parole della tua prima bozza, sbarazzandoti di passaggi e verbosità inutili.

Quindi sei pronto a specificare le tue classi principali:

UML - Universal Modeling Language. È lo strumento standard per la progettazione di classi. È possibile specificare i membri pubblici e i metodi di ciascuna classe e collegarli insieme in un modello grafico chiaro e conciso.

In combinazione con diagrammi di sequenza, modelli di dati, è possibile verificare e migliorare il proprio progetto prima che avvenga qualsiasi codifica.

Sposta la tua attenzione sul risultato che desideri ottenere e sopporta i potenziali guadagni dell'apprendimento / del tentativo di nuove implementazioni con il rischio di percorrere una strada che ti riporta al punto di partenza.

Nel caso in cui finissi al punto di partenza, non tutto è perduto perché hai acquisito esperienza.

Se hai una scadenza (sembra che tu stia programmando per divertimento), allora è davvero complicato. Se vai continuamente in una direzione, rischi di usare metodi obsoleti col passare del tempo. Se vai continuamente dall'altra parte, rischi le conseguenze della produzione di output a un ritmo più lento (un tasso variabilemente più lento a seconda dei risultati delle tue avventure di apprendimento).

Ero abituato al lavoro, facevo le cose velocemente anno dopo anno, e poi un giorno mi sono reso conto che stavo diventando non corrente nella mia gamma di competenze.