A falta de padronização no código e a baixa cobertura por testes aumenta a demanda de esforço cognitivo dos times técnicos para fazer o trabalho. Em condições extremas, quando a capacidade cognitiva dos membros do time é ultrapassada, fica impossível que qualquer trabalho de qualidade seja feito.

Por outro lado, também é sabido que familiaridade com o trabalho faz com que menos esforço cognitivo tenha de ser empenhado no dia a dia, ampliando a produtividade. Dessa forma, códigos que obedecem padrões de design, regras para definir nomes (para variáveis, métodos, atributos, propriedades, classes, namespaces e assemblies) e bons testes, consomem menos da capacidade cognitiva e permite que mais seja feito com o mesmo.

Sob essas perspectivas, [tweet]a produtividade dos times de tecnologia é mais questão de disciplina e método do que talento.[/tweet] É fato que, ao longo do tempo, será comum que programadores com diferentes níveis de maturidade e estilos de escrita interajam as com bases de código transformando-as, quando não são adotados cuidados adequados, em uma verdadeira miscelânea de gostos e sabores. Entretanto, esse é um problema que pode ser mitigado com práticas cuidadosas.

A falta de entendimento do todo destrói a confiança necessária para a realização de modificações aumentando consideravelmente a necessidade de interrupções para conversas “tira-dúvidas” com outros membros do time que, supostamente, entendem melhor a base de código. Essas interrupções acabam abalando as estruturas de comunicação da empresa e aumentam, muito, as chances de que a escrita de novos códigos aconteça com maior acoplamento (por causa da lei de Conway).

Extrapolando os limites dos times de tecnologia, as “dores de cabeça” aumentam ainda mais quando também não existem bons critérios de aceitação documentados, levantados a partir das demandas do negócio, tampouco existem testes automatizados para vincular o código com estes critérios. Quando isso acontece, perde-se, com frequência, a vinculação entre as partes do sistema e os objetivos de negócio que elas atendem levando a problemas que só são identificados na produção.

O antídoto para todos esses problemas, em nosso entendimento, é a adoção de dois “ciclos de desenvolvimento” suportado por testes.

No ciclo amplo, se estabelece um teste de aceitação para cada modificação na base de código. Importante destacar que o teste de aceitação deverá refletir critérios combinados com o negócio.

No ciclo curto, cada modificação na base de código é antecipada por um teste de unidade, localizado e específico, que apoia o desenvolvedor a conduzir pequenas mudanças, incrementalmente.

Dessa forma:

• A escrita de testes de aceitação automatizados “conecta” o código com o objetivo de negócio, diminuindo o volume de carga cognitiva necessário recorrentemente para a manutenção
• A escrita de testes de unidade e integração funciona como uma “rede de segurança” que evita regressões em funcionalidades, reforça o uso de design testáveis e aumenta a confiança nas entregas.
• A presença de testes, tanto os de aceitação quanto os de unidade, reduz a necessidade de interações com colegas especialistas, reduzindo o ruído e diminuindo a chance de desenvolvimento de códigos ainda mais acoplados
• O hábito de “refatorar” o código continuamente faz com que os “estilos de programação obsoletos” seja removido gradualmente e é imensuravelmente mais fácil quando há testes.
• O estabelecimento de um processo de trabalho, lógico e possível de repetir, alinhado com princípios de qualidade, permite que os desenvolvedores ganhem familiaridade com boas práticas.

Engenharia de software implica em acrescentar as práticas de desenvolvimento a noção de tempo. Ou seja, assumir que o código que funciona bem hoje precisará ser revisto amanhã. Ignorar essa noção, invariavelmente, compromete resultados.

Os “dois ciclos” impedem o crescimento da necessidade de carga cognitiva, otimizam as comunicações, conduzem a padronização de design e estilos de código. É uma medida efetiva para redução do “custo por linha modificada” e mitiga o risco dos “programadores heróis”.