Approccio dall'alto verso il basso vs Bottom-up durante la progettazione di una libreria di classi

7

Sto progettando una libreria di classi che rappresenti concetti di teoria musicale occidentale con temperamento equabile allo scopo di comporre musica con codice notata (mi rendo conto che ci sono altre librerie e programmi per questo, ma voglio progettare il mio). Il problema che sto affrontando è che quando comincio con il concetto più fondamentale (PitchClass) e inizi a crescere, mi ritrovo molto rapidamente fuori controllo con troppa complessità nella progettazione. Finisco per rottamarlo e ricominciare da capo.

Sto pensando a un nuovo approccio. Inizia scrivendo un programma (che non verrà compilato) che dimostra come voglio usare la libreria alla fine. Ad esempio, scrivi i programmi di esempio che potrebbero accompagnare prima una libreria, come parte del processo di progettazione. Spero che ciò possa aiutarmi con le decisioni di progettazione di livello inferiore in modo da non perdere me stesso nella complessità del design.

Questo approccio è analogo alla progettazione basata su test, ma diverso in quanto il programma di esempio non è isolato in una singola classe o funzione, ma mostra invece l'interfaccia di molte classi di alto livello.

Domanda
La metodologia di progettazione top-down che sto descrivendo qui è un approccio valido? ha un nome? Sto lavorando da solo, ma i team usano mai un approccio come questo?

Questo non risponde alla domanda perché riguarda specificamente progettazione di un'interfaccia utente Web e gestione delle differenze tra i browser.

Questo non è rilevante perché riguarda il back-end rispetto alle specifiche front-end.

Questo non è un duplicato perché riguarda specificamente l'approccio a uno stack MVC.

    
posta Matthew James Briggs 29.04.2015 - 22:20
fonte

2 risposte

9

Stai descrivendo Sviluppo basato sul test di accettazione .

Il principio base dietro ATDD è che ogni requisito software è accompagnato da un test di accettazione che, una volta eseguito, fornisce la prova che il requisito è stato soddisfatto.

Acceptance tests are created when the requirements are analyzed and prior to coding. They can be developed collaboratively by requirement requester (product owner, business analyst, customer representative, etc.), developer, and tester. Developers implement the system using the acceptance tests. Failing tests provide quick feedback that the requirements are not being met.

The tests are specified in business domain terms. The terms then form a ubiquitous language that is shared between the customers, developers, and testers.

Tests and requirements are interrelated. A requirement that lacks a test may not be implemented properly. A test that does not refer to a requirement is an unneeded test. An acceptance test that is developed after implementation begins represents a new requirement.

Personalmente sono un grande fan di ATDD. I requisiti che non sono accompagnati da un test di accettazione non sono affatto requisiti; sono desideri.

    
risposta data 29.04.2015 - 23:22
fonte
3

Is the top-down design methodology I am describing here a valid approach? Does it have a name?

Sì, si chiama design top-down, e c'è un discreto articolo di Wikipedia . In particolare, stai descrivendo una variante informale in cui trovi cosa vuoi che faccia la libreria e come la vuoi organizzare in base a come intendi usarla.

do teams ever use an approach like this?

Sì, ma più grande è la squadra, maggiore è la formalità necessaria per far sì che tutti lavorino verso gli stessi obiettivi. In passato, il design top-down veniva fatto su carta prima che i programmatori venissero assunti.

    
risposta data 30.04.2015 - 00:21
fonte