Non riesco a cogliere schemi di progettazione della programmazione

I modelli di progettazione software sono soluzioni ben note a problemi noti. Il modo in cui li capisci è imparando i modelli, comprendendo come funzionano e sapendo quando è opportuno applicarli singolarmente alla progettazione del tuo software.

Il modo in cui apprendi i modelli di progettazione del software è studiandoli, uno alla volta. È un processo di formazione continua. Se vuoi ridurre l'impronta di apprendimento, studia i modelli che riguardano direttamente le tecnologie che stai utilizzando attualmente.

Alcune cose importanti da sapere sui modelli di design:

1. Alcuni modelli di design sono di natura architettonica. MVC e MVVM sono esempi di tali modelli. Usi tali schemi quando hai bisogno dei benefici organizzativi e strutturali che forniscono.

2. Alcuni pattern di progettazione sono soluzioni alternative per le carenze nei linguaggi di programmazione. Non avrai bisogno di questi pattern se utilizzi un linguaggio di programmazione più espressivo, ma spesso non riesci a farlo scelta. La maggior parte dei modelli GoF sono in questa categoria .

3. Utilizza un pattern software solo quando stai provando a a risolvere il problema che il pattern è specificamente progettato per risolvere. Se stai scrivendo un'applicazione cucendo insieme pattern software, stai sbagliando.

4. Non esiste un modello software esistente per ogni problema di calcolo esistente. Se fosse così, la programmazione sarebbe semplicemente un esercizio di abbinamento del modello.

5. Alcuni pattern sono in realtà anti-pattern. la complessità aggiuntiva introdotta da questi modelli supera i vantaggi che forniscono. Dovrai decidere tu stesso, in base a un modello per modello, quale di questi modelli eviterai.

L'approccio di tutti all'apprendimento è un po 'diverso, e non ho idea di quale sia il tuo approccio generale, ma credo che tu ti stia comportando da disertore etichettandoti come "stupido".

Personalmente, dalle mie osservazioni su ciò che molti chiamerebbero ingegneri del software "di successo", i progettisti ecc. hanno tutti un tema comune al loro apprendimento: "esperienza". Credo che questa sia la tua "educazione superiore" e imparerai più velocemente da essa che acquistare tonnellate di libri da Amazon e leggerli (una mia cattiva abitudine).

Quindi, ad esempio, prendi un pattern GOF come lo schema di comando e implementalo nella tua scelta della lingua. Comprendi quali benefici ti offre e quali sono gli svantaggi. I vari libri sui modelli di progettazione ti spiegheranno questo, ma ritengo sia meglio applicare tale conoscenza praticamente e imparare da essa. Non sconto sul materiale di lettura, hanno uno scopo, ma il mondo dell'IT non è quasi un esercizio da manuale. Detto questo, questa è la mia opinione e visione del mondo dell'IT e, in parte, rappresenta le proprie lotte all'inizio della mia carriera nell'ingegneria del software. Inoltre, un grosso problema che vedo, anche con sviluppatori di software molto esperti, è l'impazienza e l'oblio di godere di quello che stanno facendo. Quindi prenditi il tuo tempo con ciò che stai imparando e ricordati di apprezzare ciò che stai facendo, altrimenti perché perdere tempo ad investire in esso?

Inoltre, fai uso dell'esperienza pratica di altre persone. Ci sono una miriade di soluzioni open source, sia cattive che buone e puoi imparare da loro. Guarda come hanno applicato i pattern e pensa a come lo affronterai in modo diverso.

Quindi, il mio consiglio generale è se senti che il tuo approccio è sbagliato, cambialo. Guarda le persone intorno a te che ritieni stiano imparando il materiale che senti di non afferrare e guardare quello che stanno facendo o persino chiedere loro.

La risposta breve è che non hai bisogno di loro. Puoi scrivere codice senza di loro. Come ha detto Matthew nei commenti questo è particolarmente vero in JavaScript, dove la lingua è abbastanza flessibile e i progetti tendono ad essere più piccoli. Ma se hai programmato per 4 anni, trovo difficile credere che tu non sia incappato in cose che si sentono ripetitive o imbarazzanti. Sono quelle aree che stai riscoprendo o perdendo modelli di design.

Esempio: il sistema di eventi di JavaScript è spesso inadeguato all'attività in corso. Non ti sei mai ritrovato a voler combinare o trasformare stream di eventi? O quella serie di eventi erano valori di prima classe a pieno titolo? Hai bisogno dei modelli di Mediatore e / o Osservatore. Hai bisogno di un collegamento dati bidirezionale? Stessa storia.

La gerarchia dei prototipi fragili è finita? Mixin / Trait / Sottoclasse Schemi di fabbrica per il salvataggio.

Trova un mentore, qualcuno con una buona esperienza da cui imparare. Fai una domanda a lui, osserva il suo codice, invia una recensione del codice e prova a collaborare con lui. Questo è il modo migliore per migliorare le tue capacità di codifica.

in più:

• Collabora ad un semplice progetto OSS che ti piace

• Quando ci sono due modi per risolvere lo stesso problema, scegli sempre il più semplice

• Costruisci alcune esperienze extra con progetti secondari in cui sei libero di fare ogni tipo di errore strano e imparerai il modello di progettazione "nel modo più duro" (tm)