I modelli di design sono disapprovati?


135

Ho avuto una discussione con uno dei nostri sviluppatori senior che è stato nel settore per 20 anni. È abbastanza conosciuto in Ontario per un blog che scrive.

La cosa strana è ciò che mi ha detto: ha detto che esiste un pezzo di codice con cui è un incubo lavorare perché è stato scritto da un libro di testo e non tiene conto del mondo reale. L'aggiunta di un nuovo campo all'interfaccia utente / al database / al livello dati richiede 2-3 ore, mentre nel suo codice impiega 30 minuti.

L'altra cosa è che evita i modelli di progettazione perché la maggior parte dei programmatori non li capisce e non sono bravi dal punto di vista della manutenzione.

Poi c'è anche l'idea che la maggior parte degli sviluppatori web in Canada preferisca che il loro modello di dati erediti dalle classi del livello di dati, piuttosto che tenerlo isolato. Gli ho chiesto: "Non è standard di settore per il modello da separare dal livello dati?" Ha detto a volte, ma la maggior parte delle persone qui preferisce non farlo perché è troppo lavoro.

Sembra che il suo ragionamento per non codificare usando le migliori pratiche sia perché è un incubo per la manutenzione, pochi dei nostri dipendenti lo capiscono (oltre a me stesso), ed è lento a lavorare se è necessario distribuire nuove funzionalità o campi in pochi giorni " tempo.

È così strano sentire un'opinione del genere, considerando che Stack Overflow incoraggia principalmente le persone a seguire gli standard del settore. Il problema è che siamo costantemente costretti a sfornare nuovi campi e funzionalità in pochi giorni, che non è possibile dedurre un modello solido sufficientemente flessibile? Questo sembra essere l'essenza di ciò che capisco da questo.

Cosa ne pensi di queste affermazioni?



67
Personalmente sono nervoso per qualsiasi cosa definita "best practice" (senza giustificazione) perché di solito significa "Non so perché questa sia una buona idea, ma voglio che tu lo faccia comunque; fine della discussione"
Richard Tingle

34
gli standard del settore, il modello di progettazione e le migliori pratiche sono solo termini per "Le cose che qualcuno ha detto funzionano meglio nel loro contesto, quindi anche per il tuo. Probabilmente. Forse" ®. il tuo senior dev ha ragione.
CptEric,

86
Questo non ha nulla a che fare con Agile.
Razze di leggerezza in orbita

68
"senior mvc developer" "i modelli di design sono cattivi" la dissonanza cognitiva
Dan Pantry

Risposte:


239

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 proprio per quello che stanno facendo.

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

Questo ragazzo probabilmente sta usando modelli di cui nessuno di voi ha mai sentito parlare. Va bene, finché non hai bisogno di parlargli di come viene fatto qualcosa. O dovrà imparare a parlare con te o dovrai imparare a parlare con lui. Non ha nulla a che fare con chi ha "ragione".


12
D'accordo, con l'avvertenza che, quando la maggior parte delle persone usa il termine "modelli di design" al giorno d'oggi, di solito si riferiscono alla banda dei quattro .
Robert Harvey,

35
Giusto e mi piace usare l'inglese, ha senso per me. Non so perché i francesi impiegano così tanto tempo per adottarlo. Fino a quando lo farò, imparerò un po 'di questo sistema metrico di cui continuo a sentir parlare.
candied_orange,

6
Potrebbe non essere che non capisca, potrebbe anche essere che capisce ma sa che non tutto si applica in tutte le situazioni.
whatsisname

148
"Uno schema che ha un nome non lo rende una cosa buona. Lo rende riconoscibile." Oh mio Dio, questo è il miglior riassunto del problema che abbia mai sentito: D
Razze di leggerezza in orbita

7
@JanDoggen Sono chiamati modelli (anti-) perché sono anche modelli comuni nello sviluppo del software (alcuni dei quali sono modelli relativi al design).
JAB

95

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

Poiché sono necessari buoni modelli di progettazione per soddisfare molti possibili scenari di utilizzo, tendono ad essere troppo 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 software, è necessario valutare la tecnica rispetto al costo di utilizzo della tecnica e decidere se i benefici superano il costo.

A parità di altre condizioni, meno codice è sempre meglio. Ho attraversato architetture a più livelli in cui devi letteralmente fare da tre a sei salti attraverso più progetti per trovare qualsiasi codice interessante, vale a dire un codice che realizzi effettivamente qualcosa di diverso dall'aggiunta di overhead.

I modelli software ben noti dovrebbero darti un vocabolario comune con il quale puoi comunicare strategie di progettazione. Sfortunatamente, molti sviluppatori di software non comprendono abbastanza bene il vocabolario del modello di software per applicarlo correttamente ai loro problemi di programmazione. Gli sviluppatori inesperti vedono questi schemi all'interno del dominio degli esperti; vogliono essere visti come esperti e quindi cercano di imparare e applicare gli schemi troppo presto, prima che siano pronti. Quello che dovrebbero invece fare è concentrarsi sull'apprendimento dei fondamenti della programmazione prima, e poi tentare di risolvere il problema che ogni modello si risolve da solo. Se lo fanno, saranno in una posizione molto migliore per comprendere e applicare correttamente i modelli.


19
Bene, questo è un problema diverso da quello che stai descrivendo nella tua domanda. Il negozio in cui lavoro ora è la prova vivente che puoi essere agile e avere ancora un codice molto pulito e snello che è facile da mantenere, ma non è la solita roba multistrato aziendale che vedi nella maggior parte dei negozi Java, ed è abbastanza "non standard" nel suo approccio. Non abbiamo un anno per creare app nel modo "aziendale".
Robert Harvey,

34
@ Igneous01: Nota che ciò che un professore che non ha mai avuto alcuna esperienza nel mondo reale considera "buono" potrebbe variare radicalmente da ciò che un'azienda che cerca di fare soldi considera "buono".
Robert Harvey,

8
"Sfortunatamente, molti sviluppatori di software non comprendono abbastanza bene il vocabolario del modello di software per applicarlo correttamente ai loro problemi di programmazione." Questo sono io in breve. =) I pochi di cui ho visto i nomi, ho un momento estremamente difficile individuarne una reale implementazione. Probabilmente ho blocchi di codice che ho scritto che potrebbero essere classificati come schemi di implementazione, ma sicuramente non saprei dirti quali. Sono arrivato a pensare che gli schemi siano molto meno importanti del fatto che il codice sia effettivamente decifrabile e che i requisiti cambino solo in alcuni punti del codice.
jpmc26

35
Mentre pedanticamente mi metterò in discussione con "meno codice è sempre meglio" perché so che porta a un codice che sembra brainfuck , concordo con entusiasmo con il punto "modello vacabulary". Non lamentarti del fatto che il mio codice è una schifezza solo perché non riesci a trovarlo nel tuo libro di testo. Ci sono molte ragioni perfettamente valide per chiamare la mia merda di codice, ma non è una di queste.
candied_orange

23
"codice che realizza effettivamente qualcosa di diverso dall'aggiungere un sovraccarico" - Pensavo che l'obiettivo del software aziendale fosse che non ci sarebbe stato codice che realizzasse qualcosa . Qualsiasi comportamento effettivo che il software potrebbe avere, dovrebbe essere una proprietà emergente del design a strati, oppure dovrebbe essere guidato dalla tabella dalle regole aziendali che il codice considera come dati. Sto solo scherzando al 50%.
Steve Jessop,

86

Stackoverflow.SE e Programmers.SE incoraggiano principalmente le persone a seguire le migliori pratiche come SOLID, non standard di settore . E che ci crediate o no, lo standard di fatto del settore è spesso l' architettura "big ball of mud" - sul serio.

Ma per rispondere direttamente alla tua domanda: il problema con i modelli di progettazione è simile a quello dell'ereditarietà: molti sviluppatori mediocri li abusano, il che comporta un certo rischio di creare codice ingegnerizzato e difficile da mantenere. Ma la risposta a questa non è sicuramente quella di evitare o vietare completamente l'uso dei modelli di progettazione (o ereditarietà), la risposta sta imparando a usare questi strumenti in situazioni in cui hanno senso e solo lì. E questo è completamente indipendente dal lavoro "agile" o no.


Penso che la specificità della tua affermazione "il problema con i modelli di progettazione è simile a quello dell'ereditarietà - molti sviluppatori mediocri li abusano" non è necessario ... con tutti gli aspetti del codice, uno sviluppatore non istruito sull'uso corretto di qualcosa può e spesso lo abuserà e scriverà un codice non ottimale. Questo potrebbe essere considerato un assioma dello sviluppo in generale.
Jeremy Holovacs,

1
@JeremyHolovacs: non esattamente. Il problema che vedo è che persino gli sviluppatori istruiti li abusano. Ho visto troppo spesso soluzioni in cui gli sviluppatori esperti cercavano di risolvere un problema in uno schema che "in qualche modo" si adattava, ma non bene.
Doc Brown,

45
  1. I modelli di progettazione sono solo nomi usati per comunicare idee. Mi sono spesso trovato a fare cose che in seguito ho scoperto che hanno un nome. Pertanto, non esiste un "modo modello di progettazione" al contrario di un "modo modello non di progettazione".

  2. I modelli di progettazione sono linee guida. Come ogni cosa, 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 del tuo problema.

  3. Ogni migliore pratica e linea guida può essere ignorata se esiste una ragione sufficiente. Le ragioni valide includono i tempi di sviluppo e le aspettative dall'applicazione. Ad esempio, sono consapevole del fatto che è male codificare i valori (esempio stupido) ma per una dimostrazione del concetto, i vantaggi potrebbero superare i costi (in questo caso, principalmente i tempi di sviluppo). Tuttavia, se viene presa una decisione come questa, potrebbe fallire e ad un certo punto potrebbe essere necessario un refactoring.


5
RE: numero 1, sì, ci sono stato - ho inventato il modello di modello. Non l'ho fatto prima io. O qualcosa del genere prima.
Grimm The Opiner,

29

Per aggiungere un'altra metafora alla zuppa, i modelli di progettazione sono Clippy, l'helper di Microsoft Office. "Sembra che tu stia facendo la stessa cosa per un sacco di cose. Posso aiutarti in questo offrendoti Iteratore o Visitatore?"

Un buon resoconto di questi schemi indicherà quando è utile fare qualcosa nello stesso modo in cui è stato fatto molte volte prima, quali errori commetterai la prima volta che lo provi e quali modi comuni sono stati trovati 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 i maghi.

Dove le persone inesperte possono sbagliare e scrivere codice che non tiene conto della realtà, è quando pensano che il loro elenco di modelli di progettazione sia un elenco completo di tutti i possibili approcci per risolvere i problemi nel software e provano a progettare il codice collegando insieme il design modelli fino a quando non è finito. Un'altra cattiva tattica osservata in natura è quella di inserire un modello di progettazione in una situazione in cui non è realmente adatto, sulla base del fatto che il modello di progettazione "è la migliore pratica". No, potrebbe essere o meno la migliore pratica per la classe di problema che risolve effettivamente , ma non è certamente la migliore pratica per problemi che non riesce a risolvere, o per problemi che risolve solo introducendo complessità inutile quando esiste una soluzione più semplice .

Naturalmente è anche possibile che qualcuno eviti uno schema sulla base di YAGNI, poi si rende conto di averne bisogno e cerca a tentoni la soluzione normale. Questo di solito è (ma non sempre) peggio che realizzare il requisito dall'inizio, ed è per questo che anche nello sviluppo agile è frustrante quando i requisiti totalmente prevedibili non vengono scoperti in anticipo. Non posso essere stato l'unico programmatore C ++ a essere molto divertito dal fatto che Java inizialmente ha rifiutato i contenitori generici come inutilmente complessi, per poi ricollegarli in seguito.

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

L'aggiunta di un nuovo campo all'interfaccia utente / database / livello dati richiede 2-3 ore, mentre come nel suo codice impiega 30 minuti.

Non si può davvero discutere con questo: con questa metrica il suo design è molto meglio dell'altro. Che sia perché ha evitato i modelli di progettazione è discutibile, penso che sia più probabile perché ha considerato i giusti problemi del "mondo reale" durante la progettazione, e con il beneficio dell'esperienza è migliore nel suo lavoro rispetto a qualcuno armato solo di un libro di testo e alti ideali.

Quindi ha riconosciuto che qualsiasi modello che richiede di toccare molti punti diversi nel codice per aggiungere un campo è un cattivo modello per il lavoro, "semplifica l'aggiunta di campi" e non ha usato quei modelli. Le architetture a strati possono davvero soffrire in questo senso, ed è sbagliato usare i modelli di progettazione senza apprezzarne gli svantaggi.

Al contrario, quanto tempo occorre per scrivere una nuova interfaccia utente nel suo design e quanto tempo impiega un'architettura a strati? Se il progetto lo avesse richiesto di costruire e distribuire costantemente nuove interfacce utente su un modello di dati fisso, invece di aggiungere costantemente campi, si spera che avrebbe progettato invece per quello. O pure. Ma per tutti i suoi vantaggi, dire "stiamo facendo agili" purtroppo non significa che non dovrai mai fare un altro compromesso!

La selezione da un menu di modelli di design può certamente smettere di pensare alle preoccupazioni più importanti. Ma riconoscere quando scrivi un Visitatore e documentarlo o nominarlo "Visitatore" per aiutare i lettori a ottenerlo rapidamente, non ostacola molto nulla. Scrivere "this is a Visitor" invece di documentarlo correttamente è un terribile errore per il motivo che dà il tuo senior dev - i programmatori non lo capiranno. Anche i programmatori che sanno cosa sia un Visitatore hanno bisogno di più informazioni di un semplice "questo è un Visitatore".


5
"I motivi di design sono Clippy, l'aiutante di Microsoft Office" Stasera avrò degli incubi.
MetalMikester

"Dove le persone inesperte possono sbagliare [è quando] provano a progettare il codice collegando insieme i modelli di progettazione fino al termine." Senti senti. Vorrei avere più voti da dare. :)
Quuxplusone

Vorrei anche avere più voti per l'ultimo paragrafo. I modelli di progettazione sono il vocabolario della programmazione: sarai uno scrittore migliore e più chiaro se hai un vocabolario di grandi dimensioni. Posso dirlo a una Fabbrica da un Costruttore quando li vedo, ma non l'ho capito leggendo libri sugli schemi di progettazione, non più di quanto abbia imparato a distinguere una falesia da un bluff leggendo un dizionario inglese.
Quuxplusone,

20

Il tuo collega sembra soffrire della sindrome NIH ("Not Invented Here").

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

Evitare i modelli di progettazione è davvero sorprendente. Negli ultimi 30 anni di programmazione e gestione dei programmatori, i modelli di progettazione hanno contribuito a mettere le parole su cose che sono state fatte istintivamente, aiutando così a comprendere più rapidamente l'intento, i vantaggi, gli inconvenienti, il rischio, le opportunità e i relativi schemi. I modelli di progettazione si sono dimostrati 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 i modelli senza che si noti una riduzione della produttività?

  • Gli argomenti secondo cui "i programmatori non comprendono i modelli di progettazione" sembrano "Non riesco davvero a spiegare cosa sto facendo". O "Non voglio discutere del mio design". Penso davvero che la modellizzazione possa sfruttare la comprensione generale e consentire ai colleghi meno anziani di condividere opinioni preziose. Ma forse il tuo collega senior vuole evitare proprio questo.

Gli approcci a strati 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 superano le architetture artigianali per ordini di grandezza. Martin Fowler presenta questo approccio nel suo eccellente libro su "Patterns of enterprise architecture". Oh! Scusa ancora: si tratta di schemi comprovati; nessuna possibilità nella visione NIH del tuo collega ;-)


Sindrome NIH, interessante, non ne avevo mai sentito parlare prima. Evidentemente questo è il problema che la maggior parte dei datori di lavoro nordamericani si trova ad affrontare come gestire i propri dipendenti!
paga il

@pay Non sono sicuro che questo sia limitato al Nord America ;-) È sempre allettante cercare soluzioni che abbiamo già usato in passato con un certo successo. È la zona di comfort. Ma si dovrebbe sempre rimanere aperti a nuove idee e al dialogo costruttivo con colleghi stimolanti. Dopo tutto, " Viaggia più veloce da solo, ma più lontano insieme " .
Christophe,

16

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

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

La differenza chiave tra la progettazione software a cascata e quella agile è quando vengono prese le decisioni di progettazione. In cascata, raccogliamo tutti i requisiti, identifichiamo quali modelli di progettazione abbiamo bisogno e solo allora iniziamo a scrivere codice. Nell'architettura agile, seguiamo il principio YAGNI per rinviare le decisioni di progettazione fino all'ultimo momento responsabile, quando sappiamo quanto più possibile sulla scelta.

Cioè, a cascata, i modelli di design tendono ad essere applicati se il loro bisogno è anticipato , in agile, quando sono effettivamente necessari . Di conseguenza, i progetti agili tendono ad applicare gli schemi di progettazione meno spesso, poiché non tutte le esigenze previste sono effettive.


1
+1 per Design patterns are standard solutions to standard problems. Sono un po 'deluso dal non vederlo nelle risposte più votate. Ciò richiede quindi prima di tutto di identificare se il problema che stai affrontando corrisponde a un problema standard e, molto spesso, lo faranno sempre.
Walfrat,

8

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

Alla luce di ciò, a meno che non ti impegni veramente a scrivere il codice una tantum al 100%, dove nessun concetto o implementazione è utilizzabile da un caso d'uso all'altro, stai quasi sicuramente usando almeno alcuni modelli di progettazione. Potrebbero non avere nomi comuni appariscenti come "Repository" o "Unit of Work" o addirittura "MVC", ma ciò non li rende "non un modello di progettazione".


6

Di solito mi piace pensarlo nel modo di - diciamo - "navigazione" usando il GPS. Quando apprendi le "migliori pratiche" e i "modelli di progettazione", impari a seguire il percorso di navigazione GPS. Ma quando conosci la zona, imparerai spesso che guidare lungo una strada laterale ti porterà oltre le aree problematiche, ti porterà lì più velocemente e / o meglio. È quasi lo stesso quando si tratta di queste cose: l'esperienza ti rende in grado di decostruire la tua cassetta degli attrezzi e prendere scorciatoie.

Imparare i 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 avranno vincoli e problemi che non si trovano nei libri di testo. Clienti / Clienti vogliono il loro prodotto veloce e generalmente economico; Devi lavorare con il codice legacy; Devi 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 gli schemi sono più generali.

Uno dei motivi principali per cui molte persone su siti come SE ti daranno risposte "best practice" e risposte "design pattern" è che, poiché stanno rispondendo in soluzioni generali e astratte e quindi aiuta a fornire un linguaggio comune per risolvere un tipo di i problemi. E per farti imparare.

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


5

L'aggiunta di un nuovo campo all'interfaccia utente / database / livello dati richiede 2-3 ore, mentre come nel suo codice impiega 30 minuti.

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

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

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

  • Viste diverse dello stesso modello (la vista è indipendente dal modello)
  • Ogni strato può essere sviluppato separatamente (ad es. Da diversi team) e testato separatamente (unit test) prima dell'integrazione
  • eccetera.

Considerando che il suo codice potrebbe essere ottimizzato per qualcos'altro, ad esempio:

  • Linee minime di codice
  • Facile per una persona apportare un cambiamento che interessa tutti i livelli (non avendo livelli veramente distinti)
  • eccetera.

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


"non avendo livelli veramente distinti" o, per essere onesti, avendo un "comportamento predefinito" accettabile che si propaga attraverso i livelli. Ad esempio, le app di amministrazione SQL basate sul Web sono un livello di presentazione che si aggiorna automaticamente quando cambia il livello del database. È solo che, a parte per usi limitati, in realtà non presentano i tuoi dati come desideri che vengano presentati agli utenti :-) Mezz'ora sembra incredibilmente veloce per aggiungere un nuovo campo, suggerendo che non esiste un'interfaccia utente significativa in cui progettare connessione con il nuovo campo, a strati o in altro modo.
Steve Jessop,

4

I modelli di progettazione sono strumenti. Come gli strumenti, ci sono due modi per usarli: il modo corretto e il modo errato. 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 i chiodi, mentre i cacciaviti sono usati per le viti.

Troppo spesso, un modello di progettazione è pubblicizzato come One True Way, che è spesso vero solo quando sorgono problemi particolari. Gli sviluppatori junior sono spesso come 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 esso, finché alla fine imparano che il modello A si applica al problema B e il modello C si applica al problema D. Proprio come non si utilizza un cacciavite per guidare i chiodi, non si utilizza un particolare modello solo perché esiste; si utilizza il modello perché è lo strumento migliore (noto) per il lavoro.

Il rovescio della medaglia è rappresentato dagli anti-motivi. Cose che hanno dimostrato più volte di essere cattive, di solito in termini di tempo di esecuzione o memoria. Tuttavia, sia i pattern che gli anti-pattern non fanno bene allo sviluppatore che non capisce perché esistano. Agli sviluppatori piace pensare che ciò che stanno facendo sia nuovo e inventivo, ma il più delle volte non lo sono. Probabilmente è stato pensato prima. Le persone prima di loro hanno creato gli schemi grazie all'esperienza.

Ovviamente, gli sviluppatori junior sembrano spesso escogitare nuovi modi di fare cose vecchie, e talvolta quei modi 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 modelli perché si credono superiori, ma non sanno che, in realtà, 10.000 sviluppatori hanno già utilizzato un design specifico e lo hanno scartato perché in realtà era un problema.

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

Chiunque sostenga che i modelli siano La Via o che i modelli siano La rovina dell'esistenza, ha torto. I modelli sono strumenti, pensati per essere applicati a situazioni specifiche e hanno vari gradi di successo in base alle circostanze. Questa è una verità, che non dipende dal fatto che tu abbia scelto MVC o meno, se utilizzi gli oggetti Data Transfer o no, ecc. Ciò che conta è l'implementazione del codice in un intervallo di tempo ragionevolmente breve, che funziona ragionevolmente bene per gli utenti, ed è ragionevolmente privo di bug logici.

Di solito , i pattern consentiranno una forma coerente di design e avranno prestazioni migliori rispetto all'ignorare tutti i pattern a favore della scrittura di idee originali al 100%, ma non è possibile evitare tutti i pattern. Ad esempio, se y = x + 5, hai davvero intenzione di scrivere y = x + (5 * 3 + 15/3) / 4, solo per evitare lo schema di scrittura x + 5? No non siete. Scriverai y = x + 5 e passerai al problema successivo.

Le persone usano i modelli ogni giorno, e va bene . Ciò che conta di più è avere un codice logicamente funzionale, raramente si arresta in modo anomalo ed è intuitivo. Nient'altro conta più di questo.


Penso che l'avvertenza in questo caso siano situazioni che, in base alla tua comprensione "attuale" del problema e del dominio, puoi creare una nuova classe o seguire un modello che si applica alla situazione, ma poi il giorno successivo un cliente desidera che tu lo faccia effettuare personalizzazioni per loro in alcune piccole sfaccettature che altri clienti non vorranno nella loro versione. Consolidare una base di codice che si rivolge alle esigenze di 2 dozzine di clienti ed evita la copia della pasta sembra impossibile da realizzare. Mi sono appena imbattuto in questo oggi quando refactoring un vecchio processo di stampa unione.
Igneous01

2

Non puoi "evitare i modelli di progettazione", tranne che immagino evitando di progettare due parti del tuo sistema nello stesso modo (cosa che non consiglio e dubito che lo stia facendo lo sviluppatore senior). Ciò che probabilmente intende è "evitare di usare ciecamente un disegno solo perché aderisce a un modello di disegno". Pensare a quello che stai facendo è sicuramente una "best practice", e una università dovrebbe esistere per insegnare; purtroppo, ciò non sembra accadere.


2

I modelli di progettazione non sono antitetici alle pratiche agili. Ciò che è antitetico alle pratiche agili è usare i modelli di progettazione per motivi di utilizzo dei modelli di progettazione, la pratica comune tra neolaureati e studenti di pensare sulla falsariga di "come possiamo risolvere questo problema usando un modello di fabbrica".

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

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.