Uma breve história da modularidade
Josh Emerson
21 de novembro de 2016
0 minutos de leituraHá pouco mais de uma semana, patrocinamos a conferência de Brighton ffconf. Foi um dia repleto de palestras brilhantes, instigantes e úteis. Ashley Williams, do npm, apresentou uma palestra intitulada “Uma breve história da modularidade”, que consideramos especialmente relevante para a Snyk. Por isso, decidimos compartilhar aqui um resumo.
Além de ler nosso resumo, você pode baixar os slides pelo npm executando npm install a-brief-history (adoramos o fato de a palestra da Ashley ser, ela própria, um módulo npm!). O vídeo estará disponível em breve (incluiremos o link assim que estiver no ar).
Por que modularizar?
O npm é o maior repositório de módulos do mundo. Hoje, ele tem mais módulos do que Bower (JS), nuget (.NET), Packagist (PHP), PyPI e Rubygems.org juntos. Então, por que o npm tem tantos módulos?
As respostas ao tuíte de Ashley foram variadas, mas a maioria das pessoas apontou motivos semelhantes para modularizar o código:
Permite reutilizar código comum
Impõe a separação de responsabilidades
Facilita a documentação e os testes do código
Por que não modularizar?
A modularização tem um custo real de complexidade. Como Guy Podjarny explica em As 5 dimensões de uma dependência npm, talvez você tenha muito mais dependências do que imagina. Para cada uma delas, é preciso fazer muitas perguntas.
Com o tempo, você encontra um pacote que parece atender às suas necessidades, mais ou menos. Mas os problemas estão só começando. Cabe a você avaliar a biblioteca: ela tem testes? Você consegue entender o código-fonte? Ela é mantida ativamente? A documentação é fácil de encontrar e consultar?
Rich Harris – Módulos pequenos: não é tão simples assim
Além dessas perguntas, você também deve considerar a segurança. Os responsáveis pelo pacote corrigem as vulnerabilidades no código? Há vulnerabilidades conhecidas na dependência ou nas dependências dela?
Desenvolvimento de software é gerenciamento de mudanças
Depois de analisar os benefícios e os custos da modularização, Ashley se concentra na diferença entre a percepção e a realidade desse processo.
Quando pensamos em desenvolvimento de software, provavelmente pensamos em resolver problemas e criar sistemas que executam tarefas. Mas nem sempre lembramos que o software evolui continuamente, e nem sempre na mesma direção.
Em 1972, David Parnas escreveu um livro intitulado “Sobre os critérios a serem usados na decomposição de sistemas em módulos”, no qual aborda a modularização sob a perspectiva do gerenciamento de mudanças.
[Comece] com uma lista de decisões difíceis de projeto ou de decisões que provavelmente mudarão. Em seguida, projete cada módulo para ocultar uma dessas decisões dos demais.
Ao pensar na modularização sob essa perspectiva, você tenta ocultar a complexidade dentro dos módulos, para que o restante do sistema não precise se preocupar com a implementação.
Em seu blog, programming is terrible, Tef apresenta uma abordagem para fazer exatamente isso.
Escreva código que seja fácil de excluir, não de estender. Em vez de criar software reutilizável, devemos tentar criar software descartável. Nem preciso dizer que excluir código é mais divertido do que escrevê-lo.
Conclusão
Ashley encerra a palestra resumindo que modularizar o código é difícil, porque precisamos entender muito mais antes de descobrir como e quando dividi-lo. Um dos principais desafios para decidir como e quando modularizar é que existe um fator temporal. Só com o passar do tempo podemos observar se uma estratégia está funcionando a nosso favor ou contra nós.
