Arquitetura baseada em humor

Ontem o Walmyr do Talking About Testing compartilhou, no grupo da sua mentoria, um artigo muito interessante sobre como os testes de unidade começaram a estruturar o Stack Overflow para a sua versão Enterprise para entregar mais qualidade para os seus clientes pagantes. Gosto muito do conteúdo do Walmyr, sempre compartilhando coisas muito interessantes, o conteúdo é riquíssimo na sua mentoria. Obrigada Walmyr!

Depois de ler o artigo, conectei com a palestra que vi da Roberta Arcoverde no DevLeaders do ano passado, falando sobre dívida técnica e exatamente sobre esse ponto do Stack Overflow não ter testes de unidade em 2008, e como eles estão virando esse jogo.

—

No livro da Arquitetura Limpa do Uncle Bob, ele fala da diferença entre você estar fazendo uma bagunça e estar criando uma dívida técnica. E é aqui que a gente separa os adultos das crianças.

No livro tem um caso de uso bem interessante de uma empresa que mostra o ciclo de vida de um produto ao longo de 8 entregas. No primeiro gráfico temos o crescimento exponencial da equipe de engenharia, isso deveria ser bom, certo? Mais pessoas, entregas mais rápidas!

No segundo gráfico mostra a produtividade ao longo dessas entregas com uma curva ascendente, só que a partir da quarta, a curva começa a ficar quase uma reta, não tendo mais crescimento até o final.

Em contrapartida, o gráfico que mostra o custo por linha de código em função do tempo é muito crescente e para o infinito e além, sem retas de estacionamento. Aqui é onde ele fala sobre a marca registrada de uma bagunça.

“Quando sistemas são desenvolvidos às pressas, quando o número total de programadores se torna o único gerador de resultados, e quando houver pouca ou nenhuma preocupação com a limpeza do código e a estrutura do design, você pode ter certeza que irá seguir esta curva até o seu terrível final”. – Arquitetura limpa, página 7.

O próximo gráfico é sobre produtividade por release, e se pensarmos que temos mais desenvolvedores, a produtividade deve estar lá em cima, certo? No estudo de caso, não. Ela começa em 100%, na segunda entrega já está em 70% e incrivelmente na terceira entrega já está em 20% e o resto é quase uma linha reta para baixo até o final.

E o último gráfico é a visão executiva sobre tudo isso. O valor da folha de pagamento mensal do desenvolvimento por entrega. Também é uma curva crescente.

O resumo deste caso de uso é, seja qual for o lucro registrado, essas tendências não são sustentáveis, essas curvas drenarão o lucro do negócio e causará a estagnação da empresa, podendo levar a um colapso total.

—

E geralmente o que a gente ouve sobre estratégia em lidar com essa bagunça é reescrever o código em outra linguagem mais moderna, com uma equipe dedicada e etc. Mas de novo o Uncle Bob fala sobre isso, se você não lidar com a bagunça e não criar uma arquitetura de qualidade, vai entrar no mesmo ciclo e o código de hoje vai se tornar o legado bagunçado de amanhã.

Em um dos artigos do Martin Fowler ele mostra o quadrante da dívida técnica e o primeiro item é você ser negligente com o código, não escrever código testável, não escrever um código limpo. A diferença entre fazer a bagunça que não é arrumável (ou que vai custar muito caro) e fazer uma bagunça consciente mas preparado para a mudança, é a arquitetura!

A arquitetura nada mais é que a organização dos componentes do sistema. Se pensar na arquitetura limpa, que é um padrão arquitetural, os componentes são bem definidos para que o domínio só seja acessado de fora pra dentro, nunca ao contrário. E o mais importante, as regras de negócio (algo do nosso teste de unidade), não estarem espalhadas pelo código e sim numa camada específica pra isso. Essa é uma grande diferença para o teste.

O teste nesse nível habilita tanta coisa! É lindo ver o teste mostrando algo que poderia ser acoplado se fosse desenvolvido primeiro, sem pensar no teste. O teste também pode ser um farol para pensar no SOLID, um padrão de codificação.

E não diferente do que a Elisabeth Hendrickson disse no seu livro de Testes Exploratórios, “é tudo sobre a variabilidade das coisas”. Nesse nível é tudo sobre a manutenibilidade das coisas.

Nessa palestra do DevLeaders, a Roberta Arcoverde compartilhou algumas heurísticas de priorização dessa mudança, cabe muito compartilhar aqui com vocês algumas delas:

Code Smells – quanto mais code smells em um módulo, mais importante refatorá-lo primeiro. Aqui tem ferramenta como o Sonar que é um braço direito em detectar problemas de manutenibilidade, informa como consertar e tem regras específicas de cada linguagem.

Alterações – Módulos que mudam com mais frequência têm maior impacto em manutenibilidade e devem ser priorizados.

Ouvir o time – Desenvolvedores sabem intuitivamente quais áreas do código dão maior dor de cabeça. Não só os Devs, os QAs também sabem onde estão as maiores dores.

A dor mais latente – Eu já usei esse tipo de priorização, busquei no Centro de Relacionamento com o Cliente (a ponta mais próxima do cliente) pra saber por onde começar a pensar em alguma cobertura de testes, por exemplo.

—

A verdade é que não existe Bala de Prata, existe a estratégia adequada ao seu contexto. Por isso é bom estar com a caixa de ferramentas em dia e ter bastante troca com os times e principalmente com pessoas da comunidade, ajuda muito a ventilar as ideias.

O ideal é:

Resolver o problema para o cliente sem causar um problema para o desenvolvedor.

“A dívida técnica não é uma licença para fazer bagunça. A dívida técnica cria a necessidade de uma limpeza ainda maior.

Quando você decide assumir uma dívida técnica, é melhor garantir que seu código permaneça completamente limpo. Manter o sistema limpo é a única maneira de pagar essa dívida”. – Uma bagunça não é uma dívida técnica – Uncle Bob.

Enfim, não dá pra criar uma arquitetura baseada em humor. Essa virada do Stack Overflow com a estratégia da Roberta Arcoverde só mostrou que é possível fazer isso, com estratégia e priorização, sem esquecer da boa e velha melhoria contínua, inspeção e adaptação.

Coisas como Clean Code, Clean Architecture e SOLID já mantém muito a casa arrumada. Quanto mais bagunçada a casa está, mais temos que ter disciplina pra manter a casa arrumada.