Um ano de analise de código — Sonarqube
O ano de 2017, estava apenas começando quando me deparei com um texto muito curioso sobre Qualidade de Software. Neste texto, o autor que infelizmente não me recordo — apesar de haver inúmeros na web para pesquisa, traçava um paralelo entre a Teoria das janelas quebradas e o desenvolvimento software.
Para quem não conhece, a teoria das janelas quebradas ou “broken windows theory” é um modelo americano de política de pública para combate ao crime, que tem como visão fundamental a desordem como fator de elevação dos índices da criminalidade. Nesse sentido, a teoria prega que se não forem reprimidos os pequenos delitos ou contravenções, inevitavelmente teremos condutas criminosas mais graves.
A Universidade de Stanford dos EUA, realizou uma experiência deixando dois carros idênticos, da mesma marca, modelo e cor, abandonados na rua. Um no Bronx, bairro pobre e conflituoso da cidade de Nova York e o outro em Palo Alto, bairro rico e tranquilo da Califórnia. O resultado foi que o carro abandonado no Bronx começou a ser vandalizado em poucas horas. As rodas foram roubadas, depois o motor, os espelhos, o rádio, etc. Levaram tudo o que fosse aproveitável e aquilo que não puderam levar, destruíram. Contrariamente, o carro abandonado em Palo Alto manteve-se intacto. A experiência não parou aí. Quando o carro abandonado no Bronx estava desfeito e o de Palo Alto continuava impecável, os pesquisadores quebraram o vidro do carro de Palo Alto. O resultado a seguir foi o desencadeamento do mesmo processo que ocorrera no Bronx. Por que o vidro quebrado abandonado num bairro supostamente seguro foi capaz de desencadear um processo de delitos? Trata-se de algo que tem a ver com a psicologia humana e com as relações sociais. Um vidro quebrado num carro abandonado transmite uma ideia de deterioração, de desinteresse, de despreocupação. Faz quebrar os códigos de convivência, faz supor que a lei encontra-se ausente, que naquele lugar não existem normas ou regras.
Baseada nessa experiência, vamos traçar um paralelo para o desenvolvimento de software. Durante o desenvolvimento de qualquer software, ocorrem pequenas quebras de regra, por inúmeras razões . Se estes códigos não são revistos, outros e mais outros são criados até que todo software esteja deteriorado. Em software, este processo é conhecido pelo nome de divida técnica.
O termo “dívida técnica” foi definido por Ward Cunningham e descreve a dívida que a equipe de desenvolvimento assume quando escolhe um design ou abordagem fácil de implementação no curto prazo, mas com grande impacto negativo no longo prazo.
O autor de "The Code Complete" Steve McConnell classificou a dívida técnica em dois tipos:
- Não intencional — Desenvolvedores juniores escrevem código de baixa qualidade por conta de sua inexperiência técnica.
- Intencional — O time de desenvolvimento toma uma decisão consciente para cumprir determinado prazo de entrega, que terá grande impacto no futuro.
Se o divida cresce o bastante, eventualmente a empresa gastará mais consertando estas dividas do que investindo em incrementar o valor dos seus ativos — Steve McConnell (autor de Code Complete)
A frase acima denota a importância de termos um processo de monitoramento da divida técnica para à mantermos sob controle, uma vez que ela faz parte da natureza do desenvolvimento de software e não há como elimina-las.
Para monitorar a divida técnica, faz-se necessário a utilização de um analisador de código estático. Este analisador faz a depuração dos fonte sem que seja necessário executa-lo. O processo proporciona uma compreensão da estrutura do código, arvore sintática, e assegura que o código adere às normas e padrões impostos.
A principal vantagem da análise estática é o fato de que ele pode revelar erros que não se manifestam até que uma não-conformidade ocorra, o que pode acontecer em semanas, meses ou anos após o deploy do produto. No entanto, a análise estática é apenas um primeiro passo para um regime abrangente de controle de qualidade de software.
Uma vez compreendida as bases teóricas do projeto e os ganhos de escala, vamos falar das experiências do projeto. O projeto teve como inicio o levantamento dos requisitos para uma ferramenta de analise de código e posteriormente a tomada de decisão do tipo Make or Buy.
Os requisitos foram elaborados e estudados com o objetivo de mantermos a manutenibilidade do software. Manutenibilidade é uma das características de qualidade de software, que determina o grau de facilidade com que o mesmo pode ser corrigido ou aperfeiçoado. Um software com alto índice de manutenibilidade necessita de menos tempo e recursos para ser modificado. Existem alguns fatores que afetam a manutenibilidade e com base nestes fatores chegamos a uma lista de requisitos para a seleção de nossa ferramenta de analise de código estático, que pode ser observado na figura abaixo:
Além destes requisitos, a ferramenta deveria atender a toda gama de linguagens que hoje utilizamos na empresa e conectar-se facilmente as nossas ferramentas de SCM.
Após uma analise e provas de conceito em quadro de nossos Polos de desenvolvimento, escolhemos a ferramenta SonarQube.
O próximo desafio era implementar a ferramenta. A ferramenta possui suporte a algumas de nossas linguagens, como Java, .Net, Progress e .Net Core. Neste caso o desafio era selecionar todas as regras que gostaríamos de aplicar em nossos software e construir novas. Por outro lado, para as linguagens não suportadas, tínhamos o desafio de entender os mecanismos de funcionamento do Sonarqube e qual a melhor abordagem para construirmos o analisador de código e posteriormente as regras. Para a linguagem AdvPL, que não é suportada nativamente pelo Sonarqube, optamos por reaproveitar um parser construído no ANTLR em vez de utilizar a própria estrutura disponibilizada pelo Sonarqube, uma vez que obteríamos sinergia com outros projetos que mantém este parser e por consequência, teríamos um redução de prazo e esforço significativo.
O próximo passado seria a implementação da ferramenta em alguns sites de desenvolvimento, selecionamos um pequeno conjuntos de fontes para iniciar a analise e o resultado nós surpreendeu negativamente. Passamos alguns dias analisando cada item e chegamos a algumas conclusões interessantes. A mais relevante é a de que as regras disponibilizadas, de forma nativa, são conflitantes, o que inegavelmente irá gerar uma nota baixa, caso todas fossem habilitadas. Outro ponto é a forma como as regras são classificadas no Quality Gate da ferramenta, por ser um tema extenso, não vou me atrever a comentar neste artigo. Haja visto que o mais importante é manter-se um ciclo recorrente de melhoria continua de código, atendo-se ao Leak Period para evitar que novas dividas sejam criadas.
Após esta experiência com as linguagens suportadas nativamente, passamos a elaborar as regras de analise especificas para cada software, inclusive o AdvPL. As regras iniciais foram focadas no que julgamos ser mais importante para uma primeira entrega e consequentemente teria as dividas que gostaríamos de eliminar no curto prazo.
O balanço que faço deste um ano do inicio do projeto é que ele foi extremamente positivo, apesar de todas as dificuldades que apareceram durante o projeto, vale lembrar que o comportamento dos desenvolvedores é algo peculiar.
Conseguimos neste período, eliminar muitos potenciais bugs, reduzir o custo de inspeção visual de código e trabalhar em questões como vulnerabilidade e desempenho da aplicação de forma geral.
Ao adicionar a ferramenta Sonarqube em nossa Integração Continua, alcançamos a maturidade no processo e iniciamos uma nova fase em que iremos disponibilizar gradativamente nossas regras e outras especificas para as customizações de nossos clientes e parceiros.
