Ho appena letto il link all'articolo che hai postato, devo dire che Fowler ha fatto ottimi punti e molte cose che ha detto, sostengo il nostro team da anni.
IMO, se fai un progetto decente, non dovresti entrare in quella che sarebbe considerata una situazione senza uscita. Ho sempre visto il software come costituito da blocchi . Credo ancora in un design iniziale, ma l'obiettivo principale non è quello di progettare l'intero prodotto, ma di fornire un'architettura / direzione generale in modo che il tuo team possa visualizzare un'immagine comune a cui tutti stiamo lavorando. Se hai un mucchio di pezzi di cubo e triangolo, è utile delineare come un castello sarebbe messo insieme prima di iniziare semplicemente a schiaffeggiare i pezzi.
Da quando vengo dalla terra di OO, per me ogni blocco è una classe e la superficie di quel blocco è l'interfaccia pubblica (ciò che è visibile da classi esterne o derivate). Se segui buoni principi SOLIDI, ti assicurerai che ogni blocco sia estremamente semplice e abbia un'interfaccia pubblica intuitiva. Tornando alla mia analogia, vuoi assicurarti che il codice crei solo forme semplici. Ogni volta che crei classi troppo complesse (molte funzioni, molte variabili), crei forme che sono difficili da riutilizzare quando cambiano i requisiti.
Concordo con Fowler sul fatto che il rischio / sfida più grande per il design evolutivo è che lasci le decisioni di progettazione al tempo di programmazione e ti aspetti che ogni singolo sviluppatore prenda tali decisioni. È qui che il sistema può guastarsi se non si dispone di meccanismi di feedback adeguati. Ogni volta che viene richiesta una nuova funzionalità, è estremamente allettante trovare semplicemente la funzione che deve essere estesa, mettere un qualche tipo di condizionale al suo interno e semplicemente aggiungere un sacco di codice proprio all'interno di quella funzione. E a volte, questo potrebbe essere tutto ciò che è necessario, ma questa è anche (IMO) la singola pratica più comune che porta a componenti senza uscita. Questo non ha nulla a che fare con il design evolutivo. Questo è ciò che si chiama "no design".
Fintanto che ti prendi il tempo di fare un passo indietro e dire, aspetta un minuto, questa classe ha già 15 variabili membro, lasciami estrarre 6 di queste e metterle nella loro classe autonoma, il tuo software sarà composto da una luce di peso leggero, flessibile e riutilizzabile. Sicuramente se i PM arrivano e cambiano la metà dei requisiti dei prodotti, potresti dover rimuovere alcuni dei tuoi blocchi, rimetterli sullo scaffale e disegnarne di nuovi (proprio come quando si costruisce un castello, non è possibile utilizzare tutti i tuoi cilindri). Ma a quel punto, questa è solo una parte del fare affari. Requisiti modificati e mantenendo il codice flessibile e modulare, dovresti essere in grado di cambiare il tuo prodotto per allinearlo con la tua nuova direzione aziendale.
Credo che questo approccio evolutivo alla progettazione funzioni con ogni livello di abilità dell'ingegnere. Personalmente, ho realizzato software per molto tempo e prima che il nostro team passasse alla metodologia agile, ero responsabile della spedizione di diversi componenti principali dal mio PC di sviluppo quasi direttamente al cliente con quasi nessun controllo di qualità. Allo stesso tempo, quei componenti sono sempre rimasti flessibili e mantenibili.
Sto solo cercando di dire che mi considero relativamente decente nella progettazione del software. Allo stesso tempo, se mi chiedessi di scrivere un documento di progettazione di 100 pagine, consegnarlo a un programmatore e aspettarti che funzioni, probabilmente non avrei potuto progettarmi da un sacchetto di carta. Quando si avvia il lavoro, a volte vorrei delineare alcuni diagrammi simili a UML (molto semplificati, non in un linguaggio completo), ma quando comincio a programmare, refactoring secondo le necessità e il mio codice finale non assomiglierebbe mai a quello che ho disegnato in origine. Anche se passo un mese o due a pensare a ogni piccolo dettaglio, non riesco a immaginare qualcun altro che sia in grado di prendere i miei diagrammi e inventare un solido software senza modificare il design mentre codifica.
Dall'altra parte dello spettro, attualmente nella mia squadra (ora agile e lo sostengo pienamente) abbiamo un paio di ragazzi che si sono uniti a noi da un territorio incastonato dove hanno fatto C solo negli ultimi 15 anni. Ovviamente ho aiutato con alcune lezioni iniziali di pianificazione e preparazione, ma mi sono anche assicurato di dare seguito a revisioni periodiche del codice e sessioni di brainstorming in cui discutiamo delle applicazioni di SOLID e dei principi di progettazione. Hanno prodotto un po 'di codice spaghetti che mi ha fatto rabbrividire un po', ma con una leggera spinta da parte mia, hanno iniziato a refactoring ciò che era già stato prodotto e la cosa divertente è che uno di loro è tornato da me qualche giorno dopo e dice: Odio per dirlo ma dopo aver spostato quel codice, questo sembra molto più leggibile e comprensibile. Vicolo cieco evitato. Punto I ' Sto cercando di fare è che anche qualcuno che è completamente nuovo a OO può produrre un codice abbastanza decente, purché abbia un mentore con più esperienza, per ricordargli che il "design evolutivo" non è la stessa cosa di "nessun design". E anche alcune delle sue classi "più complesse" non sono così spaventose perché ogni classe non ha molta responsabilità (cioè non tanto codice), quindi il peggio peggiora, se quella classe "vicoli ciechi", noi buttalo e scrivi una classe sostitutiva che abbia la stessa interfaccia pubblica (finora non ho mai visto la necessità di questa contingenza in tutto ciò che abbiamo scritto e ho fatto revisioni del codice due volte a settimana).
Come nota finale, sono anche fermamente convinto dei documenti di progettazione (almeno per le condizioni aziendali del mio attuale team) ma l'obiettivo principale per i nostri documenti di progettazione è la Memoria organizzativa , quindi i documenti effettivi vengono scritti dopo che il codice è stato prodotto e refactoring. Prima della codifica, generalmente abbiamo una fase di progettazione rapida (a volte non così rapida) in cui delineamo le classi su tovaglioli / mspaint / visio e ricordo sempre alle persone che questa fase produce un percorso da seguire, non un progetto e mentre iniziano a programmare, tutto ciò che non ha senso dovrebbe essere cambiato. Anche con questi promemoria, i ragazzi più recenti tendono a provare a inserire il codice nel design originale, non importa quanto sia innaturale anche per loro. Questo di solito emerge nelle revisioni del codice.
Dang, ho scritto molto. Mi dispiace per quello.