Compreender design patterns

[abensur]

Tenho trabalhado com javascript nos últimos 4 anos. Estou bem seguro das minhas habilidades em resolver problemas e consigo observar que a qualidade do meu código têm aumentado. Me preocupo em estar atualizado com a comunidade e tento usar sempre o que têm de mais novo, mas sinto que não consigo compreender design patterns do mesmo jeito que consegui compreender os diferentes tipos de layout models em CSS ou como funcionam regex. Sei onde buscar referências no assunto e já li livros sobre o mesmo. Atualmente, dependo dos meus colegas seniors para tomar decisões estruturais sobre algum projeto mas não tenho problemas em trabalhar em cima delas.

Sempre que preciso começar um projeto sozinho eu procuro seguir um desses dois caminhos: Se estou usando uma library/framwork grande, como React.js ou Angular, me inclino a copiar o que a comunidade está fazendo; Se estou fazendo algo menor, fico com o module pattern. Eu sei que uma vez que eu tiver um melhor entendimento no assunto vou ser capaz de fazer escolhas mais apropriadas mas no momento estou perdido.

O que eu devo fazer para cair a ficha desse assunto? Devo buscar uma formação superior? Esse assunto é realmente difícil entender?

obs.: Não estou me referindo à design patterns óbvios como loops ou funções mas sim dos GoF Patterns.

[RicardoJunior]

@abensur Isso é um problema foda mesmo, geralmente os patterns se contradizem um com o outro, como por exemplo 'prototype pattern vs constructor pattern vs dynamic pattern' é tipo falar ' é igual mass é diferente ', o conceito é aproximado porém a forma de estruturação conceitual é diferente, e no final das contas, as suas dúvidas são causadas por falta de conteúdo, pq a diferenciação você ganha com a experiência de uso do pattern/framework. Talvez o seu problema venha de um escopo bem maior do que parece. E não, formação superior não vai resolver o seu problema, e esse assunto é realmente difícil de entender sim, pq você pode entender todos, mas na hora de aplicar você vai ter experiência em poucos. Precisamos pensar mais pra achar uma forma pra resolver isso, eu não acho que resolveria lendo livros do Addy Osmani, etc... Não que não ajude, porém não resolve, não com questão de experiência prática.

• Acho que eu fiquei meio confuso pra me explicar, mas vou voltar com uma resposta mais completa, precisamos refletir.

[woliveiras]

@abensur, você diz sobre criar componentes reutilizáveis, pensar em escalabilidade, manutenção de código, manter um code style quando trabalhando em grupo, etc?

Creio que seu problema esteja em pensar em Arquitetura de Software e não, somente, compreender Padrões de Projetos e quando utilizar cada padrão.

[abensur]

@woliveiras não disse nada sobre isso, aliás já faço todas essas coisas (componentes reutilizáveis, pensar em escalabilidade/manutenção, codestyle, etc.).
Não sei o que você entende por Design Patterns, mas eu coloquei um link justamente por ser vago demais.

Alguns Design Patterns são arquitetônicos por natureza, como MVC, o MVVM ou um Redux/Reflux. Esses são relativamente fáceis de compreender pois são evidentes os benefícios estruturais e organizacionais desse tipo de pattern.
Já outros design patterns são quebra-galhos para as deficiências na linguagem e é justamente nesse quesito que me carece compreensão.

[woliveiras]

Saquei @abensur!

[alanhr]

@abensur no começo eu também tinha muitas duvidas de quando usar um pattern do Gof porem, isso ficou claro para mim quando eu comecei a me perguntar : "Esse código é muito parecido com aquele outro porque não usar uma estrategia = Strategy " ou "Eu preciso que isso seja que nem uma cadeia de chamadas se uma condição não atender ele vai chamar outra ate chegar na que atenda = Chain of responsibility ".
Dessa maneira hoje em dia eu consigo usar patterns de uma forma muito fácil.
Espero ter ajudado.