“One of the things that I’m very conviced of, and I know it is also something that many of my collegues in the agile movement is convinced of, is that if you’re gonna get reuse you don’t do it by building something reusable and then expecting people to go ahead and use it. The much more effective way is to build something usable, and then harvest reusable things from that.”
Martin Fowler em Agilists and Architects: Allies not Adversaries Presentation no InfoQ
(Os negritos são meus, a partir da entonação do próprio Fowler)
Traduzido livremente:
“Uma das coisas de que estou muito convencido, que é algo que muitos dos meus colegas do movimento ágil também estão convencidos, é que se você está buscando reuso, você não o faz criando algo reutilizável, e então esperando que as pessoas usem isso. A maneira mais efetiva é criar algo utilizável, e então colher coisas reutilizáveis a partir daquilo.”
Começo o post com essa citação por um motivo: o título do post é uma pegadinha. Você não cria reusabilidade. Além disso, toda a comunidade fica meio boba quando o Fowler é citado, parece que estamos citando a Bíblia, então meu argumento já chega em vocês com o caminho preparado. Ele é uma das unanimidades em todas as comunidades: Java, .Net, Rails, etc…
Às vezes encontro o pedido de algum cliente para auxiliar na criação de um framework corporativo, encapsulando todas as regras de negócio intersistêmicas, toda a infraestrutura, e tudo que é possível encapsular, de forma que cada sistema já começa com 30% construído, devido à altíssima reutilização. O argumento que eu sempre devolvo ao cliente é exatamente o colocado pelo Fowler: você não cria um framework corporativo, ele emerge naturalmente das suas necessidades. Já vi algumas vezes frameworks corporativos criados antes da necessidade, ou feitos por arquitetos/desenvolvedores que não tinham experiência no dia a dia dos projetos onde o framework seria utilizado. Invariavelmente duas coisas acontecem: o framework é muito ruim, e é sumariamente ignorado, ou o framework é muito ruim e é empurrado por alguma política corporativa, o que engessa e encarece o processo de desenvolvimento. Notem que nos dois casos o framework é muito ruim.
Porque o framework é muito ruim? Porque ele feito pelo arquiteto astronauta, ou por algum terceiro, ou até por um funcionário da empresa, só que sem olhar para o mundo real. Aí o framework possui componentes:
- Que nunca são usados porque ninguém sabe que existem;
- Que são tão complexos que são impossíveis de entender;
- Que são irrelevantes, porque não resolvem necessidades de negócio reais;
- Que são feitos sem flexibilidade, e não aderem a bons princípios de extensibilidade (como o princípio aberto fechado, por exemplo), e que obrigam os desenvolvedores a ficarem dando a volta no componente para resolver os problemas que ele não resolve.
- Que tentam resolver problemas de negócio específico, como se todos os sistemas enxergassem uma entidade sempre sob a mesma perspectiva, e que nunca são utilizados porque isso não é verdade, e o que foi feito não se adapta às necessidades do sistema sendo construído.
A única maneira de fazer um framework útil de forma produtiva é extraí-lo de projetos reais. Qualquer outra coisa é dinheiro jogado no lixo. Receita de bolo:
- Faça um projeto com testes;
- Extraia o que pode ser comum a outros sistemas. Não extraia nada que seja de negócio, abstraia apenas infra-estrutura;
- Refatore livremente o que foi extraído, independente do sistema original, e crie testes para o framework também;
- Adapte o sistema original ao framework. Se doer é porque o framework está ruim, volte ao passo 3. No final rode os testes. Tudo tem que passar, se não passar conserte o framework ou o sistema;
- Enxague, e repita os passos 1 a 4 até o framework atingir o escopo esperado;
- Sempre que trabalhar uma atualização em um sistema legado adeque os sistemas da empresa ao novo framework.
Não preciso nem dizer que tudo tem que ser feito utilizando boas práticas de OO e de arquitetura, não é? Componentização, pacotes, extensibilidade, e aquele monte de outras coisas que eu falo aqui.
Gerentes, vocês entenderam? Arquitetos, vocês entenderam? Desenvolvedores, vocês entenderam?
A chamada de atenção acima é proposital. Com frequência gerentes, arquitetos e desenvolvedores, nesta ordem, querem inventar frameworks corporativos para economizar dinheiro, para diversão conceitual, ou para ajudar no próprio trabalho, respectivamente.
Lembrem disso da próxima vez que alguém sugerir “Vamos criar um framework?”.
Giovanni Bassi
Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.