“a Mudança é a única constante…” – Heráclito (Filósofo)
As ferramentas, bibliotecas e frameworks utilizamos em nossas aplicações web de hoje são drasticamente diferentes das que usamos apenas poucos anos atrás.
em poucos anos a partir de agora, a maioria destas tecnologias terá mudado dramaticamente novamente. No entanto, muitos de nós fazemos disso uma parte central e inextricável de nossos aplicativos.
nós importamos, usamos e herdamos dos framewor-of-the-month como se todos eles fossem estar ao redor e inalterados para sempre. Bem … não são. E isso é um problema.Depois de mais de 20 anos de desenvolvimento, design e arquitetura de aplicações web, aprendi a apreciar duas verdades importantes.:
- as dependências externas representam uma grande ameaça para a estabilidade e viabilidade a longo prazo de qualquer aplicação.
- é cada vez mais difícil — se não impossível — construir qualquer tipo de aplicativo não-trivial sem alavancar dependências externas.
este artigo trata-se de conciliar estas duas verdades para que os nossos aplicativos tenham a maior chance de sobrevivência a longo prazo.A Toca do coelho é muito profunda.
Se começarmos a pensar em todas as coisas que nossos aplicativos web dependem é fácil de pensar em uma dúzia ou mais antes mesmo de chegar ao código:
- > Alimentação
- Conectividade
- Firewall
- DNS
- Hardware do Servidor (CPU, Disco, memória Ram, …)
- Refrigeração
- Plataforma de Virtualização
- Contêiner Plataforma
- Sistema Operacional
- Plataforma de Servidor Web
- Servidor de Aplicativo da Plataforma
- Navegador
Como desenvolvedores, é bom estar ciente dessas coisas, mas não há, muitas vezes, não há muito que possamos fazer sobre eles. Então, vamos ignorá-los por agora e falar apenas sobre o código.
em código, existem três tipos de dependências:
1. Dependências que controlamos
este é um código escrito e de propriedade de nós ou da nossa organização.
2. Dependências que não controlamos
este é um código escrito por um fornecedor de terceiros ou comunidade de software de código aberto.
3. Dependências uma vez removidas
estas são as dependências de código das quais as dependências de código de terceiros dependem. (Diga isso três vezes rápido!)
vamos falar principalmente sobre dependências que não controlamos.
dependências que controlamos e dependências uma vez removidas ainda podem causar dores de cabeça, mas no caso de dependências que controlamos, devemos ser capazes de intervir diretamente e mitigar quaisquer problemas.
no caso de dependências uma vez removidas, podemos geralmente contar com um terceiro para cuidar dele para nós, uma vez que eles são dependentes destes, também.
Why third-party code dependencies are good
uma grande parte de sua aplicação web existe para resolver problemas comuns: autenticação, autorização, acesso aos dados, Tratamento de erros, navegação, registo, encriptação, visualização de uma lista de itens, validação de entradas do formulário, e assim por diante…
independentemente de qual pilha de tecnologia você usa, há uma boa chance de que soluções comuns para esses problemas existem, e estão disponíveis como bibliotecas que você pode facilmente adquirir e plug-in para a sua base de código. Escrever qualquer uma destas coisas completamente do zero é geralmente uma perda de tempo.
deve concentrar-se num código que resolva um problema pouco comum ou resolva um problema comum de uma forma pouco frequente. É isso que torna a sua aplicação valiosa: o código que implementa as regras de negócio que são únicas apenas para o seu aplicativo — o “molho secreto”.”
Google search and page ranking algorithm, Facebook timeline filtering, Netflix’s “recommended for you” section and data compression algorithms— the code behind all of these features is “secret sauce.”
código de terceiros — na forma de bibliotecas-lhe permite implementar rapidamente essas características mercantilizadas de seu aplicativo, para que você possa ficar focado no seu “molho secreto”.”
Por que o código de terceiros dependências são ruins
dê uma olhada em qualquer não-trivial de web-app construído no último par de anos e você vai ser absolutamente surpresa com a quantidade de código que realmente vem a partir de uma biblioteca de terceiros. E se uma ou mais dessas bibliotecas de terceiros mudarem drasticamente, desaparecerem ou quebrarem?Se for de código aberto, talvez possa consertá-lo você mesmo. Mas até que ponto compreende o código que não possui na biblioteca? Uma grande razão pela qual você usa uma biblioteca em primeiro lugar é para obter os benefícios do código sem ter que se preocupar com todos os detalhes. Mas agora estás preso. Amarraste completamente a tua fortuna a estas dependências que não possuis e que não controlas.
um antigo cliente meu construiu o seu aplicativo usando um Backend-as-a-Service provedor de propriedade do Facebook, chamado Parse. Eles usaram uma biblioteca cliente JavaScript fornecida pelo Parse para consumir o serviço Parse. No processo, eles uniram todos os seus códigos-incluindo o código do “molho secreto” – a esta biblioteca.Três meses após o lançamento inicial do produto do meu cliente — assim que começaram a ter boa tração com clientes reais e pagantes — a Parse anunciou que estava a fechar.
agora, em vez de se concentrar em iterar o seu produto e crescer a sua base de clientes, o meu cliente teve de descobrir como migrar para uma versão de Parse auto-hospedada, de código aberto, ou substituir o Parse completamente.
the disruption this caused for a young, incipiente application was so huge that my client eventually scrapp entirely.
equilibrar o bem e o mal
Vários anos atrás, meu ir-a solução para superar os riscos mantendo os benefícios de terceiros-bibliotecas foi envolvê-los usando o Adaptador Padrão.
essencialmente, você enrola o código de terceiros em uma classe adaptadora ou módulo que você escreveu. Isso então funciona para expor as funções das bibliotecas de terceiros de uma maneira que você controla.
usando este padrão, se uma biblioteca de terceiros ou framework muda, ou desaparece, você só tem que corrigir um pouco de código adaptador. O resto da sua aplicação permanece intacta.
isto soa bem no papel. Quando você tem dependências auto-contidas que apenas fornecem algumas funções, isso vai fazer o truque. Mas as coisas podem ficar feias depressa.Consegue imaginar ter de embrulhar toda a biblioteca React (incluindo o JSX) antes de a usar? Que tal embrulhar jQuery, Angular, ou a mola em Java? Isto rapidamente se torna um pesadelo.
Esses dias eu recomendo uma abordagem mais sutil…
Para cada dependência que você deseja adicionar à sua base de código, avaliar o nível de risco que ele vai apresentar pela multiplicação de dois fatores:
- A probabilidade de que a dependência vai mudar de uma forma material.
- a quantidade de danos que uma mudança material da dependência faria à sua aplicação.
uma biblioteca ou estrutura de terceiros é menos provável de mudar quando algumas ou todas as seguintes coisas são verdadeiras:
- ele existe há vários anos e teve vários lançamentos importantes.
- é amplamente utilizado por muitas aplicações comerciais.
- tem o apoio activo de uma grande organização — de preferência uma empresa ou instituição de nome familiar.
Uma biblioteca de terceiros ou quadro vai fazer menos dano para a sua aplicação quando algumas ou todas as seguintes coisas são verdadeiras:
- É usado apenas por uma pequena porção de sua aplicação, em vez de ser utilizado.
- o código que depende dele não faz parte do “molho secreto” de que falei anteriormente.
- removê-lo requer alterações mínimas na sua base de código.
- toda a sua aplicação é muito pequena e pode ser reescrita rapidamente. (Tenha cuidado com este-raramente é verdade por muito tempo.)
quanto mais arriscado algo é, mais provável você deve ser para embrulhá-lo ou evitá-lo completamente.
quando se trata do código que é realmente central para a proposta de valor de sua aplicação —o seu “molho secreto” — você precisa ser extremamente protetor dele. Torna esse código o mais independente possível. Se você absolutamente precisa usar uma dependência, considere injectá-la em vez de referenciá-la diretamente. Mesmo assim, tem cuidado.Às vezes isso significa dizer “não” para uma biblioteca de terceiros que você acha que é muito legal, ou que você realmente quer usar por uma razão ou outra. Sê forte. Acredita, vai valer a pena. Pergunte a todas as pessoas que investiram muito na primeira libertação do Angular, ou ao meu antigo cliente que usou o Parse em todo o lado. Não tem piada. Acredita em mim.Por falar em diversão, olha para isto….
a imagem acima é o grafo de dependência para uma aplicação chamada Explorador de TinyTag.Gerar um gráfico de dependência para seus aplicativos existentes é uma ótima maneira de entender o nível de risco que está sendo introduzido por suas dependências. Eu juntei uma lista de ferramentas livres para gerar grafos semelhantes aos acima em uma variedade de linguagens, incluindo JavaScript, C#, Java, PHP e Python. Podes trazê-lo aqui.
Ajude-me a ajudar outros
eu quero ajudar o maior número de desenvolvedores que eu puder, compartilhando meu conhecimento e experiência com eles. Por favor, ajude-me clicando no botão recommend recommend (coração verde) abaixo.
finalmente, não se esqueça de obter a sua lista de geradores de grafos de dependência livre aqui.