O Guia Definitivo de
Testes Contínuos

02. O Código-Fonte¶

Este é um dos ativos mais preciosos de qualquer equipe de desenvolvimento, porque nele reside todo o trabalho. Na verdade, é o único artefato que todo projeto sempre precisará para construir. Muitas equipes não o documentam, nem fazem certos tipos de testes para ele, mas sem código, não há software. Então, o código é a única coisa que as equipes de desenvolvimento de software sempre terão. Isso fornece a diretriz de que é uma área fundamental à qual prestar atenção a fim de controlar a qualidade e reduzir riscos e custos, não importa quais sejam os objetivos e o contexto da organização.

Ao considerar o código-fonte, estamos nos referindo a várias coisas, mas principalmente à gestão de código e à qualidade do código. Ambos os aspectos devem ser considerados a fim de alcançar uma boa abordagem de testes contínuos.

Gestão de Código¶

Sendo o código um ativo tão importante, um risco essencial de manter sob controle é garantir que ele seja devidamente gerenciado, assim como quaisquer alterações feitas nele. Existem ferramentas específicas para fazer isso, feitas para trabalhar com um repositório centralizado onde todos os membros da equipe podem armazená-lo de forma confiável.

As ferramentas de hoje evoluíram em termos de foco em tarefas, indo de esquemas simples como o CVS para outros mais sofisticados e flexíveis como o Git. O que elas permitem, algumas em menor ou maior grau, é ter o código em um local centralizado. Cada desenvolvedor pode enviar código, consultá-lo, recuperar versões anteriores (o que é útil quando o seu código não está funcionando corretamente e você precisa voltar à versão anterior que funcionava), adicionar comentários a cada "commit" feito (por exemplo, comentários indicando por que se decidiu enviar determinado código ao repositório) e muito mais.

Essas ferramentas também são acompanhadas de uma metodologia. Em particular, isso se reflete em como as branches das versões são administradas (aprovadas, removidas, mescladas etc.), o que permite que diferentes pessoas trabalhem em diferentes versões do código. Há aqueles que mantêm uma branch para cada cliente (se cada um tiver um código diferente), ou uma branch para versões maiores de código, ou em um nível mais fino, onde uma nova branch é aberta para cada funcionalidade ou correção que alguém faz.

Qualidade do Código¶

Por outro lado, é importante prestar atenção à qualidade do código para promover a manutenibilidade. A qualidade do código é tipicamente um atributo interno de qualidade, pois não é visível ao usuário. É possível que, mesmo que o usuário perceba um software como sendo de alta qualidade (fácil de usar, rápido, sem bugs críticos etc.), ele possa, na verdade, ter problemas preocupantes de qualidade de código. Mas, como os usuários não conseguem ver nem analisar o código por si mesmos, eles nunca saberiam. Por outro lado, fatores de qualidade como desempenho, confiabilidade e usabilidade, entre outros, são externos, ou seja, os usuários de fato os percebem.

Mas pode chegar um momento em que os fatores de qualidade internos se transformam em externos. Considere, por exemplo, o que acontece quando uma mudança é feita no sistema em resposta a uma solicitação do usuário. Se a qualidade do código for tão ruim que leva várias semanas para modificar o sistema, então há um enorme problema de manutenibilidade que não afeta apenas a equipe de desenvolvimento, mas também o usuário. Quanto mais tempo leva para a mudança ser feita devido ao código ruim, pior será a satisfação do usuário.

A manutenibilidade depende de muitos aspectos. Há uma frase surrada que diz: "O código é escrito uma vez e lido muitas vezes", ou seja, ele deve ser fácil de ler. Mas isso não inclui apenas seguir as conhecidas convenções, como quando usar maiúsculas e quando usar minúsculas, ou usar a indentação correta, mas também é necessário manter em mente a complexidade do código, o acoplamento, o tamanho das classes, a quantidade de parâmetros e muitos outros fatores.

Anos atrás, surgiu o termo dívida técnica para explicar facilmente o problema da manutenibilidade do código a alguém sem habilidades de programação. Ele faz uma analogia com o conceito mais conhecido de dívida financeira. Ele essencialmente diz que, se alguém programa uma certa funcionalidade e o faz às pressas por falta de tempo, sem cumprir a "definição de pronto" da equipe (por exemplo, pulando a documentação ao colocar comentários no código, não atendendo a padrões e convenções de codificação nem implementando testes unitários), então, naquele exato momento, a "dívida" se acumula. Deve-se ao sistema aquilo que foi apressadamente omitido, por exemplo, os testes unitários, adiando-os para quando o tempo permitir.

Qual é o problema com isso? Além de pagar a dívida, "juros" serão adicionados, por assim dizer, já que é provável que leve mais tempo e mais energia para corrigir as coisas depois de algum tempo do que fazê-lo corretamente no momento.

Cada problema de manutenibilidade gera dívida técnica e alguém sempre paga: às vezes apenas o desenvolvedor ou, pior, o usuário que acaba sofrendo com a má qualidade do sistema.

Alguns defeitos muito comuns na qualidade do código são:

• Código duplicado
• Falta de testes unitários, falta de comentários
• Código espaguete, complexidade ciclomática, alto acoplamento
• Métodos que são longos demais
• Nenhuma adaptação a padrões e convenções de codificação
• Vulnerabilidades de segurança conhecidas

Os ambientes de desenvolvimento modernos ajudam imensamente com alguns desses problemas, como o Visual Studio ou o Eclipse (para citar alguns populares), a ponto de que, se algumas das restrições não forem atendidas, o código não compilará. De qualquer forma, há muitas coisas que podem ser analisadas com ferramentas feitas especificamente para analisar a qualidade do código. Hoje, a ferramenta mais popular para esse fim é o SonarQube, mas existem várias outras, como PMD, Kiuwan e CheckStyle.

Essas ferramentas realizam um estudo estático do código e são white-box, ou seja, analisam o código sem executá-lo. Elas verificam os defeitos comuns mencionados acima, como código duplicado ou complexidade ciclomática.

Algo muito impressionante é que o SonarQube e ferramentas semelhantes são capazes de indicar exatamente qual é a dívida técnica, calculando quantos minutos levaria para resolver cada problema que detectam. Por exemplo, a imagem a seguir é mostrada publicamente no site do SonarQube como o resultado para o MySQL. Pode-se ver que o software tem uma dívida de 36.000 dias, o que significa que são necessários 36.000 dias para resolver todos os incidentes detectados.

Tanta dívida não é o que ninguém quer para o seu software!

Embora seja ótimo que o SonarQube possa fornecer informações sobre onde está a dívida técnica, também é importante saber como pagá-la. Mas apenas ordenar esses problemas por prioridade não é suficiente. A chave aqui é encontrar o código que dará o melhor ROI se for melhorado. É necessário cruzar as informações dos problemas e sua severidade com o número de commits que há em cada classe. Ao fazer isso, os esforços podem ser focados em melhorar a manutenibilidade daquelas classes que são modificadas com mais frequência. No entanto, se houver problemas de manutenibilidade de classes que raramente são tocadas, mas que funcionam corretamente, é melhor não mexer nelas. Como diz o ditado: "Se não está quebrado, não conserte."

Para alcançar os testes contínuos, um ambiente de CI deve ser construído e, para isso, fica claro que o código precisa estar acessível em um repositório bem organizado, com várias verificações de qualidade sendo feitas no código, utilizando algo como o SonarQube.