Confesso que quando eu comecei a ler esse livro eu estava esperando um estilo Mind Hunter com desenvolvimento de software. Não foi beeem assim mas deu pra ver possibilidades interessantes nas informações deixadas nos sistemas de versionamento de código como Git. No Your Code as a Crime Scene o Adam Tornhill mostra técnicas para descobrir informações como acoplamento de código, centralização de conhecimento em certos membros do time e partes do código que tem mais riscos do que outras. Aqui algumas notas do que achei mais interessante! Boa leitura.
O livro é dividido em três partes:
Evolving Software
Dissect Your Architecture
Master the Social Aspects of Code
Segundo o autor, os objetivos principais das análises são:
Predizer quais partes do código tem mais defeitos e as curvas de aprendizado mais íngremes
Encontrar qual parte do código importa mais pra manutenção
Entender como muitos desenvolvedores e times influenciam a qualidade do código
Porquê essas análises são importantes?
- 40 ~ 80% do tempo é gasto com manutenção (Robert Glass)
- 60% das mudanças é com melhorias (Robert Glass)
- Um software que não é de sucesso não tem manutenção
- Nossa principal tarefa quanto desenvolvedores não é escrever código, mas entendê-lo
Para chegar nessas informações precisamos identificar os hotspots e também fazer o ofender profiling. Os hotspots são os lugares que sofrem alterações com uma frequência alta. É uma métrica que combina complexidade e esforço: quantas vezes foi modificado, o número de linhas etc. O ofender profiling procura entender o quem e o quando. Onde estão os arquivos mais modificados? Eles estão no mesmo pacote?
A partir das informações extraídas é possível também visualizar problemas com o design do software. Aqui as coisas ficam bem interessantes! Se um único arquivo sempre está entre os modificados, por exemplo, é um forte indício de que ele está acumulando múltiplas responsabilidades, violando o Single Responsibility Principle. Caso você perceba que um arquivo de teste está mudando junto com outros que não são a classe ou módulo testado, isso pode significar que existe um code smell por ali, como o feature envy. Além desses problemas mais arquiteturais e de design, outros problemas como nomenclatura também podem ser encontrados. As vezes é o caso de ter a responsabilidade certa mas o nome do teste ou da classe não estar de acordo porque o nome não acompanhou as modificações ao longo do tempo.
Uma outra informação que o autor chama a atenção e eu achei super relevante é a distribuição de conhecimento. Com os commits, autores e arquivos modificados, é possível ver quem está habituado a fazer modificações em determinados lugares. Com isso, podemos entender como o conhecimento sobre certas partes do código estão centralizados em quais pessoas. Isso pode ajudar a organizar sessões de compartilhamento e evitar dev Gods nos times.
Entender quais são as partes mais frágeis do código é valioso demais. A partir das mensagens do log você pode fazer o track entre os bugs e os arquivos. No livro o autor cita vários trabalhos onde prova-se que quanto mais um código é modificado, maior a chance de ter bugs. Identificar esses pontos para extrair algumas partes para novos módulos ou classes ou adicionar mais testes em casos onde não há uma boa cobertura já ajuda na prevenção de novos bugs.
Ao buscar essas informações também é importante se atentar ao aspecto temporal do projeto. Se um projeto tem 5 anos, por exemplo, talvez não faça sentido tomar decisões levando todo esse período em consideração, afinal o time muda, estratégias mudam, tecnologias mudam. É bom levar em consideração releases, iterações ou eventos importantes.
Além disso, o modos operandis do time deve ser levado em conta. O time usa squash ou não? As pessoas fazem commits grandes ou pequenos? As mensagens de erro são descritivas? Tem pair programming ou não?
O autor recomenda alguns técnicas para visualização dessas métricas, como circle packing e tree-map, onde todos os arquivos são plotados e as cores ficam mais intensas a partir de quantas vezes ele foi modificado. Essa simples visualização já ajuda a ter uma ideia de quais arquivos sofrem mais mudanças e se eles tem alguma relação ou não.
Todos os pontos acima são bem ricos para nortear o time na construção de um software melhor. Mas essa frase, retirada do livro, é o que define o que será mais importante em todo o processo:
Let your questions guide your analysis
Os scripts utilizados no livro estão aqui, caso você queira testar. Dizem as más línguas que eu e um colega começamos a desenvolver uma CLI em Python para extrair essas métricas mas nunca terminamos. 🙈 Mas está na infindável TODO list, juro.
Esses foram os meus destaques para o livro. Ao chegar no meio dele achei um pouco repetitivo e os scripts usados poderiam ser melhor pensados, evitando muitas inserções manuais. O autor tem várias palestras sobre o tema, basta procurar pelo nome do livro que os vídeos aparecem. Embora não seja um livro que eu recomende fortemente, como disse acima, acredito que as possibilidades apresentadas por ele são bem interessantes.
comments powered by Disqus