Olhando por cima parece uma solução alternativa mas na verdade é apenas complementar, o problema que o post resolve não é simplesmente uma biblioteca externa mas a quantidade de pontos onde é necessário mudanças se a biblioteca for alterada, vamos supor que se use a sua solução, biblioteca built-in, mas e se precisar, por qualquer motivo que seja, mudar a biblioteca? Como fica?
Respondendo a "Primeiro, parabéns pelo post e solução! Essa do..." dentro da publicação O seu projeto é viciado? 💉💻
2
2
Excelente ponto. Sua análise está absolutamente correta.
Independentemente de estar usando uma biblioteca de terceiros ou outro "módulo" do software, a regra de ouro sempre foi comunique-se através de uma interface estável.
Mas o "x da questão" é:
comecei a reparar em algo que tem me incomodado: a dependência excessiva de libs externas.
Sua pergunta, "Como fica se precisar mudar a biblioteca?"
A mudança se torna uma tarefa de engenharia, e não um ato de desespero. Você tem o luxo de planejar a substituição, talvez até manter as duas versões coexistindo durante um período de transição, e finalmente realizar um "decommissioning" da versão antiga.
O oposto disso é ter que reescrever centenas de chamadas às pressas porque o projeto quebrou em produção depois que dependência falhou.
2
Muitíssimo obrigado pelo feedback, pessoal! Estou realmente feliz com essa discussão.
O ponto central que percebi é o uso excessivo de bibliotecas externas espalhadas pelo projeto. Não tenho nada contra libs em si, mas quando elas estão profundamente entranhadas no código, qualquer alteração se torna complicada e arriscada.
Entendo o argumento de trazer o código externo para dentro do projeto, assumindo a responsabilidade de mantê-lo. Mas existem alguns contras:
No contexto atual, não usar libs externas muitas vezes equivale a improdutividade. Prazos apertados, times desalinhados e sem comando central tornam o trabalho caótico.
Muitas libs são enormes; você quer apenas a funcionalidade, não ler e manter toda a base de código. Vulnerabilidades surgem, atualizações são constantes — manter tudo manualmente dentro do projeto é um retrabalho enorme.
Mesmo trazendo o código para dentro, manter a lib isolada facilita atualizar e substituir versões, sem quebrar padrões de uso, props ou instâncias.
Dito isso, sou super a favor de código próprio. Quase todos os componentes que uso eu crio do zero: entendo, controlo e distribuo como preciso. É muito mais produtivo no meu contexto.
Mas em alguns casos, não aproveitar recursos externos é contraproducente. Um bom exemplo é o SDK do Jitsi para videoconferências: reinventar algo tão robusto seria perda de tempo, mesmo que fosse implementada uma camada de domínio própria para centralizar o uso.
Então, minha visão é que libs externas são válidas, desde que bem abstraídas e gerenciáveis, para não tornar qualquer alteração ou atualização uma emergência.
No fim das contas, gosto de lembrar de uma frase que resume bem:
Se você quer realmente fazer uma torta de maçã do zero, terá que recriar o universo primeiro.
1
Sim, meu comentario obviamente foi uma provocação, não existe bala de prata! Mas aqui vai mais uma então:
Muitas libs são enormes; você quer apenas a funcionalidade
Isso normalmente é um enorme indicativo que voce não precisa da lib em qeustão ;)
Use e abuse de SDKs oficiais e da biblioteca padrão do seu runtime, mas todo cuidado é pouco com codigo "desconhecido".
1
Cirúrgico, e novamente muito grato por essa interação, já pensando no que posso trazer como novo post.