Come devo pianificare e avviare un progetto?

Quando pianifichi, non pianificare in anticipo tutte le cose possibili sull'applicazione. Pianifica in piccoli passi. Qual è la funzionalità minima assoluta devi iniziare a utilizzare l'applicazione? Inizia lì.

Quando avvii il tuo progetto, decidi solo la funzionalità minima assoluta. Quando lo decidi, assicurati di scrivere codice buono e pulito con incapsulamento intelligente . Ciò ridurrà al minimo gli errori derivanti da modifiche successive.

Iterate su quella funzionalità minima finché non 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 l'incapsulamento intelligente.

Se pianifichi piccoli passi e scrivi codice pulito ridurrà al minimo il numero di modifiche che devi effettivamente apportare. Quando hai finito di scrivere quella prima caratteristica, dovresti aver adottato i modelli su cui si baseranno le fondamenta della tua applicazione. Se ci sono problemi con quella fondazione, le tue prossime caratteristiche dovrebbero rivelare rapidamente il problema. Sarà più facile vedere come i pezzi si integrano insieme. Le modifiche apportate dovrebbero, a questo punto, causare interruzioni minime.

Sembra che la tua pianificazione non stia aiutando. Non è una sorpresa perché non hai abbastanza esperienza per fare un piano fattibile. La soluzione è semplice. Smettila di pianificare così tanto. Accettate semplicemente che scrivete e riscrivete il codice mentre procedete. Va bene, perché il codice è gratuito, tranne che per il tuo tempo. Se stai scrivendo un'applicazione per l'interfaccia utente, inizia semplicemente con una finestra vuota e aggiungi un po 'alla volta finché non hai terminato. Quando hai più esperienza, i tuoi progetti andranno più velocemente. Preoccuparsi perché stai cambiando codice è come uno studente di musica che si preoccupa di tutte le note sprecate nella pratica.

Nessuno sa veramente quale sarà il miglior design finché non ne avrà codificato una certa quantità. Pertanto, il segreto del buon design è riconoscere che la prima bozza è inevitabilmente subottimale e pianificare di riscrivere le porzioni più piccole in precedenza e più frequentemente . Invece di scartare un programma quasi completo, riscrivi linee o funzioni o classi non appena riconosci le loro carenze.

Normalmente, i programmatori esperti non riescono a capire bene la prima bozza. Ciò che viene fornito con l'esperienza è la capacità di riconoscere un cattivo design prima 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, una buona incapsulamento può ridurre i costi di modifica del design. Più i moduli sono strettamente incapsulati, più è conveniente cambiare in seguito. Consideralo un'ottima motivazione per tenere separate le tue lezioni.

link

Questo indirizzo il tuo problema. Iniziò semplicemente assicurandosi che il software fosse possibile, prototipandolo e crearlo. Quindi, inizia a prendere il codice e lo scioglie. Quindi, lo ottimizza.

Ci sono due aspetti nella progettazione di un'applicazione. Il primo è decidere cosa può fare la tua applicazione. Il secondo sta progettando come farlo. Le modifiche a ciò che fa sono piuttosto significative e, in base alla maturità dell'applicazione (e allo spostamento di direzione dell'applicazione), viene meglio affrontata come riscrittura piuttosto che rielaborazione.

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

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

Ad esempio, inizia con un elenco di cose da fare. Rendilo semplice ... non preoccuparti nemmeno dell'archiviazione del database all'inizio. Basta farlo funzionare. Ora inizia a costruire su quella base. Forse vuoi imparare MVVM e WPF ... sai già come implementare la lista di cose da tenere in memoria, quindi hai un problema in meno da risolvere. Ora vuoi farlo dove più utenti possono caricare le loro liste da un database. Hai risolto in memoria e separato la presentazione, così puoi concentrarti sull'apprendimento dell'accesso ai dati. Da lì è possibile espandere l'applicazione per disporre di un modello di dominio più complesso (ad esempio passando da un elenco di cose da fare 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 sia realizzabile da parte tua, che puoi contrassegnare i progressi e che puoi crescere nel tempo.

Nella mia esperienza, il design del sistema spesso richiede più tempo o più a lungo della codifica attuale. Quando dici "pianificando in anticipo" cosa stai pianificando? Magari vai a scuola vecchia e usa una delle metodologie progettuali collaudate. O vai a scuola vecchia e scrivi lo pseudo codice prima di scrivere il codice vero e proprio.

Penso che devi chiederti perché stai cambiando le cose in momenti cruciali invece di 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 / grattare e ricominciare, meno spesso. Annota il problema che stai cercando di risolvere. Scrivi descrizioni vaghe di classe che pensi di aver bisogno, scrivi in che modo avrà bisogno di interagire. Ottieni un'idea di come funzionerà tutto il codice allora. Non spendere un sacco di volte a scrivere ogni proprietà, metodo delle tue lezioni. In questa fase stai cercando di ottenere la vista del piede 50K di ciò che dovresti fare. Una volta che inizi a scrivere codice, se hai bisogno di scrivere più dettagli, vai a farlo. Se non solo inizia la codifica.

Il motivo per cui lo trovi così difficile è che hai un'idea, ma 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 cosa vogliono, allora spetta 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 NULLA !!! .

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 minima funzionalità per far funzionare un sistema base. Potrebbe trattarsi di una singola funzione di base o di uno schermo intero, ma deve essere qualcosa che senti, dal momento che il cliente sarà abbastanza utile da testare.

Quindi, lista dei desideri delle caratteristiche + priorità di base = Requisiti .

Una volta che hai tutto ciò, fai un disegno di altissimo livello. Basta sedersi e riflettere su ciò che il tuo sistema avrà bisogno per far funzionare le prime priorità. Cambia idea se lo desideri, ma qui è dove potresti voler aumentare il 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.

I .: ORA ottieni indulgere i tuoi designer .

Una volta terminato, inizi a implementare le tue funzionalità. Crea per ciascuna funzionalità una specifica funzionale di base. Questo potrebbe essere semplice come una raccolta di dichiarazioni di caratteristiche. Story card se ti piace. Ciò ti consente di sviluppare la tua idea nella tua mente un po 'e di creare una serie di affermazioni che diventeranno la specifica che testerai e svilupperai la tua implementazione.

Cry Havoc, lascia scivolare i cani di ... Codice !!

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 finché non decidi che il progetto è abbastanza completo.

Si tratta davvero di esperienza, ma questo approccio che ho trovato è una semplice formula per aiutarti a focalizzare la tua mente su ciò che deve essere fatto, piuttosto che rimanere bloccato in un ciclo infinito di procrastinazione dovuto al tentativo di fare anche tu molto in una volta.

Dopo aver eseguito le nozioni di base, come stabilire gli obiettivi del progetto, ottenere il tuo elenco di requisiti e bloccare qualsiasi interfaccia verso sistemi esterni.

Quindi devi fare un caso d'uso o una "storia" per ogni interazione con l'utente. I volumi sono stati scritti su ciò che rende un caso d'uso "buono" o una storia e ci sono molte varianti. I casi d'uso sono lo strumento di progettazione più efficace che abbia mai incontrato. Aiutano a cogliere le funzionalità mancanti allo stesso tempo di eliminare i requisiti non necessari e riducono il design al minimo indispensabile. Come ho detto le metodologie variano ma la maggior parte dei praticanti concorda su: -

• testo in inglese semplice conciso
• "Goal Driven" funziona meglio, ad esempio "La scimmia ottiene un'uva" è migliore di "Il pulsante rosso di Monkey Pushes".
• 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 utilizzare un caso d'uso per un sistema basato su HTML e utilizzarlo per un sistema a comando vocale senza modifiche al caso d'uso. (questo è molto difficile da fare, ma ne vale la pena!)
• Punta a ridurre il conteggio delle parole della prima bozza del 50%, sbarazzati di passaggi e frasi inutili.

Di quanto sei pronto a specificare le tue classi principali:

UML - linguaggio di modellazione universale. È lo strumento standard per la progettazione di classi. Specifica i membri pubblici e i metodi di ogni classe e li collega in un modello grafico chiaro e conciso.

Insieme ai diagrammi di sequenza, modelli di dati, puoi verificare e migliorare il tuo progetto prima che avvenga qualsiasi codifica.

Spostare l'attenzione sul risultato che si desidera ottenere e soppesare i potenziali guadagni di apprendimento / provare nuove implementazioni con il rischio di scendere lungo una strada che ti riporta indietro al punto di partenza.

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

Se hai una scadenza (sembra che tu stia programmando per divertimento) allora questo è davvero difficile. Se vai continuamente in una direzione, rischi di utilizzare metodi obsoleti con il passare del tempo. Se vai continuamente dall'altra parte, rischi le conseguenze della produzione di output a un ritmo più lento (una velocità variabile più lenta a seconda dei risultati delle tue avventure di apprendimento).

Ero solito esplodere nel lavoro, fare cose velocemente anno dopo anno, e poi un giorno mi sono reso conto che stavo diventando non corrente nel mio skillset.