Architetture agili [chiuso]

Question

Sto iniziando la mia tesi di laurea e il tema sarà "architetture agili"

Fondamentalmente, inizierà con una descrizione delle metodologie tradizionali di sviluppo software, e la successiva nascita di metodologie agili, per finire con raccomandazioni e una progettazione di un'architettura applicativa flessibile e facilmente adattabile ai cambiamenti inerenti alla costruzione del software.

La mia domanda è: quali modelli e pratiche di progettazione consiglieresti per un'architettura del genere?Sono interessato a modelli che consentano la massimizzazione del disaccoppiamento delle classi come l'inserimento delle dipendenze, l'elevata manutenibilità e la massima astrazione dal problema specifico.

Answer 1

Raccomando quanto segue:

1. Modello di deposito
2. Modello di specifica
3. Iniezione di dipendenza
4. Progettazione guidata dal dominio

Fondamentalmente tutto ciò che predica il pubblico di ALT.NET.

Answer 2

Sicuramente pratiche dell'IoC e basato su contratto la programmazione in generale sarebbe in cima alla mia lista.Per esperienza, però, metterei in guardia dal fare astrazione eccessiva dal problema semplicemente per amore dell’astrazione.Per esempio.astraendo perché puoi e non perché qualcuno potrà mai avvalersi di quell'astrazione.Ho visto quel tipo di architettura andare male e aggiungere semplicemente un livello troppo elevato di complessità a un sistema peggiorandone la manutenzione.

Una sorta di ciclo di feedback attorno al processo di sviluppo, che si tratti di test unitari, integrazione continua e/o riunioni "scrum".Mi rendo conto che non rientra realmente nell'ambito delle "architetture" agili, ma se non si dispone di un processo agile, nessun grado di architettura "orientata all'agile" avrà importanza.

Answer 3

Una pratica di progettazione essenziale che suggerirei è di costruire prima uno scheletro end-to-end funzionale della tua architettura.Per convalidarlo il prima possibile attraverso un feedback reale.

Questo è ciò che i Programmatori Pragmatici chiamano "Tracer Bullets", e Alistair Cockburn come "scheletro ambulante".

Puoi anche definire cos'è un'applicazione nel contesto della tua tesi?Consideri solo software applicativo O hai anche a che fare con sistemi più complessi?

Answer 4

È una domanda interessante, questa.È possibile creare un’architettura agile nell’isolamento?Se stiamo guardando qualcosa come XP, allora sono un po' dubbioso.O forse ho capito male, ma questo non mi ha mai impedito di espandermi...

In XP, per adottare un approccio di cui so di più, avremo una sorta di struttura entro un tempo molto breve dall'inizio di un progetto;più o meno nel momento in cui la prima storia è completa, in effetti.Durante la scrittura iniziale della storia avremo iniziato a farci un'idea di cosa potremmo costruire: è inevitabile:i programmatori tendono a pensare in termini di codice.Ma pensare troppo avanti ci porta dentro YAGNI territorio.

In un certo senso pensavo che gran parte dell'architettura di un'applicazione sviluppata all'interno di un ambiente agile dovrebbe emergere attraverso, in particolare, un refactoring costante e dedicato per rimuovere le duplicazioni.

Quindi forse la questione è anche quella di valutare se ci sono caratteristiche particolari – o classi di caratteristiche – che le architetture evolute come risultato di un processo agile tenderanno a mostrare.E poi penso che dipenderà dal tipo di app che stiamo costruendo, anche se alcuni dei principi già menzionati (un paio dei quali capisco anche) devono essere probabili.

Answer 5

Per quanto mi riguarda Agile non predica alcuna "Architettura" in quanto tale.Agile è una metodologia basata su principi fondamentali che influiscono sulla gestione del progetto, sui cicli di rilascio e sulle pratiche generali di sviluppo, ma certamente non sull'architettura del software.

Tutti i modelli software elencati qui potrebbero essere utilizzati utilizzando un forte processo a cascata che è un anatema per lo sviluppo Agile.

Answer 6

Architettura della cipolla

esempio

Answer 7

Essere agili significa abbracciare il cambiamento, ad es.adottare per modificare i requisiti e le decisioni di progettazione e accettare il refactoring, ecc.molte cose in modo "tradizionale" disapproverebbero, dal momento che stai toccando qualcosa che funziona / concordato in precedenza.

In metodi come XP cerca di mantenere alta la qualità scrivendo test unitari.Facciamo finta che siamo tutti d'accordo nello scrivere test unitari.

Ora ecco dove puoi introdurre un'architettura in modo che il sistema sia testabile o adatto ai test, perché non tutti i sistemi sono testabili.Ad esempio, rendendo richiamabile il livello intermedio e separando il livello dell'interfaccia utente dalla logica aziendale, ecc.

Answer 8

Se Robert Martin ha qualcosa da dire al riguardo (e ha indetto l’incontro originale dell’IIRC sul Manifesto Agile), allora l’architettura ha assolutamente tutto a che fare con l’Agilità.Tutta la prima sezione del suo libro Sviluppo software agile, principi, modelli e pratiche riguarda il SOLIDO principi architettonici.Questo è stato un po’ controverso in alcuni ambienti, ma non capisco perché.Se la tua base di codice è fragile e fortemente accoppiata, non può essere molto aperta al cambiamento, che è il segno distintivo dell’agilità.Separare concettualmente il processo dalla pratica del codice è una cosa molto poco agile da fare.

Principio 1 del manifesto:"Diamo valore alle persone e alle interazioni piuttosto che ai processi e agli strumenti."

Definire il "processo" Agile come un'astrazione separata dall'architettura della base di codice per me viola lo spirito di questo primo principio.