Come partizionare un problema in più comprensibile parti?

Question

Io non sono sicuro se è possibile dare dei consigli su questo argomento, ma si prega di provare.È difficile spiegare il mio caso perché è troppo complesso da spiegare.E questo è esattamente il problema.

Mi sembrano costantemente inciampare in una situazione in cui cerco di progettare qualche parte del mio progetto, ma ha tante cose da prendere in considerazione che io sono in grado di ottenere una comprensione di esso.

Ci sono suggerimenti o consigli su come guardare il mio sistema in piccoli pezzi alla volta?Come trovare le più piccole parti che possono essere progettate separatamente sul loro?

Answer 1

I tuoi obiettivi principali sono:

• Alta coesione : Codice (metodi, campi, classi) all'interno di un pezzo / modulo / partizione dovrebbero interagire intensamente; dovrebbe avere senso per questi elementi di conoscere l'altro. Se si scopre che alcuni di loro non interagire molto con il resto, probabilmente appartengono stare altrove o dovrebbero formare la propria partizione. Se si trova il codice di fuori interagire intensamente con la partizione e sapendo troppo circa il suo funzionamento interno, probabilmente appartiene al suo interno. L'esempio tipico è trovato nel codice OO scritto in stile procedurale, con oggetti di dati "stupidi" e il codice "manager" che opera su di loro, ma in realtà dovrebbe essere parte degli oggetti di dati.
• Accoppiamento lasco : Interaction tra pieces / moduli / partizioni dovrebbe avvenire solo attraverso API strette, ben definite, ben documentati. Cercate di identificare tali API e vedere quale codice è necessario per la loro attuazione e che il codice li utilizzerà.

Answer 2

Creazione di un glossario.

In altre parole, identificare i termini che sono significative per il progetto di dominio, non il programmatore punto di vista, ma da un utente, che abbia familiarità con la materia.

Quindi definire i termini come proprio e discretamente come si può.Una buona definizione in questo modulo può servire come una sorta di pseudocodice.

Dal momento che non hai specificato anche il dominio del problema, scelgo un esempio al caso.In una personale civile di sistema, si potrebbe avere termini come:

• billet:un termine del servizio (dalla data di inizio alla data di fine) in un particolare grado e scatto
• dipendente:una serie di billette associato con un particolare SSN
• grado e scatto:di riga e di colonna federale generale pianificazione

E così via.Questo non è per identificare le unità funzionali, come si suona come si sta cercando di fare, ma è un buon passo di preparazione prima di farlo, in modo che tu possa esprimere il tuo funzionale passaggi ben definiti termini.

Answer 3

E 'utile per affrontare problemi di decomposizione sia top-down e bottom-up.

Se hai problemi a dividere un grande problema in due o problemi più piccoli, prova a pensare di più piccole possibili problemi che dovranno essere risolti. Una volta che quelli sono gestiti, si può iniziare a vedere il modo di combinarli in problemi più grandi, come ci si avvicina alla grande problema originale.

Answer 4

Quando mi ritrovo copiando e incollando pezzi di codice con aggiustamenti minimi mi rendo conto che è una "partizione" e quindi creare una classe, metodo, la funzione, o qualsiasi altra cosa.

In realtà, l'approccio orientato intero oggetto è ciò che è interamente circa. Provate a pensare della vostra applicazione, come cose tangibili che fanno roba. Scrivi pseudo codice che descrive ciò che le cose sono e cosa fanno, trovo un sacco di "partizioni" in questo modo.

Answer 5

Ecco una prova, una sorta di supposizione.

La gente di solito sottovaluta quanto tempo ci vorrà loro di fare il lavoro. Se il progetto è grande, allora molto probabilmente avrete bisogno di più persone di lavorare su di esso, in modo da poter provare a programmare con questo in mente. Ora, una persona può essere previsto per contenere una sola area in testa, quindi avrai bisogno di spiegargli esattamente che tipo di compito che si suppone di fare.

Quindi direi si dovrebbe cercare di dare una descrizione del lavoro che dovrebbe comprendere il più possibile per una persona di concentrarsi seriamente su. Ripetere, finché non si è rotto il vostro progetto in parti si voleva. Come un vantaggio, si è pronti per assemblare la tua squadra. Ma se si scopre le parti sono piccole, forse sarete ancora in grado di farlo da soli.