Design e amp; Codifica - dall'alto verso il basso o dal basso verso l'alto? [chiuso]

Question

Quando si codifica, quale è nella tua esperienza un approccio migliore?

1. Suddividi il problema in pezzi abbastanza piccoli e quindi implementa ogni pezzo.
2. Suddividi il problema, ma implementalo utilizzando un approccio top-down.
3. Qualsiasi altro?

Answer 1

Ecco cosa faccio:

Comprendi prima il dominio. Comprendi il problema da risolvere. Assicurati che tu e il cliente (anche se quel cliente sei tu!) Siete sulla stessa pagina del problema da risolvere.

Quindi viene proposta una soluzione di alto livello al problema e da ciò il design si trasformerà in bolle o punti elenco in una pagina o altro, ma il punto è che si scuoterà in componenti che possono essere progettati.

A quel punto, scrivo test per le classi ancora da scrivere e poi perfeziono le classi per superare quei test.

Uso un approccio test-first e costruisco componenti funzionanti e testati. Questo è ciò che funziona per me. Quando le interfacce dei componenti sono note e le "regole" sono note per il modo in cui parlano tra loro e si forniscono reciprocamente servizi, allora diventa generalmente un semplice esercizio "aggancia tutto insieme".

È così che lo faccio, e ha funzionato bene per me.

Answer 2

Tendo a progettare top-down e implementare bottom-up.

Per l'implementazione, la costruzione dei pezzi funzionali più piccoli e il loro assemblaggio nelle strutture di livello superiore sembra essere ciò che funziona meglio per me. Ma, per il design, devo iniziare dal quadro generale e scomporlo per determinare quali saranno quei pezzi.

Answer 3

Potresti dare un'occhiata al Agile Manifesto . Le funzioni top down e bottom up sono basate sul design e sulla costruzione di Built It All At Once.

Il software "funzionante su documentazione completa" significa che la prima cosa che costruisci è la più piccola cosa utile che puoi avviare. Superiore? Parte inferiore? Né.

---

Quando ero più giovane, ho lavorato a progetti che, per contratto, erano rigorosamente dall'alto verso il basso. Questo non funziona Anzi, non può funzionare. Di conseguenza, ottieni montagne di design e codice ridondanti. Non è stato un approccio valido se applicato senza pensarci.

Quello che ho notato è che l'approccio Agile - piccoli pezzi che funzionano - tende a spezzare il problema in parti che possono essere colte tutte in una volta. Il top-down / bottom-up non conta più così tanto. In effetti, potrebbe non importare affatto.

Quali lead fanno: " Come si decompone per lo sviluppo Agile? " Il trucco è evitare di creare Una grande cosa che devi quindi scomporre. Se analizzi un problema, scopri che gli attori cercano di realizzare casi d'uso e falliscono perché non hanno tutte le informazioni, o non le hanno in tempo, o non possono eseguire le loro decisioni o qualcosa del genere.

Spesso, queste non sono grandi cose che necessitano di decomposizione. In tal caso, devi risolvere il problema nella direzione Obiettivi all'indietro . Dagli obiettivi alle cose che ti consentono di raggiungere quell'obiettivo alle cose che consentono agli attivatori, ecc. Poiché gli obiettivi sono spesso grandi cose, questo tende ad essere dall'alto verso il basso - dall'obiettivo generale di business al processo e al passo dettagliati.

Ad un certo punto, esaminiamo questi vari passaggi che conducono agli obiettivi. Abbiamo fatto la parte di analisi (scomporre le cose). Ora arriva la parte di sintesi: riassembliamo ciò che abbiamo in cose che possiamo effettivamente costruire. La sintesi è dal basso. Tuttavia, non lasciamoci trasportare. Abbiamo diversi punti di vista, ognuno dei quali è diverso.

Abbiamo un modello. Questo è spesso costruito dai dettagli in un modello concettuale più ampio. Quindi, a volte decomposto nuovamente in un modello normalizzato per OLTP. O scomposto in uno schema a stella normalizzato per OLAP. Quindi eseguiamo il backup per creare una mappatura ORM dal modello normalizzato. Su - Giù - Su.

Abbiamo elaborazione. Questo è spesso costruito dai riassunti dei processi aziendali nei dettagli delle fasi di elaborazione. Quindi il software è progettato attorno ai passaggi. Quindi il software è suddiviso in classi e metodi. Giù - Su - Giù.

[ Digressione . Con gli utenti illuminati, questa scomposizione definisce nuovi titoli di lavoro e modi di lavorare. Con utenti non illuminati, i vecchi lavori rimangono e noi scriviamo montagne di documentazione per mappare i vecchi lavori su nuovi software.]

Abbiamo componenti. Spesso guardiamo i pezzi, guardiamo quello che sappiamo sui componenti disponibili e facciamo una sorta di abbinamento. Questo è il processo più casuale; è simile al modo in cui si formano i cristalli - ci sono centri di nucleazione e il tipo di design si solidifica attorno a quei centri. Servizi web. Banca dati. Gestione delle transazioni. Prestazione. Volume. Diverse funzionalità che in qualche modo ci aiutano a scegliere i componenti che implementano alcune o tutte le nostre soluzioni. Spesso sembra bottom-up (dalla funzionalità al prodotto), ma a volte top-down (" sto tenendo un martello, chiamo tutto un chiodo " == uso l'RDBMS per tutto.)

Alla fine dobbiamo codificare. Questo è dal basso verso l'alto. Tipo. Devi definire una struttura del pacchetto. Devi definire le classi nel loro insieme. Quella parte era dall'alto in basso. Devi scrivere metodi all'interno delle classi. Lo faccio spesso dal basso verso l'alto: analizzo il metodo, scrivo un test unitario, finisco il metodo. Ruota il metodo successivo, scrivi un test unitario, finisci il metodo.

Il principio guida è Agile: crea qualcosa che funzioni. I dettagli sono su tutta la mappa: su, giù, davanti, dietro, dati, processo, attore, area tematica, valore commerciale.

Answer 4

Sì. Fai tutte queste cose.

Può sembrare sarcastico (scusate, torno alla forma), ma questo è davvero un caso in cui non c'è una risposta giusta.

Answer 5

Anche in modo agile, scrivi prima i tuoi test!

Quindi tutto il software è un ciclo continuo di

• Rosso: il codice non supera il test
• Verde: il codice supera il test
• Refactor: miglioramenti del codice che preservano l'intenzione.

difetti, nuove funzionalità, modifiche. Tutto segue lo stesso schema.

Answer 6

La tua seconda opzione è una strada ragionevole da percorrere. Se si suddivide il problema in blocchi comprensibili, l'approccio top down rivelerà tutti i principali difetti di progettazione prima di implementare tutti i piccoli dettagli. Puoi scrivere stub per funzionalità di livello inferiore per tenere tutto appeso insieme.

Answer 7

Penso che ci sia altro da considerare rispetto al design dal basso verso il basso. È ovviamente necessario suddividere il progetto in unità di lavoro gestibili, ma è necessario considerare anche la definizione delle priorità ecc. E in un progetto di sviluppo iterativo, spesso si ridefinirà il problema per la successiva iterazione dopo aver fornito la soluzione per la precedente .

Answer 8

Durante la progettazione, mi piace fare il middle-out. Mi piace modellare il dominio, quindi progettare le classi, passare al database e all'interfaccia utente da lì. Se ci sono funzionalità specifiche basate sull'interfaccia utente o basate su database, posso progettare anche quelle in anticipo.

Durante la codifica, in genere mi piace fare bottom-up (prima il database, quindi le entità aziendali, quindi l'interfaccia utente), se possibile. Trovo che sia molto più semplice mantenere le cose dritte con questo metodo.

Answer 9

Credo che con i bravi progettisti di software (e secondo me tutti gli sviluppatori di software dovrebbero anche essere progettisti di software ad un certo livello), la magia è riuscire a fare simultaneamente dall'alto verso il basso e dal basso verso l'alto.

Cosa ero " istruito " fare dai miei mentori è iniziare da un breve top-down per capire le entità coinvolte, quindi passare dal basso verso l'alto per capire gli elementi di base che voglio creare, quindi fare un backup e vedere come posso scendere di un livello, sapendo quello che so sui risultati del mio bottom up, e così via fino a quando non si incontrano nel mezzo.

Spero che sia d'aiuto.

Answer 10

Design esterno.

Inizi con ciò che stai cercando di ottenere nella parte alta e sai con cosa devi lavorare nella parte bassa. Continua a lavorare su entrambe le estremità fino a quando si incontrano nel mezzo.

Answer 11

Sono in qualche modo d'accordo con tutte le persone che dicono "nessuno dei due", ma ognuno cade da qualche parte nello spettro.

Sono più un tipo dall'alto in basso. Scelgo una caratteristica / punto di alto livello / qualunque cosa e la implemento come un programma completo. Questo mi permette di delineare un piano e una struttura di base entro i confini del dominio problematico.

Quindi inizio con un'altra funzione e rifatto tutto dall'originale che può essere utilizzato dal secondo in nuove entità condivise. Raccogliere, sciacquare, ripetere fino al completamento dell'applicazione.

Tuttavia, conosco molte persone che sono ragazzi dal basso verso l'alto, che sentono un problema e iniziano a pensare a tutti i sottosistemi di supporto di cui potrebbero aver bisogno per costruire l'applicazione su di esso.

Non credo che nessuno dei due approcci sia sbagliato o giusto. Entrambi possono ottenere risultati. Cerco anche di trovare ragazzi dal basso verso l'alto con cui lavorare, poiché possiamo attaccare il problema da due diverse prospettive.

Answer 12

Entrambi sono approcci validi. A volte uno solo "sente" più naturale dell'altro. Tuttavia, c'è un grosso problema: alcuni linguaggi tradizionali e in particolare i loro framework e librerie pesantemente sul supporto IDE, come l'evidenziazione della sintassi, il controllo del tipo di background, la compilazione di background, il completamento del codice intelligente, IntelliSense e così via .

Tuttavia, questo non funziona con la codifica top-down! Nella codifica top-down, usi costantemente variabili, campi, costanti, funzioni, procedure, metodi, classi, moduli, tratti, mixin, aspetti, pacchetti e tipi che non hai ancora implementato! Quindi, l'IDE ti urlerà costantemente a causa di errori di compilazione, ci saranno linee rosse ovunque, non otterrai il completamento del codice e così via. Quindi, l'IDE praticamente ti proibisce di scrivere codice dall'alto verso il basso.

Answer 13

Faccio una variante di top-down. Tendo a provare a fare prima l'interfaccia, quindi lo uso come elenco di funzioni. La cosa positiva di questa versione è che funziona ancora con IDE che altrimenti si lamenterebbe. Commenta semplicemente la chiamata di una funzione a ciò che non è stato ancora implementato.