Il modo migliore per pianificare un'attività?

Question

Dato che sono molto nuovo alla programmazione, sono molto curioso di apprendere i modi migliori/le pratiche di programmazione.

Ogni volta che voglio scrivere un programma, inizio direttamente con la codifica mentre alcuni dicono che è necessario pianificare il programma prima di iniziare il codice.

Ma non capisco il vero valore della creazione dei diagrammi di classe e di tutto quel genere di cose coz Penso che alla fine devo scrivere il codice.

Ragazzi, potete condividere le vostre esperienze su come state programmando? Voglio dire qual è il tuo primo passo quando avvii un'applicazione?

Answer 1

A volte un compito di grandi dimensioni è scoraggiante che può persino rendere "solo la codifica" senza pianificazione impossibile, in quanto non si sa da dove iniziare. Mi ricordo che anni fa mi sono sempre bloccato per anni cercando di lavorare su qualcosa di nuovo, perché ero cresciuto in posizione in cui il mio compito principale era quello di apportare miglioramenti - non avevo esperienza di lavorare con una tela bianca. Era paralizzante, incapace di impegnarsi in un approccio perché potrebbe essere una scelta progettuale non ottimale.

Ma in ogni caso, in questi giorni tendo a sedermi con la carta e a scorrere il disegno.

Se è grande, inizierò a delineare come alcune parti funzioneranno separatamente e alla fine questi pezzi si uniranno. Cerco di trasformarlo in classi o moduli e poi scoprirò che ci sono ridondanze nel design, o c'è qualcosa che semplicemente non funziona. Così ricomincio, scriverlo con un approccio migliore ... e scoprire altri problemi. Continuo a ripetere, ottenendo una migliore comprensione del problema ad ogni sweep. (Le lavagne possono essere utili per farti andare su e giù, essere fisico mentre risolvono questioni spinose.)

Quando ho un disegno psuedocode/diagramma di flusso che è abbastanza dettagliato che non ha problemi evidenti - è così che inizio la codifica.In un ambiente formale, lo schizzo definitivo del progetto è ciò che vorrei trasformare in una specifica e distribuire agli utenti/sviluppatori per la revisione.

Spesso, con un design complicato, io trasformare questo abbozzo di disegno in commenti di guidarmi come codice che ho, che è più veloce e più preciso di dover consultare i miei appunti ogni 2 secondi:

// open file 
// read header line 
// check header is right (watch for int problem) 
// select right config object 
// loop over lines, read each line into config object 

E Converto ogni commento in codice.

Questo è molto più efficiente della codifica in un vicolo cieco e dover scrivere e riscrivere semplicemente perché non si è riusciti a gestire il problema dall'inizio. Ciò non significa che il design non cambierà più - troverai comunque dei problemi - ma alcuni dei principali bug di progettazione possono essere eliminati prima di colpire l'IDE.

Ci sono molti approcci al design, questo è proprio ciò che funziona per me. Ciò che è meglio può variare in base al tipo di progetto e alle dimensioni del team.

Answer 2

Sono un fan di CRC Cards.

CRC sta per Classe, Responsabilità, Collaborazione. Si utilizza una serie di cartoline, in cui ogni scheda rappresenta una classe e elenca di cosa è responsabile e in che modo collabora con altre classi.

Dato un elenco di funzionalità e/o un set di casi d'uso, le carte CRC facilitano l''"esecuzione" delle varie funzioni del software, assicurando che le classi esistano per eseguire le azioni necessarie e che le relazioni tra quelle classi esistono per consentire loro di lavorare insieme correttamente.

Answer 3

Sto utilizzando qualcosa come le "CRC Cards" di vita reale - Prendo solo pochi fogli di carta e una penna e inizio a disegnare le classi, i loro metodi e tutte le loro dipendenze. Gli altri documenti vengono utilizzati per informazioni più dettagliate sulla funzionalità.

Answer 4

Se sei nuovo alla programmazione, quindi inizia con le nozioni di base: Imparare a programmare. Scrivi alcuni piccoli "hello world" programs ed espandi le tue conoscenze a siti Web o applicazioni Windows. Impara a scrivere programmi che soddisfino le tue esigenze. Se non si hanno requisiti, scriverli prima di iniziare, altrimenti il ​​programma non avrà una linea di arrivo.

Quando ti senti pronto per affrontare progetti più grandi, puoi utilizzare la classe e il design dell'oggetto utilizzando UML e impara test-driven development per scrivere più codice solido. Ulteriori informazioni sulle diverse metologie di sviluppo, come Agile e Scrum. I progetti più grandi richiedono pianificazione e buoni progetti, quindi è necessario conoscere le proprie teorie.

Answer 5

Non essere bloccati sui diagrammi delle classi ecc., Lo scopo principale per dedicare un po 'di tempo a pensare a ciò che si vuole fare è essere in grado di organizzare la propria applicazione in un prodotto robusto. Quando ti siedi e pensi in anticipo come fare alcuni casi di utilizzo su ciò che il tuo programma dovrebbe fare in modo efficace guardando da un'altra angolazione in modo da poter trovare cose che non sono così ovvi. Una questione di astrazione

Se si avvia direttamente la codifica, spesso si finisce col ritrovarsi nei dettagli dell'implementazione e si può dimenticare l'obiettivo di creare una soluzione molto stretta e fragile.

Un po 'come ti fai strada nella giungla dalla A alla B e sei esausto buttati a terra quando arrivi lì, hai quindi creato un percorso da A a B ma quello che volevi veramente era una strada ben preparata da a a B.

Answer 6

Due punti con la pianificazione e la preparazione sono:

• per assicurarsi che voi e la quota di clienti la stessa visione del problema.
• Per esporre potenziali problemi con la tua idea su come risolvere il problema.

Come si fa dipende dalla situazione, ma il punto è quello di realizzare i due punti sopra modo più economico possibile. Disegna schizzi, discuti, crea un prototipo low-fi, create a pilot system.

Answer 7

Se si vuole scrivere un programma buona, in particolare quello che si potrebbe desiderare di cambiare e migliorare in seguito, allora sarà vale la pena fare un po 'di progettazione prima di immergersi in scrittura di codice.

"Creare diagrammi di classe e tutto quel genere di cose" è davvero solo un modo di scrivere su carta ciò a cui stai già pensando: quali classi hai bisogno, quali dati archiviano e come si relazionano le classi l'un l'altro. Non devi seguire alcun processo formale - trovo che scatole e frecce grezze funzionino perfettamente per organizzare i miei pensieri.

Mentre trascorro più tempo con un programma, in genere trovo che trovo alcuni modi migliori di organizzare i dati o migliorare le relazioni tra le classi. Quando ciò accade, il punto cruciale è che è molto più facile e veloce scribacchiare e ridisegnare alcune caselle piuttosto che buttare via un file di 200 righe scritto in C++ accuratamente debugato e ricominciare.