Disclaimer
Este texto foi inicialmente concebido por um Agente Dev + Eficiente especializado nos conteúdos da Jornada e foi revisado por Alberto
Introdução
Uma classe que começa com 40 linhas e termina o ano com 400. Acontece em praticamente todo projeto. O problema não é a classe ter crescido. É que ninguém percebeu quando ela começou a ficar difícil de entender.
Não existe um ponto de ruptura claro -- ela vai acumulando responsabilidades, condicionais e dependências até que qualquer alteração começa a pesar muito mais do que deveria. E aí você tem um time inteiro olhando para o mesmo arquivo e cada pessoa avaliando a dificuldade de um jeito diferente.
A maioria das práticas que tentam resolver isso são baseadas em princípios qualitativos. "Responsabilidade única", "código limpo", "baixo acoplamento". Importantes, mas difíceis de aplicar de forma consistente entre pessoas diferentes de um mesmo time. O que é "responsabilidade única" para uma pessoa pode não ser para outra.
O Cognitive Driven Development (CDD) parte de uma premissa diferente: é possível tornar a avaliação de complexidade de código algo mensurável e compartilhado.
Para não causar confusão: não estamos falando de sustituição de práticas e sim de trazer uma prática que pode facilitar o uso das outras.
O fundamento: carga cognitiva aplicada a código
A teoria da carga cognitiva vem da psicologia educacional. A ideia central é que seres humanos possuem um limite restrito de capacidade de absorção de informação em um determinado intervalo de tempo. Uma referência clássica é o trabalho de Miller (1956), que estabelece que uma pessoa consegue manter aproximadamente 7 itens simultâneos na mente.
O insight do CDD é tratar código como material de consumo cognitivo -- assim como um slide, uma apostila ou um vídeo. Se existe um limite para o que uma pessoa consegue processar, então faz sentido que unidades de código também respeitem esse limite.
A partir daí, o CDD sugere que a complexidade de uma unidade de código (um arquivo, por exemplo) tenha um limite definido. Passou deste limite? A complexidade está maior do que queremos, precisamos ajustar.
Como funciona na prática
O processo é direto. A equipe decide quais elementos de código ela julga que mais pesam na mente das pessoas. Não existe resposta certa -- isso varia de time para time e de projeto para projeto.
Por exemplo, em um projeto com Java, a equipe pode definir (apenas um exemplo) os seguintes elementos:
- Condicionais
- Acoplamentos com classes do projeto
- Funções como argumento
Cada elemento desse, dentro do CDD, é chamado de Intrinsic Complex Point (ICP). Num projeto usando Clojure, os elementos vão mudar. Num projeto usando Python, podem mudar de novo. A teoria é agnóstica de linguagem -- o que muda é quais construções da linguagem a equipe considera relevantes para o entendimento.
Pode-se definir que cada elemento contabiliza um ponto e, a partir disso, já fica bem mais fácil avaliar a complexidade. Supondo que o limite é 10, basta contar.
Por que isso funciona melhor do que princípios qualitativos
Três ganhos práticos:
Uniformidade de avaliação. Quando todo mundo conta os mesmos elementos e usa o mesmo limite, a discussão sobre complexidade sai do campo não determinístico e vai para o campo determinístico. Pessoas com níveis de experiência diferentes passam a analisar complexidade sob a mesma ótica.
Automação. Algo que se resume a contar elementos e comparar com um limite é completamente entendível por um programa. Isso pode entrar no CI, num linter, ou até ser delegado a um LLM (aceitando as variações nas respostas). Não depende de julgamento humano subjetivo no momento da verificação.
Adaptabilidade. Nada é fixo. A equipe, depois de iterar, pode querer trocar os ICPs, aumentar o limite, reduzir. A métrica evolui junto com o contexto do time. Se os acoplamentos com classes do projeto pararam de ser um problema porque todo mundo já domina, a equipe pode remover esse item e adicionar outro que passe a ser mais relevante.
O experimento
Já há alguns anos, foi feito um experimento com mais de 20 pessoas, comparando refatoração convencional com refatoração guiada pelo CDD. O grupo que usou a métrica chegou a resultados mais uniformes e com complexidade menor -- independente do nível de experiência de quem refatorou.
O ponto mais interessante: pessoas menos experientes entregaram código menos complexo do que pessoas mais experientes que refatoraram sem a métrica. Quando existe um limite claro e uma forma objetiva de medir, a experiência deixa de ser o único fator determinante para a qualidade do resultado. Métodos bons fazem diferença para diminuir diferenças de experiência.
O que muda no dia a dia
Na prática, adotar o CDD significa que o code review ganha um critério a mais -- e um critério que não depende de quem está revisando. Se o arquivo passou do limite, precisa ser dividido. Se não passou, está dentro do aceitável.
Isso não substitui a análise qualitativa. Você ainda vai discutir naming, coesão, decisões de design. Mas a questão "esse arquivo está complexo demais?" deixa de ser uma discussão sem fim.
Para projetos novos, a sugestão é começar com um limite mais restritivo e ajustar conforme a equipe ganha experiência com a métrica. Para projetos existentes, o caminho é contabilizar primeiro e aplicar o limite apenas para código novo -- sem sair refatorando tudo de uma vez.
CDD dentro da Jornada Dev + Eficiente
CDD é um dos mais de 20 cursos da Jornada Dev + Eficiente. E não é um curso isolado: o controle de complexidade de código se conecta diretamente com os cursos de design de código, engenharia de requisitos e DDD. A complexidade do código que você escreve é consequência de como você refinou o requisito, modelou o domínio e organizou as responsabilidades.
A Jornada cobre de controle de complexidade de código até operação de sistemas em produção. Acesso vitalício, todas as perguntas respondidas pelos instrutores e comunidade no Discord.
Acesse https://deveficiente.com/oferta-10-por-cento para conhecer tudo que oferecemos.
Top comments (0)