Empiricamente, todos sabemos que os desenvolvedores gastam muito mais tempo tentando entender código antes de começar a fazer qualquer alteração que resolva um bug ou entregue alguma funcionalidade para o negócio. Há quem diga que essa relação chega a ser de 90/10, ou seja, em uma hora de trabalho, são investidos 54 minutos entendendo o código e apenas 6 fazendo algo que, efetivamente, entrega valor.
Nesse contexto, [tweet]qualquer iniciativa que reduza o esforço necessário para entender código tem potencial de causar impacto enorme de produtividade – tanto na perspectiva técnica dos times de desenvolvimento, quanto na perspectiva econômica que interessa tanto o negócio.[/tweet]
Há tempos, sabemos que [tweet]o caminho para reduzir o tempo gasto entendendo código é empenhando algum esforço escrevendo código-limpo que é mais fácil de entender.[/tweet] Infelizmente, a formação de profissionais com essa competência exige tempo. É difícil, caro e toma tempo fazer com que todos no time possuam, de forma nivelada, conhecimento, habilidades e, principalmente, as atitudes imprescindíveis para esse fim. Exatamente por isso, é necessário que busquemos formas de abreviar esse processo.
Dentre as várias iniciativas que conhecemos para melhorar a qualidade do código produzido, em um ambiente saudável, a que costuma produzir efeitos mais imediatos é a adoção de ferramentas de análise estática automatizada de código.
Em .NET, por exemplo, ferramentas como Resharper e NDepend atingiram níveis de maturidade surpreendentes e conseguem produzir insights valiosos mesmo para programadores experientes. Em outras linguagens e plataformas, há ferramentas igualmente poderosas.
Seja integrando-as as IDEs, seja incluindo-as como etapa no processo de Build, as ferramentas de análise estática conseguem identificar “sujeiras” comuns de escrita e indicar alternativas para a limpeza.
[tweet]Modernamente, essas ferramentas consolidam e explicitam o conhecimento da comunidade sobre como escrever código limpo.[/tweet] Métodos muito grandes, com muitos parâmetros, mal comentados, com alta complexidade são identificados. Classes muito grandes, com baixo nível de abstração e oportunidades de reduzir o acoplamento são detectadas. Chamadas ao banco de dados realizadas na interface, referências cíclicas, objetos criados sem necessidade são apontados. Padrões de nomes para variáveis, métodos, classes, namespaces são especificados e indicados. Se não bastasse tudo isso, a cada nova versão essas ferramentas ganham mais e mais capacidades que podem acelerar tanto o processo de desenvolvimento quando gerar métricas confiáveis que suportem o planejamento de evolução do software.
Treinar o time é, sem dúvidas, fundamental. Melhorar a cultura é uma necessidade inquestionável. Mas, modernamente, é difícil encontrar boas razões para que ferramentas de análise estática não sejam amplamente incorporadas as rotinas das organizações. Os investimentos são nulos frente aos benefícios potenciais.
