Come novizio, come posso superare al meglio la complessità dei progetti più grandi?

6

Attualmente, sono uno studente e posso affrontare tutti i miei compiti che richiedono solo 3-5 lezioni da implementare. Ora, sto cercando di sviluppare programmi su una scala più ampia, ma sto attraversando un momento davvero difficile per capire come progettare il programma da un livello superiore.

L'esempio del mondo reale su cui sto lavorando è un progetto di gruppo per costruire un lettore RSS. Fin qui tutto bene e ho un prototipo di base che funziona utilizzando un framework RSS più alcune classi che ho creato io stesso. Usando il prototipo come esempio e il documento dei requisiti (ben oltre 50 requisiti, per ora) ho bisogno di costruire il programma vero e proprio. Sento di conoscere molti principi, ma non sono sicuro di come applicarli a contesti diversi come questo.

Sono impiccato su come rompere questo semplice lettore RSS in più componenti, classi, ecc. e cosa dovrebbero essere anche quelli. Mi piacerebbe davvero sapere come posso / dovrei andare a chiudere la testa attorno a questo progetto. Voglio essere in grado di fare un passo indietro e visualizzare i diversi pezzi del programma in modo da avere una struttura prima di scrivere qualsiasi codice.

I complimenti extra se hai un link a un articolo o blog che mostra in realtà, ad esempio, come puoi prendere un concetto e scomporlo a un livello elevato. Una sorta di articolo di tipo "dal concetto alla produzione" invece di solo informazioni astratte disponibili in siti come SourceMaking .

    
posta Pete 18.06.2011 - 05:38
fonte

7 risposte

14

Progettare l'architettura del tuo progetto è il vero compito e sicuramente ti hanno insegnato i principi generali, o vogliono che tu impari da solo, praticando.

Ad ogni modo, un primo approccio potrebbe essere:

  1. Studia le tue specifiche.
    1. Sottolinea i nomi specifici in blu. Sono probabilmente le tue classi / oggetti / proprietà.
    2. Sottolinea i verbi specifici in rosso. Sono probabilmente i tuoi metodi principali.
    3. Sottolinea gli aggettivi specifici in verde. Sono probabilmente i tuoi limiti.
  2. Scrivi ogni parola identificata nella sua casella (post-it).
  3. Sposta quelle caselle su una dashboard bianca.
    1. Le caselle correlate dovrebbero rimanere vicine l'una all'altra.
    2. Disegna linee tra le caselle per vedere le relazioni.
    3. Aggiungi note (post-graffate) alle caselle.
  4. Ad un certo punto ti renderai conto che hai bisogno di un nuovo set di scatole.
    1. Disegnali mentre guardi quelli nella dashboard.
    2. Aggiungi proprietà alle caselle graffate nel punto in cui appartengono.
    3. Scatta una foto della dashboard.
    4. Rimuovi le vecchie scatole e conservale in una borsa, per ogni evenienza.
  5. Ripeti da 3 fino a quando non ti piace quello che hai sul cruscotto.
risposta data 18.06.2011 - 12:31
fonte
4

Scrivere programmi su più larga scala è come scrivere programmi su scala più piccola. Hai solo più lezioni, tutto qui. Per risolvere un problema più grande, suddividilo in parti più piccole e gestisci i pezzi individualmente utilizzando classi separate.

Penso che il modo migliore per iniziare il processo di apprendimento di affrontare grandi progetti sia lo studio di schemi di progettazione. , in particolare i schemi strutturali. I modelli strutturali sono utili per organizzare raccolte di classi in una struttura organizzativa più ampia.

Puoi anche studiare pattern come Model-View-Controller e architettura multipla.

    
risposta data 18.06.2011 - 06:38
fonte
3

A meno che non si lavori su uno di essi, è abbastanza difficile immaginare nuovi sistemi complessi. Detto questo, ho un piano di 3 giorni per imparare in un posto nuovo. Funziona, e se un nuovo incarico / lavoro si può iniziare ad essere rapidamente produttivo. Fondamentalmente, è importante ottenere il quadro generale.

Scopri tre cose, dedicando 1 giorno a ciascuna delle seguenti

  1. Layout di sistema : è molto importante conoscere il layout fisico dell'infrastruttura. Scopri i diversi server e i loro attributi, ambienti operativi, etc., essenzialmente tutto ciò che riguarda l'infrastruttura.
  2. Schema del database : scopri come vengono archiviati i dati dell'applicazione. Chiedete in giro e scoprite i dati più importanti (tabella / vista / relazione ...) Questo è il modo migliore per conoscere il business.
  3. Architettura generale : informazioni sui componenti importanti dei sistemi e su come sono incollati insieme.
risposta data 18.06.2011 - 07:40
fonte
2

Ci sono molti modi per affrontare questo programma, ma qualunque cosa tu faccia, non iniziare senza avere una chiara idea di dove stai andando. Nella tua risposta al mio commento, tu dici che

we have started doing all the requirements and documentation including various diagrams. I know what the program should do but I am not sure how to separate that into classes, methods, etc.

Non mi preoccuperei troppo di questo. Quello che devi fare come primo passo è essere veramente certi del "flusso" del tuo sito. Pensare prima in termini di usabilità, quindi abbozzare i processi in background come se si stesse progettando una macchina. Non lasciare che le lezioni e le pratiche di codifica ti fermino in quella fase.
Quando quella parte è finita, dovresti essere in grado, con l'aiuto di alcuni documenti, di spiegare ai programmatori e ai novizi in che modo tutto funziona, sia dal punto di vista del front-end che dal punto di vista algoritmico. Se non puoi, allora non è abbastanza chiaro. Tornaci.

Quando questa parte è terminata, viene eseguito il 50% della progettazione del codice. Da lì in poi, ci sono molti modi per andare. Ad esempio, è possibile elencare tutte le funzionalità (funzionalità) necessarie, tutti gli archivi di dati (database, filesystem, xml ...) e tutti i moduli front-end e vedere quali collegamenti con ciò che è più naturalmente possibile. Da lì, vedere quali sono le caratteristiche comuni e creare classi madri e vedere quali funzioni devono essere aggiunte nelle sottoclassi. Prestare particolare attenzione a quali dati immettono una funzione e quali dati la lasciano, e assicurarsi che le funzioni correlate funzionino bene insieme.

Personalmente sono un fan di che ottiene segnali reali di 37 (è assolutamente da leggere se non lo conosci ). Quello che fanno è progettare l'interfaccia prima e poi andare da lì. Aiuta a concentrarsi su ciò che conta davvero e controlla ad ogni passaggio che il flusso è buono.

La mia variazione personale su questa tecnica è la seguente: scrivo prima il mio codice finale. Questo mi aiuta a capire cosa vorrei che facessero i miei corsi. Se il mio codice diventa troppo complesso, allora lo cambio al volo (non fa nulla comunque, non ho ancora creato una singola classe) e inizio all'implementazione delle funzionalità.
Questo è in qualche modo simile a sviluppo basato sui test , anche se più semplice da avviare, perché ha bisogno di 0 preparazione.

E infine, anche se le buone pratiche di codifica sono un must, e sono assolutamente d'accordo che dovrebbero essere utilizzate a tutti i costi, ma non rendono l'errore del principiante di essere ostacolato da loro. Ciò che conta è che il codice funzioni, soprattutto. Quindi tieni a mente tutte le cose buone che hai imparato, ma non stressarti troppo e immergiti semplicemente. Il design iterativo è il modello migliore (almeno per piccoli gruppi). Costruisci qualcosa che funzioni e ottimizza in seguito (prova comunque a mantenere un livello minimo di pulizia o non sarai in grado di ottimizzare affatto).

Spero che ti aiuti.

[modifica] Ho dimenticato di dirlo: se non lo sei già, usare un sistema di subversion può far risparmiare un sacco di mal di testa a lungo termine. Bitbucket offre repository privati ed è abbastanza facile impostare mercurial su linux & Windows (non so di Apple, ma suppongo sia altrettanto facile)

    
risposta data 18.06.2011 - 12:00
fonte
1
  • abitudine. Avere abitudini significa che quando ti chiedi cosa hai fatto, sai che lo hai fatto nel solito modo per capire cosa hai fatto. Come dove hai messo quel file.

  • Un computer. Fai tutto ciò che lavori su un computer; preferibilmente un notebook puoi prendere posti. In questo modo, ogni volta che fai qualcosa, hai accesso a tutto ciò che hai sempre fatto.

  • sottodirectory. Le sottodirectory sono meravigliose per conservare progetti, fonti, versioni, dati di test, ecc.

  • Copia. Idealmente quando scrivi un nuovo programma, metà del codice può essere copiato da un vecchio programma che hai scritto in precedenza.

  • Test. I tre segreti dell'affidabilità sono test, test e test.

  • Se le cose diventano troppo complesse, considera un sistema di controllo della versione del codice sorgente. Non lo uso perché lavoro sempre e non desidero eseguire il backup di una versione precedente della mia fonte. Ma per i progetti che coinvolgono più persone è fondamentale.

  • Archivio. Memorizza "Quel programma da tre anni fa.zip" su un CD.

risposta data 18.06.2011 - 09:13
fonte
1

Non sono d'accordo con tutto ciò che è stato scritto qui, mentre sto scrivendo un brain-dump in forma schematica con caratteristiche generali, scenari ecc., che è l'estensione del lavoro sulle specifiche che devi veramente fare.

Il modo più semplice per scrivere un programma complesso è semplicemente scriverlo e assicurarti di rifattorici mentre vai avanti. Ogni volta che aggiungi una nuova funzione / aspetto del programma, scrivi una piccola app separata per testare e sperimentare con quella parte e poi integrarla nell'app principale.

Man mano che la tua applicazione cresce, inizierai a vedere temi, schemi e divisioni logiche comuni nel tuo codice, ti ritroverà senza pietà a separare la tua app in questi e a ridurre complessità e dipendenze. Meno dipendenze, più facile è capire una parte del tuo codice ed è anche più facile scrivere piccoli programmi di test per quella parte del codice.

La cosa principale è sempre quella di fermarsi a intervalli regolari e chiedersi: "Il codice sta diventando troppo complicato? Come posso risolverlo?" e poi rifai il codice come avresti fatto da zero se poi sapessi cosa fai ora.

    
risposta data 20.06.2011 - 09:20
fonte
0

Credo di aver sofferto per troppo tempo dello stesso dilemma ... Immagino sempre dove andare dopo. Penso che quello che mi mancava fosse una documentazione ad es. ERD corretto, Diagramma di flusso dati e Documenti di progettazione come Casi di utilizzo / Storie || Diagrammi di sequenza del sistema ...

Un software con la corretta ingegnerizzazione e documentazione dei requisiti non subisce uno scenario del genere a mio parere personale.

Hai preparato abbastanza per la tua applicazione prima di saltare sulla parte di codifica .... ???

    
risposta data 20.06.2011 - 05:46
fonte

Leggi altre domande sui tag