Verde Sem Vergonha

Algum tempo atrás eu tive contato com o livro “99 Bottles of OOP”, da Sandi Metz, Katrina Owen e TJ Stankus. Ele oferece ideias extremamente interessantes, com muitas delas natualmente implementadas por quem procura sempre escrever código de sofwtare com qualidade. Nas palavras dos autores, o livro é sobre escrever código econômico, de fácil manutenção e agradável. Eu acrescento que o livro trata do processo (a jornada, para ser mais poético), sobre atravessar todo percurso entre a chegada de um problema, sua solução inicial, e a solução final totalmente baseada nas melhores práticas. Do início ao fim, passamos pelas soluções mais triviais de um programa para escrever os versos da música “99 Bottles of Beer” (uma versão alcoólica dos cincos patinhos que foram passear). O estado da arte da solução final é visível e absurdamente óbvio. Mas mais importante que isso, é entender o processo de tomada de cada decisão até chegar nela.

Dentre os vários conceitos debatidos, o livro me apresentou um muito interessante: Shameless Green (verde sem vergonha). O nome vem das marcações, geralmente verdes, que ganhamos ao executar testes automatizados em no softare e eles concluírem com sucesso. De forma geral, o conceito estabelece que devemos fazer focar problema e sua solução mais trivial possível. Claro, tudo isso amparado por testes desde as primeiras linhas de código.

Shameless Green é TDD? Não, embora caminhem lado a lado! TDD é um processo, uma disciplina que define a ordem de trabalho (teste falha, código passa, refatora) e fornece feedback rápido e com mantém segurança para refatoração. Shameless Green, por outro lado, é uma postura diante do design: a decisão consciente de chegar ao verde o mais rápido possível, priorizando clareza e entendimento, mesmo que isso resulte em código duplicado, procedural, feio e ruim. Em outras palavras, TDD diz como avançar com segurança, enquanto o Shameless Green define como o código pode parecer nesse estágio inicial, aceitando soluções simples e até não elegantes enquanto o domínio do problema ainda está sendo descoberto.

Levando ao extremo, é algo como isso:

fun test_multiply() {
  assert(multiply(3, 5)).equals(15)
}

fun multiply(a, b) {
  return 15
}

Com essa ideia, escrever código com excesso de if/else, duplicações, números mágicos, lógica procedural e todo tipo de gambiarra de engenharia é perfeitamente válido, desde que isso seja uma escolha consciente e temporária. Nesse estágio, vale fazer qualquer coisa que leve o sistema ao verde de forma clara e direta, sem tentar antecipar abstrações, padrões ou arquiteturas futuras. O objetivo não é escrever um bom design, mas tornar o problema explícito no código, acumulando exemplos concretos que mais tarde servirão de base para refatorações seguras e fundamentadas.

Um problema resolvido com Shameless Green é funcional. Para cada entrada X, ele vai entregar a saída Y esperada, e isso está garantido pelos testes. No entanto, o valor real da técnica só aparece quando esse estado inicial de “verde sem vergonha” é tratado como um ponto de partida, e não como um destino final. A partir do momento em que o comportamento está protegido pelos testes, o código deve entrar conscientemente em um ciclo de refatoração, onde duplicações são removidas, responsabilidades são separadas e abstrações passam a emergir com base em fatos observados, não em suposições. Sem essa etapa posterior, o Shameless Green deixa de ser uma estratégia deliberada de aprendizado do domínio e passa a ser apenas código desleixado.

Imaginemos um API REST constrúída com Spring Boot. Uma divisão de camadas clássica é fazer os controllers receberem as requisições HTTP e traduzir elas para o domínio da aplicação, passando os dados para a camada de serviço. A camada de serviço aplica qualquer lógica de negócio e usar a camada de repositório para persistência de dados. Uma abordagem mais sem vergonha para resolver o problema é simplesmente deixar tudo no controller. O controller recebe um JSON e entrega um JSON. O teste vai passar! A partir disso, podemos entender como as camadas de serviço e repositório poderiam ajudar nessa tarefa, quais abstrações surgem naturalmente das necessidades, e tudo vai estar garantido pelos testes que já existem.

Para sair do verde sem vergonha e chegar uma solução com qualidade elevada, o que deve ser considerado? O livro cita algumas técnicas de avaliação bastante objetivas, como a Source Lines of Code (SLOC), que é uma métrica simples que mede a quantidade de linhas de código-fonte de um sistema. Ela é útil para se ter uma noção de tamanho ou volume de código, mas não indica qualidade, já que mais (ou menos) linhas não significam, por si só, código melhor ou pior.

Outra métrica, imagino que bem conhecida, é a complexidade ciclomática, que mede quantos caminhos lógicos diferentes existem em um trecho de código. Ela cresce com o uso de if, else, switch, laços e condições compostas. Quanto maior a complexidade ciclomática, mais difícil é testar, entender e manter o código, pois mais casos independentes precisam ser cobertos por testes. Em geral, valores baixos indicam código mais simples e previsível.

A métrica ABC (Assignments, Branches and Conditions) mede a complexidade cognitiva do código contando três coisas: atribuições (valores sendo atribuídos), branches (chamadas de métodos/funções) e condições (decisões lógicas). Diferente da complexidade ciclomática, ela captura o esforço mental necessário para entender o código como um todo — quanto maior o valor ABC, maior tende a ser o custo de leitura, teste e manutenção.

O foco do livro não é o Shameless Green. Como mencionado, a beleza do conteúdo está em demonstrar todo processo de tomada de decisão para prosseguir em cada etapa que eleva a qualidade do software. São tratados temas sobre identificar e implementar as abstrações corretas, uso de nomes significativos, obdiência ao Princípio Aberto/Fechado e o Princípio da Substituição de Liskov, identificação de gambiarras, dentre vários outros tema. É um livro que recomendo muito a leitura!