Gli schemi di progettazione sono disapprovati?

Queste sono le parole di qualcuno che ha trovato successo e ignora le persone che cercano di dirgli cosa fare nel gergo modello che non capisce.

I modelli di progettazione e le migliori pratiche non sono la stessa cosa. Alcune persone pensano di essere e guidano le persone che sanno cosa stanno facendo impazzire. Anche se non conoscono il nome corretto per quello che stanno facendo.

I modelli di design esistevano prima che avessero nomi. Abbiamo dato loro i nomi per rendere più facile parlarne. Un modello che ha un nome non lo rende una buona cosa. Lo rende una cosa riconoscibile .

Questo tipo probabilmente usa schemi che nessuno di voi ha mai sentito nominare. Va bene, finché non hai bisogno di parlargli di come si fa qualcosa. O dovrà imparare come parlarti o dovrai imparare come parlargli. Non ha niente a che fare con chi è "giusto".

Molti modelli di progettazione, del tipo che tu e il tuo amico state descrivendo, sono in realtà solo soluzioni alternative per le carenze nei linguaggi di programmazione . Utilizza un linguaggio di programmazione più espressivo e la maggior parte della necessità di questi modelli di progettazione scompare.

Poiché sono necessari buoni schemi di progettazione per soddisfare molti possibili scenari di utilizzo, tendono a essere eccessivamente ingegnerizzati. Il codice troppo ingegnerizzato ha un costo: devi leggerlo, capire cosa fa e capire come funziona nel contesto dell'intero sistema software. Di conseguenza, come con qualsiasi altra tecnica di sviluppo del software, è necessario valutare la tecnica rispetto al costo dell'utilizzo della tecnica e decidere se i benefici superano il costo.

A parità di altre condizioni, meno codice è sempre migliore. Ho attraversato architetture stratificate in cui devi letteralmente eseguire da tre a sei luppoli in più progetti per trovare il codice che interessante, che è dire, codice che effettivamente realizza qualcosa diverso dall'aggiunta di overhead.

Si presume che i modelli software noti diano un vocabolario comune grazie al quale è possibile comunicare le strategie di progettazione. Sfortunatamente, molti sviluppatori di software non capiscono abbastanza bene il vocabolario del modello software per applicarlo correttamente ai loro problemi di programmazione. Gli sviluppatori inesperti vedono questi modelli come appartenenti al dominio degli esperti; vogliono essere visti come esperti e quindi cercano di imparare e applicare i modelli troppo presto, prima che siano pronti. Quello che dovrebbero davvero fare è concentrarsi sull'apprendimento dei fondamenti della programmazione, quindi tentare di risolvere il problema che ogni schema risolve da sé. Se lo fanno, saranno in una posizione molto migliore per comprendere e applicare correttamente i modelli.

Stackoverflow.SE e Programmers.SE incoraggiano principalmente le persone a seguire le best practice come SOLID, non standard di settore . E che ci crediate o no, lo standard di settore di fatto è spesso la "grande palla di fango" architettura - sul serio.

Ma per rispondere direttamente alla tua domanda: il problema con gli schemi di progettazione è simile a quello dell'ereditarietà: molti sviluppatori mediocri li usano eccessivamente, il che comporta un certo rischio di creare codice troppo elaborato e difficile da gestire. Ma la risposta a questo non è sicuramente di evitare o vietare completamente l'uso di schemi di progettazione (o eredità), la risposta è imparare a usare questi strumenti in situazioni in cui hanno senso, e solo lì. E questo è completamente indipendente dal lavorare "agile" o meno.

1. I design pattern sono solo nomi usati per comunicare idee. Spesso mi sono ritrovato a fare cose che più tardi ho trovato che hanno un nome. Pertanto, non esiste un "modello di progettazione" in contrapposizione a un "modo modello non di progettazione".

2. I modelli di progettazione sono linee guida. Come tutto, ognuno di essi ha vantaggi e svantaggi. La chiave non è imparare il modello e applicarlo dove si adatta, ma piuttosto capire l'idea del modello, i vantaggi e gli svantaggi che ha e usarlo per trarre ispirazione per la soluzione al tuo problema.

3. Ogni buona pratica e linea guida possono essere ignorate se c'è una ragione sufficiente. I motivi validi includono i tempi di sviluppo e le aspettative dall'applicazione. Ad esempio, sono consapevole del fatto che i valori dell'hardcode non sono buoni (esempio stupido), ma per una dimostrazione del concetto, i vantaggi potrebbero superare i costi (in questo caso, soprattutto i tempi di sviluppo). Tuttavia, se viene presa una decisione del genere, potrebbe ritorcersi contro e ad un certo punto potrebbe essere necessario un refactoring.

Per aggiungere un'altra metafora al brodo, i pattern di progettazione sono Clippy l'helper di Microsoft Office. "Sembra che tu stia facendo la stessa cosa con un sacco di cose. Posso aiutarti con l'offerta di Iterator o Visitor?"

Un buon resoconto di questi pattern indicherà quando è utile fare qualcosa allo stesso modo in cui è stato fatto molte volte in passato, quali errori farai la prima volta che lo proverai e quali sono stati i metodi più comuni per evitare quegli errori. Quindi leggi il modello di progettazione (o lo rivedi dalla memoria) e poi vai avanti con il tuo lavoro. Quello che non puoi fare è ottenere solo usando Clippy e procedure guidate.

Dove le persone inesperte possono sbagliare e scrivere codice che non tiene conto della realtà, è quando pensano che la loro lista di modelli di progettazione sia una lista completa di tutti i possibili approcci per risolvere i problemi nel software, e provi a progettare il codice collegando insieme modelli di design fino a quando non è finito. Un'altra cattiva tattica osservata in natura è quella di calzare il corno come un disegno in una situazione per la quale non è particolarmente adatto, sulla base del fatto che il modello di progettazione "è la migliore pratica". No, potrebbe essere o non essere la migliore pratica per la classe di problemi che risolve veramente , ma non è certamente la migliore pratica per problemi che non riesce a risolvere, o per problemi che risolve solo introducendo complessità inutile quando c'è una soluzione più semplice.

Naturalmente è anche possibile per qualcuno evitare un modello sulla base del fatto che YAGNI, quindi rendersi conto che ne hanno bisogno e tentare di raggiungere la soluzione normale. Questo è solitamente (ma non sempre) peggiore rispetto alla realizzazione del requisito fin dall'inizio, ed è il motivo per cui anche in uno sviluppo agile è frustrante quando i requisiti completamente prevedibili non vengono scoperti presto. Non posso essere stato l'unico programmatore C ++ ad essere molto divertito dal fatto che Java inizialmente rigettasse i contenitori generici come inutilmente complessi, per poi richiuderli in un secondo momento.

Quindi è quasi certamente un errore evitare di scrivere un Iterator in linea di principio perché preferisci evitare schemi di progettazione.

Adding a new field to the UI/database/Data layer takes 2-3 hours to do, where as in his code it takes 30 minutes.

Non si può davvero discutere con questo: con questa metrica il suo design è di gran lunga migliore dell'altro. Se questo è perché ha evitato i modelli di design è discutibile, penso che sia più probabile perché ha considerato i giusti problemi "reali" quando lo ha progettato, e con il beneficio dell'esperienza è meglio qualcuno armato solo di un libro di testo e alti ideali.

Quindi ha riconosciuto che qualsiasi schema che richiede di toccare molti punti diversi nel codice per aggiungere un campo è un cattivo schema per il lavoro, "facilita l'aggiunta di campi", e non li ha usati modelli. Le architetture stratificate possono effettivamente soffrire a tale riguardo, ed è sbagliato utilizzare modelli di progettazione senza apprezzarne gli svantaggi.

Per contro, quanto tempo ci vuole per scrivere una nuova interfaccia utente nel suo design e quanto tempo ci vuole in un'architettura a strati? Se il progetto richiedeva che lui costruisse e distribuisse costantemente nuove interfacce utente su un modello di dati fisso, invece di aggiungere costantemente campi, si sperava che avrebbe progettato per questo invece. O pure. Ma con tutti i suoi benefici, dire "stiamo facendo agilmente" purtroppo non significa che non dovrai mai fare un altro compromesso!

La selezione da un menu di modelli di progettazione ti può sicuramente impedire di pensare alle preoccupazioni più importanti. Ma riconoscere quando scrivi un visitatore e documentarlo o nominarlo "visitatore" per aiutare i lettori a farlo in fretta, non interferisce in alcun modo. Scrivere "questo è un visitatore" invece di documentarlo correttamente è un terribile errore per il motivo che il tuo senior dev fornisce - i programmatori non lo capiranno. Persino i programmatori che sanno cos'è un visitatore hanno bisogno di più informazioni che semplicemente "questo è un visitatore".

Il tuo collega sembra soffrire della sindrome NIH ("Non inventata qui").

È perfettamente plausibile che il suo codice faciliti l'aggiunta di nuovi campi: sono anche molto più veloce ad aggiornare il mio codice rispetto al codice scritto da altri ragazzi. Ma questa velocità a breve termine non dice nulla sulla manutenibilità e sulla portabilità del codice. Gli darò il beneficio del dubbio: il codice esistente potrebbe effettivamente essere strutturato male se ha seguito male un manuale o ha seguito una buona ricetta nel contesto sbagliato.

Evitare schemi di progettazione è davvero sorprendente. Nei miei ultimi 30 anni di codifica e gestione dei codificatori, i modelli di progettazione hanno aiutato a mettere le parole su cose che sono state fatte istintivamente, aiutando così a comprendere più rapidamente l'intento, i vantaggi, i disagi, i rischi, le opportunità e i modelli correlati. I modelli di progettazione si sono rivelati dei veri acceleratori per padroneggiare la complessità!

• Forse il tuo collega è davvero molto più intelligente della maggior parte di noi e può permettersi il sovraccarico di reinventare modelli senza una notevole diminuzione della produttività?

• Gli argomenti che "i programmatori non capiscono gli schemi di progettazione" sembrano "Non so spiegare cosa sto facendo". O "Non voglio discutere del mio progetto". Penso davvero che la modellizzazione potrebbe sfruttare la comprensione generale e consentire a colleghi meno esperti di condividere opinioni di valore. Ma forse il tuo collega senior vuole evitare proprio questo.

Gli approcci stratificati hanno dimostrato di essere superiori ad altre architetture nella maggior parte delle applicazioni aziendali. I pacchetti leader di livello mondiale sono strutturati attorno a questa idea e sovraperformano le architetture artigianali per ordine di grandezza. Martin Fowler presenta questo approccio nel suo eccellente libro su "Modelli di architettura aziendale". Oh! Scusa ancora: si tratta di modelli comprovati; nessuna possibilità nella vista NIH del tuo collega; -)

Un'intuizione chiave che molte persone sentono la mancanza è che il design del software è contestuale. Esiste per raggiungere gli obiettivi aziendali e diversi obiettivi possono richiedere approcci diversi. In altre parole, non c'è design che sia sempre il migliore, anche se c'è sempre un design migliore.

I modelli di progettazione sono soluzioni standard ai problemi standard. Tuttavia, se non si ha il problema, risolverlo è uno spreco di energie.

La differenza fondamentale tra la progettazione del software a cascata e quella agile è quando vengono prese decisioni di progettazione . In cascata, raccogliamo tutti i requisiti, identifichiamo i modelli di progettazione di cui abbiamo bisogno e solo dopo iniziamo la codifica. In un'architettura agile, seguiamo la pri- gina YAGNI per rinviare le decisioni di design fino all'ultimo momento di responsabilità, quando sappiamo quanto più possibile sulla scelta.

Cioè, in cascata, gli schemi di progettazione tendono ad essere applicati se il loro bisogno è anticipato , in agile, quando sono effettivamente necessari . Di conseguenza, i progetti agili tendono ad applicare modelli di progettazione meno spesso, perché non tutti i bisogni previsti sono effettivi.

I modelli di design non sono in realtà definiti modelli di design perché prescrivono cosa fare. I modelli di progettazione sono schemi di progettazione perché descrivono ciò che è stato fatto prima . Alcuni sviluppatori o sviluppatori hanno progettato un metodo che ha svolto bene un particolare compito e sono stati in grado di applicarlo a situazioni simili con risultati simili. Questo è tutto. Molti modelli hanno punti di forza e debolezze intrinseche e spetta allo sviluppatore istruito valutare le esigenze tecnologiche e aziendali per determinare un modello appropriato da applicare.

In questa luce, a meno che tu non sia veramente impegnato a scrivere un codice unico al 100%, in cui nessun concetto o implementazione sia utilizzabile da un caso d'uso all'altro, quasi certamente stai utilizzando almeno alcuni modelli di progettazione. Potrebbero non avere nomi comuni appariscenti come "Repository" o "Unit of Work" o anche "MVC", ma questo non li rende "non un modello di design".

Di solito mi piace pensare a come - diciamo - "navigazione" usando il GPS. Quando apprendi le "migliori pratiche" e i "modelli di progettazione", impari a utilizzare il percorso di navigazione GPS. Ma quando conosci l'area, imparerai spesso che percorrere una strada secondaria ti porterà a superare le aree problematiche, raggiungendoti più velocemente e / o meglio. È la stessa cosa quando si tratta di queste cose: l'esperienza ti rende in grado di decostruire la tua cassetta degli attrezzi e prendere scorciatoie.

Apprendere modelli di progettazione e apprendere le "migliori pratiche" significa acquisire una comprensione dell'idea alla base in modo da poter scegliere in una determinata situazione. Poiché le situazioni della vita reale sono spesso più complesse rispetto alle situazioni teoriche, spesso si hanno vincoli e problemi non presenti nei libri di testo. Clienti / Clienti vogliono il loro prodotto veloce e di solito a buon mercato; Devi lavorare con il codice legacy; È necessario interagire con strumenti di terze parti che potrebbero benissimo essere scatole nere e inefficaci; e ogni sorta di cose. La tua situazione è specifica: le migliori pratiche e i modelli sono più generali.

Una delle ragioni principali per cui molte persone su siti come SE ti daranno risposte sulle "migliori pratiche" e risposte sul "design pattern" è che rispondono in una soluzione generale e astratta e quindi forniscono un linguaggio comune per la risoluzione un tipo di problemi. E per farti imparare.

Quindi - no - i modelli di design non sono disapprovati negli ambienti di sviluppo Agile; lo sviluppo tuttavia è raramente generale e abbastanza astratto da adattarsi perfettamente a uno schema e lo sviluppatore (esperto) lo sa.

Adding a new field to the UI/database/Data layer takes 2-3 hours to do, where as in his code it takes 30 minutes.

Se vuoi "ottimizzare" un design, devi dire cosa stai cercando di ottimizzare.

Ad esempio, una bicicletta da corsa è un veicolo ottimizzato ... e un Boeing 747 è anche un veicolo ottimizzato ... ma sono ottimizzati per un diverso insieme di requisiti.

L'idea del pattern "MVC", ad esempio, ottimizza per cose come:

• Viste diverse dello stesso modello (la vista è indipendente dal modello)
• Ogni livello può essere sviluppato separatamente (ad esempio da team diversi) e testato separatamente (test unitari) prima dell'integrazione
• ecc.

Mentre il suo codice potrebbe essere l'ottimizzazione per qualcos'altro, ad esempio:

• Linee minime di codice
• Facile per una persona apportare una modifica che influisce su tutti i livelli (non avendo affatto strati veramente distinti)
• ecc.

Le descrizioni dei modelli iniziano con una descrizione del problema che il modello intende risolvere. Se pensa che sia "la migliore pratica" di non usare un modello specifico, allora (assumendo che non sia uno schema stupido, supponendo che sia un modello che è utile a volte) suppongo che non abbia / sperimenta il problema specifico che tale modello afferma per risolvere, e / o ha un diverso (più grande o più urgente, in concorrenza) problema che sta cercando di ottimizzare per, invece.

I modelli di design sono strumenti. Come gli strumenti, ci sono due modi per usarli: il modo corretto e il modo sbagliato. Ad esempio, se ti do un cacciavite e un chiodo e ti chiedo di unire due pezzi di legno insieme, dovresti chiedermi un martello. I martelli sono usati per le unghie, mentre i cacciaviti sono usati per le viti.

Troppo spesso, un modello di design è pubblicizzato come One True Way, che spesso è vero solo quando sorgono problemi particolari. Gli sviluppatori junior sono spesso dei bambini quando trovano qualcosa di nuovo con cui giocare; vogliono applicare quel modello di design a tutto . E non c'è nulla di intrinsecamente sbagliato in questo, fintanto che alla fine apprendono che il Pattern A si applica al Problema B, e Pattern C si applica al Problema D. Proprio come non usi un cacciavite per guidare le unghie, non usi un particolare modello solo perché esiste; usi lo schema perché è lo strumento migliore (conosciuto) per il lavoro.

Il rovescio della medaglia è anti-pattern. Cose che si sono dimostrate di volta in volta pessime, solitamente in termini di tempo di esecuzione o memoria. Tuttavia, entrambi i pattern e gli anti-pattern non vanno bene allo sviluppatore che non capisce perché esistono. Gli sviluppatori amano pensare che quello che stanno facendo è nuovo e inventivo, ma la maggior parte delle volte non lo sono. Probabilmente è stato pensato prima. Le persone prima di loro hanno creato i modelli a causa dell'esperienza.

Ovviamente, gli sviluppatori junior spesso escogitano nuovi modi di fare cose vecchie, ea volte quelle sono migliori. Tuttavia, troppo spesso finisce per essere un caso dell'effetto Dunning-Kruger; lo sviluppatore sa quanto basta per creare un programma funzionale, ma non capisce i propri limiti. L'unico modo per superare questo sembra essere attraverso l'esperienza, sia positiva che negativa. Ignorano i pattern perché credono di essere superiori, ma non sanno che, in realtà, 10.000 sviluppatori hanno già utilizzato un design specifico, e poi lo hanno scartato perché in realtà era cattivo.

Agile favorisce "fare le cose in modo reattivo" per quanto riguarda l'adeguamento rapido alle esigenze in evoluzione dei clienti. Non favorisce né i modelli di progettazione, né li disprezza. Se un modello è il metodo più veloce e affidabile, lo sviluppatore dovrebbe utilizzarlo. Se un modello particolare costerebbe più tempo del semplice "completamento", è probabile che l'uso di qualcosa che non è un modello sia corretto (presumendo, ovviamente, che le prestazioni non siano gravemente degradate, ecc.). Se non è possibile trovare uno schema noto, è preferibile progettare il proprio oltre a dire al cliente "no". I clienti, in particolare i clienti paganti, di solito hanno ragione.

Chiunque affermi che i modelli sono The Way, o afferma che i pattern sono The Bane Of Existence, sono sbagliati. I modelli sono strumenti, pensati per essere applicati a situazioni specifiche e hanno vari gradi di successo in base alle circostanze. Questa è una verità, una che non dipende dal fatto che tu abbia scelto MVC o meno, se usi o meno oggetti di trasferimento dati, ecc. Ciò che conta è implementare il codice in un arco di tempo ragionevolmente breve, che funzioni ragionevolmente bene per gli utenti, ed è ragionevolmente privo di bug logici.

Di solito , i pattern permetteranno una forma coerente di design, e funzioneranno meglio di ignorare tutti gli schemi a favore della scrittura di idee originali al 100%, ma non è possibile evitare tutti i pattern. Ad esempio, se y = x + 5, scriveresti davvero y = x + (5 * 3 + 15/3) / 4, solo per evitare il pattern di scrittura x + 5? No non siete. Stai scrivendo y = x + 5 e vai al prossimo problema.

Le persone usano i pattern ogni giorno e va bene . Ciò che conta di più è avere un codice logicamente funzionale, che si blocca raramente e che è facile da usare. Nient'altro conta di più.

Non è possibile "evitare schemi di progettazione", tranne suppongo che eviti di progettare due parti del tuo sistema allo stesso modo (che non consiglio e dubito che lo sviluppatore senior stia facendo). Quello che probabilmente intende è 'evitare di usare ciecamente un design solo perché aderisce a un modello di design'. Pensare a quello che stai facendo è sicuramente una "migliore pratica", e una università dovrebbe esistere per insegnare; purtroppo, sembra che non stia succedendo.

I modelli di progettazione non sono antitetici alle pratiche agili. Ciò che è antitetico alle pratiche agili è l'utilizzo di modelli di progettazione per il gusto di utilizzare schemi di progettazione, la pratica comune tra neolaureati e studenti di pensare sulla falsariga di "come risolveremo questo problema usando un modello di fabbrica".

Agile significa scegliere lo strumento migliore per il lavoro, NON provare a modellare il lavoro per adattarlo allo strumento che hai selezionato.
E questo è ciò a cui TUTTE le pratiche di sviluppo del buon senso si riducono (anche se spesso è necessario scendere a compromessi perché la selezione di strumenti tra cui scegliere è solitamente limitata dagli standard aziendali, restrizioni di licenza (come GPL e talvolta altri strumenti open source spesso non può essere usato, specialmente quando si costruisce un software per la rivendita), e cose del genere.

Il tuo collega / amico probabilmente si è opposto al tuo codice non perché utilizza schemi di design di per sé, ma perché è un costrutto artificiale progettato per mostrare l'uso di uno schema specifico quando un altro design sarebbe stato migliore (anche se spesso soggettivo, ho (e molti con me senza dubbio) hanno visto un sacco di esempi in cui l'uso forzato di uno specifico modello di progettazione ha portato a un codice brutto, difficile da mantenere e altamente inefficiente).