Arquitetura Front-End: Dependências

Caio Vaccaro

Decidi escrever este artigo quando vi um tweet no meu feed:

Para contexto, vale definir que este post é mais relevante para projetos grandes. Nesse caso, basta considerar algumas características:

  • Ser vital para um negócio (start-up inclusive), algum canal como aquisição, geração de lead ou atendimento.
  • Possui vida longa, já está ou provavelmente ficará mais de 5 ou 10 anos no ar, pelo menos.
  • Depende de um número considerável de profissionais.

Em um artigo anterior, mencionei algumas coisas sobre complexidade, sendo esta a imagem principal:

Porém, cada unidade não precisa ser uma pessoa, pode ser também um projeto, módulo, biblioteca, ou mesmo uma função no seu código.


Vale a pena usar uma analogia. Todos nós estamos acostumados a nos alimentar seguindo um determinado padrão, uma certa distribuição de carboidratos, proteínas, vitaminas e sais minerais. Suponha que exista um procedimento médico, em que você pode resetar completamente as necessidades biológicas do seu corpo, e re-estabelecer quais alimentos você precisa para sobreviver, como você escolheria?

Talvez você fosse direto ao ponto e escolhesse os alimentos preferidos. Ou, refletisse que:

  • Todo alimento, precisa ser adquirido em algum lugar.
  • Você não sabe de antemão onde vai morar na vida inteira, então é bom pensar em alimentos que possam ser cultivados em boa parte do mundo.
  • A matéria prima desse alimento é finita?
  • Quem cuida de todo processamento para garantir que você sempre vai ter comida?
  • Se for industrializado, pertence à uma cadeia de fornecimento, que depende de uma logística de abastecimento.
  • E assim por diante.

Um software já depende de várias coisas:

E a camada de aplicação, que precisa ser desenvolvida e programada (e é o contexto desse artigo), também:

A questão com dependências, é decidir o quanto “não reinventar a roda”, e o quanto aumentar a complexidade de dependência do seu projeto.


Exemplo de commit e quantidade de contribuidores no projeto React.
  1. Considere quanto tempo você levaria para desenvolver do zero uma solução que já exista, ou seja, quanto tempo livre essa dependência está dando ao projeto.
  2. Pense se tal funcionalidade precisa de muita manutenção ou não, e se você vai ter condição de fornecê-la. Veja se o projeto é ativo, tem contribuidores e uma comunidade.
  3. Nem sempre dependências são open-source, considere também o valor de um módulo pago e com manutenção e suporte garantidos.
  4. Reflita sobre a possível necessidade de refactor futura, se tal módulo deixa você preso (lock-in) ao mesmo, aumentando o custo de refatoração.
  5. Vejas dependências do módulo que você quer, elas são estáveis? É possível que atualizações terceiras quebrem sua dependência.
  6. E por fim, veja qual alternativa é menos complexa em termos de conhecimento técnico, quanto tempo de onboarding cada desenvolvedor precisaria?

Em resumo, é um bom conselho não adicionar dependências em projetos sem planejamento e pesquisa. Quanto mais dependências menor a chance de estabilidade à longo prazo. Sempre vale lembrar do ocorrido com o leftpad.


Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade