Come creare l'architettura / il design di un'applicazione in Agile?

Non sviluppare il nucleo prima . Un principio chiave dello sviluppo Agile è scrivere il codice minimo necessario per le funzionalità completate. In questo modo puoi consegnare in qualsiasi momento. Il codice rimane flessibile perché si aggiorna continuamente per eliminare la duplicazione. Il refactoring è supportato dai test automatici che hai scritto per ogni funzione mentre lo hai creato. Il core cresce automaticamente dal momento che calcoli la duplicazione dal codice di livello superiore.

Fondamentalmente, invece di costruire flessibilità nel solito tentativo di minimizzare costose modifiche future del codice, Agile costruisce test automatizzati per supportare il refactoring, in modo che le modifiche al codice siano relativamente poco costose.

Il Refactoring di Martin Fowler è il mio libro preferito sulle tecniche di refactoring efficaci. È molto più semplice calcolare un nucleo utilizzabile piuttosto che definirne uno in primo piano. Definire un core utilizzabile prima dell'implementazione della funzione è quasi impossibile, a meno che non si stia semplicemente reimplementando un'API esistente. E non c'è alcun valore in questo.

Il mio approccio allo sviluppo agile è costruire "sezioni verticali". Raccolgo una storia dall'interfaccia utente per conservarla e implementarla. Ho alcuni strumenti leggeri che uso per aiutare questo processo (come un semplice framework IRepository / UnitOfWork con adattatori per In Memory (di solito per test), Entity Framework e NHibernate. A questo punto non penso ci sia molto di un argomentazione sull'opportunità o meno di utilizzare un O / RM ma piuttosto quale usare. E per me dipende dall'ambiente.

Ho scoperto che questo approccio conquista gli oppositori per quanto riguarda lo sviluppo agile perché riescono a vedere il software di lavoro più rapidamente rispetto a quando spendo un sacco di tempo per creare un core. In combinazione con Domain Driven Design e alcune altre tecniche che uso, di solito sono in grado di ottenere molte funzionalità di lavoro di fronte agli utenti molto rapidamente.

Il TDD o anche il collaudo post-hoc delle unità è importante perché parte del mantenimento della velocità man mano che la tua applicazione cresce sta avendo quella rete di sicurezza fornita da una suite di test unitaria completa. "Ho bisogno di fare un cambiamento in questa classe, come faccio ad essere sicuro di non aver infranto nulla?" Con una buona suite di test unitari, è semplice come eseguire quella suite di test. Senza, diventa questione di eseguire manualmente la tua app per verificare. Non è affatto divertente.

Crea la struttura orizzontale minima che supporta una porzione verticale di funzionalità. Il framework è realizzato per essere estensibile ed è il punto in cui la maggior parte degli sforzi viene inizialmente focalizzata. La parte verticale della funzionalità è dimostrare che il framework supporta il valore reale. Nelle successive iterazioni dedicare meno sforzi man mano che si realizza il framework e più per costruire funzionalità usando il framework. Continua così fino a quando la maggior parte degli sforzi si concentra sulla funzionalità utilizzando il framework sviluppato su iterazioni.