Progetta modelli soffocando la creatività

Molti anni fa, stavo parlando con un professore di Economia dei modelli di progettazione, di come stavano stabilendo un linguaggio comune per i programmatori e di come stavano risolvendo problemi noti in un modo carino, ecc. Ecc.

Poi mi ha risposto che questo è esattamente l'approccio opposto che userebbe per i suoi studenti di Economia. Di solito presentava un problema e chiedeva loro di trovare prima una soluzione, in modo che potessero prima pensarci e provare prima a trovare il modo di risolvere il problema, e solo dopo presentava la soluzione "classica".

Quindi stavo pensando se l'approccio del "modello di progettazione" è davvero qualcosa che rende i programmatori più intelligenti o più stupidi, dal momento che molte volte ottengono semplicemente la "soluzione giusta per questo problema" invece di usare la creatività e l'immaginazione per risolvere alcuni problemi in un modo nuovo e innovativo.

Cosa pensi?

Il tuo professore di economia ha assolutamente ragione.

I modelli di progettazione software sono principalmente un modo per gli sviluppatori di software esperti di comunicare tra loro . Sono una scorciatoia per soluzioni consolidate a problemi noti.

Ma dovrebbero essere usati solo da persone che capiscono come risolvere il problema senza lo schema, o che hanno escogitato uno schema simile da soli. Altrimenti, avranno lo stesso problema del codificatore copia / incolla; avranno codice, ma non capiranno come funziona e quindi non saranno in grado di risolverlo.

Inoltre, molti dei modelli di progettazione sono modelli aziendali , modelli che devono essere utilizzati in sistemi software aziendali di grandi dimensioni. Se impari le meraviglie del contenitore Inversion of Control, vorrai utilizzarlo in ogni programma che scrivi, anche se la maggior parte dei programmi non ne ha davvero bisogno (ci sono modi migliori per iniettare le tue dipendenze in programmi più piccoli, non richiede un contenitore IoC).

Impara gli schemi. Comprendere i modelli e il loro uso appropriato. Sapere come risolvere lo stesso problema senza lo schema (tutti gli schemi del software sono astrazioni rispetto agli algoritmi fondamentali). Quindi sarai in grado di utilizzare i modelli software con sicurezza, quando ha senso farlo.

Il modo in cui i pattern di design vogliono che le persone guardino i pattern di design è come un insieme di soluzioni che è possibile applicare in caso di problemi simili. Non vogliono che tu li consideri come le uniche soluzioni possibili, date da Dio a Mosè scolpite su tavolette di pietra sulla montagna.

Sfortunatamente, alcune persone li prendono come qualcosa di più vicino alla scrittura sacra piuttosto che a un mucchio di esempi di disegni che potrebbero essere appresi. Questo uccide la creatività e crea un culto del carico.

Il tuo professore di economia ha menzionato la presentazione del problema agli studenti e il loro tentativo di risolverlo prima, il che è una buona tecnica educativa, ma aveva una soluzione per mostrarli. Avere un sacco di soluzioni a molti problemi diversi nella tua testa è una buona cosa, ed è qualcosa che Design Patterns cerca di essere. Penso che fallisca in qualche modo (Singleton incoraggia i cattivi approcci, un'attenzione miope all'OO imperativo, ecc.), Ma potrebbe essere usato bene con intelligenza e gusto. Tuttavia, è un errore pensare che ogni possibile soluzione di esempio nel software debba essere un modello di progettazione ufficiale.

Se osservi un problema e ti chiedi "Qual è il modello di progettazione per questo?", Allora stai sbagliando e avrai meno probabilità di vedere una soluzione che ti sta fissando in faccia.

Se guardi un problema e ti chiedi "Come posso risolvere questo?", Allora se c'è una soluzione non-pattern, la vedrai e se c'è una pattern che si adatta, vedrai anche quello.

Penso anche che il tuo professore di economia sia corretto ed è un modo per imparare qualcosa in primo luogo; Comunque diamo un'occhiata a questo: manterresti la ruota segreta e permettere a tutti di reinventarla, per il bene della creatività ? Mi aspetto che tu dica di no, perché non tutte le persone sono fatte / capaci di inventare le loro ruote - e se lo sono, lo faranno ad un certo punto, non importa se sono a conoscenza dell'esistenza della ruota o non.

Torniamo ai programmatori; Sono uno sviluppatore web di giorno, quindi MVC è una di quelle cose con cui interagisco quotidianamente. Più volte ho provato a costruire le mie strutture, ho imparato molto, ma sostanzialmente non hanno avuto successo. Ho fatto del mio meglio, ma cosa accadrebbe se non ci fossero MVC là fuori? Bene, semplice, il mio codice sorgente fa schifo - in termini di affidabilità, manutenibilità ed estensibilità.

Penso che sia lo stesso per la maggior parte di noi. Se nessuno ti parla di DI - come buona pratica, quante applicazioni aziendali dovrebbero lottare o fallire fino a quando i loro sviluppatori non imparano la lezione?

Il secondo punto sono gli standard del settore . Se non insegnerai MVC agli sviluppatori web, allora sei pronto ad affrontare tutte quelle strutture non standard di cui hai bisogno per passare un po 'di tempo per imparare prima il loro modo di fare le cose, e poi ti rendi conto che alcune di quelle strutture potrebbero avere una buona idea, ma la maggior parte di essi presenterà gravi difetti di progettazione che potrebbero avere gravi conseguenze per il proprio progetto software - anche i quadri noti continuano a lottare con i difetti di progettazione di volta in volta.

Ma cosa accadrebbe se avessimo tutte quelle idee carine e le mettessimo tutte insieme e quegli sviluppatori intelligenti prendano le cose buone da tutti quegli esperimenti e creiamo una struttura davvero interessante che funziona meglio per quel problema specifico? Quindi hai appena creato i motivi di disegno . Se sei una creatura vivente, non c'è altro modo per aggirare; Anche gli animali seguono le migliori pratiche e i modelli di progettazione nella loro vita quotidiana.

Non reinventare un martello, ma non trattare tutti i problemi come un chiodo

Gli schemi di programmazione fanno risparmiare molto tempo, perché offrono soluzioni pronte per l'uso, ben documentate e testate con casi medi di cui potresti facilmente dimenticare. Ma devi imparare (e pensare) quando usarli.

Parafrasando la tua domanda: imparare a guidare mi farebbe muovere più velocemente o camminare più lentamente?

Imparare a usare il modello di programmazione non significa che non dovresti allenarti a trovare le proprie soluzioni. Ci saranno ancora abbastanza problemi su cui esercitare la tua creatività. Conoscere gli schemi di programmazione ti consentirà di essere veloce solo con problemi noti e concentrarti su quelli che sono meno banali.

Tornando alla seconda parte della tua domanda - il tuo proffesor ha ragione?

Sì, ha ragione . L'obiettivo primario degli studi è imparare gli studenti a pensare . Devono cercare di trovare le proprie soluzioni al problema e confrontarle con le soluzioni esistenti. Solo in questo modo possono davvero capirli. Se prima impari loro gli schemi, rischi che impareranno solo meccanicamente ad applicarli e non a capire cosa c'è dietro.

Questa è la ragione per la prima volta che insegni agli studenti a programmare, e gli schemi vengono introdotti in ulteriori semestri.

Vorrei assolutamente sconsigliare l'insegnamento della programmazione insegnando modelli di progettazione. Non puoi applicarli bene senza comprendere i principi che li stanno dietro, quindi insegnare quei principi è molto più importante.

Tendo a pensare che i modelli di progettazione non siano davvero così preziosi neanche per i programmatori che lavorano. Se capisci appieno i principi coinvolti in un determinato modello di progettazione, quindi in una situazione in cui è una buona soluzione tenderai naturalmente a costruirlo (o qualcosa di simile) comunque, ovviamente, anche se non lo sapevi che era uno schema con un nome. Indipendentemente dal tempo che passeresti, i modelli di apprendimento potrebbero essere spesi meglio imparando a pensare al codice in generale. Se le tue abilità di "problem solving in generale" non sono all'altezza, allora non puoi scrivere un buon codice, non importa quanto tu sia bravo ad applicare una serie di schemi. E se le tue abilità di "problem solving in generale" sono buone, allora puoi risolvere i problemi anche se non conosci un singolo schema.

Penso anche che in un mondo ideale non ci sarebbe essere eventuali modelli di progettazione, perché le idee abbastanza comune per essere chiamato un modello tutto sarebbe ben implementato, nelle biblioteche e ci piacerebbe davvero essere il riutilizzo di codice, invece di costante riscrittura esso. Immagina se esistesse un "modello di progettazione di espressioni regolari", che richiedeva l'implementazione di un piccolo motore regex ogni volta che lo volevi usare. I modelli di progettazione sono solo librerie che non possono essere scritte perché la lingua non fornisce le giuste strutture di astrazione.

Questo è in realtà un altro motivo per cui non importa molto di loro; non sono affatto universali come si dice a volte, ma in realtà sono fortemente legati ai modi particolari di strutturare i programmi che una determinata lingua consente / incoraggia. Un libro di modelli di design scritto per Python sarebbe completamente diverso da uno scritto per Java, e ancora più diverso da uno scritto per un linguaggio non imperativo come Haskell. Meglio capire a un livello più profondo, e sarai in grado di scoprire tu stesso i modelli di progettazione in qualsiasi lingua con cui acquisisci familiarità.

Il commercio e l'istruzione hanno obiettivi diversi. Se insegnassi agli studenti modelli di progettazione, prenderei lo stesso approccio. Ma in un ambiente di produzione, tempo ed efficienza sono tutto.

Inoltre, (macro) economia al di fuori della classe è una cosa diversa. Vedi i governi dire: "Whoa! Ora siamo molto annoiati di fare le tasse e allo stesso modo, quindi proviamo qualcosa di super stravagante questa volta"? No, perché tali esperimenti selvaggi possono distruggere l'economia senza possibilità di riparazione. Al contrario, tendono ad attenersi ad approcci collaudati: aumentare il tasso di interesse, annunciare le esenzioni fiscali, ecc. In altre parole, si basano su schemi di progettazione.

La risposta è, ovviamente: Sì.

I modelli di progettazione sono uno strumento di apprendimento meraviglioso in sé, purché ci si prenda il tempo per capire come funzionano e perché apportano il valore che apportano.

Possono anche essere ottimi stimolatori della produttività seguendo rapidamente un processo di progettazione, poiché forniscono soluzioni familiari ai problemi che si presentano continuamente.

Tuttavia, se progettano troppo cortocircuito o le persone diventano dogmatiche e troppo precise riguardo al loro uso, allora hanno l'effetto opposto.

I modelli di progettazione sono ovviamente meno creativi. Questa è l'intera idea. La creatività è una risorsa scarsa. Non dovresti sprecarlo per problemi che non richiedono creatività. È molto più facile, più veloce e più probabile che funzioni, se risolvi un problema come centinaia di sviluppatori prima di te. Il codice noioso e poco emozionante che fa il suo lavoro è in realtà buono.