Para arquitetos que estão começando a atuar em um projeto, é essencial formar, o mais rápido possível, uma visão abrangente de como o código está, quais são os componentes que demandam mais atenção e, na ausência de testes, quais códigos precisam maior “critério e cuidado” antes de aceitar um pull request.

Nesse contexto, utilizar ferramentas de análise estática, como o NDepend, permite que tenhamos uma boa ideia de como está o código, antes mesmo de termos acesso a ele. De todas as features da ferramenta, uma das que mais nos agrada é o gráfico “Abstractness vs Instability”, inspirado em uma proposição do Uncle Bob.

Este gráfico estabelece uma relação entre o acoplamento (aferente e eferente) e a proporção entre tipos concretos e abstratos para tentar determinar o nível de dificuldade para manter o código.

Acoplamento Aferente (Ca) refere-se a quantidade elementos (classes, assemblies, namespaces) referenciando o elemento que está sendo analisado.

Acoplamento Eferente (Ce) refere-se a quantidade de elementos (classes, assemblies, namespaces) sendo referenciados pelo elemento que está sendo analisado.

No gráfico, cinco regiões se destacam. A área verde é aquela onde está o código “ok”. Todas as demais, demandam atenção.

Códigos na “Zona do Sofrimento/Dor”, canto inferior esquerdo, são aqueles mais difíceis de manter e que, com frequência, quando alterados, geram quebras em produção. Por isso, são códigos e que precisam de mais cobertura com testes. Além disso, na distribuição do trabalho, é o código que deve receber atenção de profissionais com mais senioridade. Finalmente, esse código é aquele que precisa, provavelmente, de revisão e refactoring com mais urgência.

Importante destacar que essa análise pode ser feita mesmo sem acesso ao código fonte, através dos binários.