SOLID em frontend

[leandroruel]

recentemente vi uma vaga de emprego pedindo como um dos pré-requisitos conhecimento em SOLID, gostaria de saber dos colegas se vocês implementam esses princípios em suas empresas, se não, se fazem algo próximo, e se isso é tão importante ou se depende da empresa ou produto com que trabalham.

[danilomilan]

então, na empresa em que trabalho, estamos começando a colocar em pratica esse conhecimento e adicionando também os testes automatizados, e com certeza ajuda e MUITO na manutenção do código. Vale muito a pena.

[cristofersousa]

Estive lendo esses dias sobre isso também que vi algumas vagas solicitando os conceitos de SOLID.

Pelo que sei tem o livro Clean Code do Tio Bob que aborda isso e tem um repo aqui no github que aborda para JS CleanCode.

[rubenmarcus]

https://medium.com/@cramirez92/s-o-l-i-d-the-first-5-priciples-of-object-oriented-design-with-javascript-790f6ac9b9fa

https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design

https://thefullstack.xyz/solid-javascript/

[mikejavier]

Antes de ser back ou front, você é desenvolvedor e não importa qual seja a linguagem é sua obrigação....

• Utilizar as boas praticas de engenharia de software (SOLID, YANGI, KISS).
• Algoritmos e dados estruturados
• Controle de versão (git)
• O basico de terminal e ssh
• Http/https e APIs (hoje em dia tudo esta na web)
• TDD

Se quiser desenvolver entregando valor ao cliente...

• Metodologias ágeis (kanban, scrum, XP)

O livro que recomento muito é CleanCode que o @cristofersousa postou o link.

[ninetails]

Acho o livro meio hype, pq nada mais é que um apanhado de n outros livros, ou seja, é tipo ler um resumo, porém nem por isso tiro a importância dele.

Mas saber diria que é muito mais por excelência, se a vaga pede, é pq geralmente neste lugar há (ou deveria haver) uma boa cultura de Code Review e certa importância por manutenção de código.

Não acho que isso seja algo adequado a uma vaga junior por exemplo, mas é bom saber dele e da importância, tais como Design Patterns, testes...

Pessoalmente, acho que SOLID seria muito mais uma consequência de se aprender a programar bem + guideline (como ele mesmo diz, princípios) que uma ferramenta em si, algo que vc adquire após leituras e amadurecimento no código.

[felipeuntill]

Sua dúvida meio que encaixa com a issue #568.

Eu sou backend e meu conhecimento técnico foi maturado em cima de linguagens verbosas (C#/Java) portanto não consigo fugir dos padrões e acabo aplicando sempre que possível.

Mas olhando projetos de grande porte que possuem código aberto, vejo que a abordagem dos times de front é sempre a mais simples/funcional possível.

Hoje entendo que existe um limiar muito curto entre os dois valores e que na maioria dos casos aplicar design patterns no front-end é over-engineering!

[rubenmarcus]

Alguém conhece o Alberto Caçapava da Sprinklr? Ano passado fui num meetup de Front na Viva Real ,e a palestra dele era sobre Solid, e foi uma baita palestra, eu queria o conteúdo da palestra dele, pra ter aqui como acervo, e ele poder também falar um pouco mais... é da galera do Front-end SP Meetup

[AlexsandroSA]

Front-end é um programador, logo, todo programador - ao meu ver - tem que estudar esses conceitos SOLID, Design patterns e etc.

Teu código vai ficar muito melhor!

Tem um livro que todo deve deveria ler - na minha opiniçao - que é o Código Limpo e o Codificador limpo, não só ler, aplicar os conceitos e tu com certeza vai ser um programador melhor!

[simaodeveloper]

@rubenmarcus este mano -> @albertossilva

[albertossilva]

Eae galera, o @simaodeveloper me achou no Twitter... vou ver se eu acho a palestra no outro PC... Sobre SOLID, é isso aí mesmo... Se conseguirem aplicar bem o S e O... já um baita progresso.

Sobre Design patterns e over-engineering @felipeuntill, acredito que não seja os Design Patterns em si, mas sim porque foi mais engenharia do que precisava mesmo.

Se pegarmos como exemplo um component react que só faz renderização mesmo, e esta lá só para receber props e printar alguma coisa, não precisar usar classe e extender do componente do React, no caso aqui, seria usar não o design pattern template method que é oferecido pela biblioteca do React para coisas mais complexas.

Mas o mesmo vale para o backend... aplicar mais as coisas pela demanda, do que ficar "engenharizando"
E decidir quando aplicar uma técnica mais avançada (Design Pattern por exemplo) pela demanda é algo que leva tempo para se construir, é um feeling muito sútil. Como em todos as áreas a maior parte dos profissionais ainda não atingiu, digamos, um certo nível desse feeling, é normal que aparece esse monte de over-engineering.