7 03 2018

Você já ouviu falar de débito técnico no desenvolvimento de software? Pois bem, débito técnico engloba todo o esforço que teremos ao refatorar o código da nossa aplicação por termos optado por um caminho mais simples, ao invés de implementarmos alguma funcionalidade do jeito “certo“. Sabe aquelas gambiarras que implementamos e que nós temos certeza que não é o jeito correto de resolver um problema? O esforço para corrigir essas gambiarras no futuro é justamente o débito técnico que estamos adquirindo ao desenvolvermos dessa maneira.

Nem todo débito técnico é ruim. Afinal de contas, se optamos por resolver um determinado problema com uma gambiarra, é porque nós tínhamos uma justificativa para teremos seguido por esse caminho. O grande problema é que, depois de um tempo de desenvolvimento, fica muito difícil de termos uma noção de quanto tempo teremos que empenhar para resolvermos todo esse débito técnico. E, pior ainda, fica praticamente impossível de lembrarmos exatamente o código que deverá ser refatorado.

É para nos ajudarmos com essa atividade que nós temos ferramentas como o NDepend, que eu vou apresentar para você no artigo de hoje.

Disclaimer

Eu já tinha ouvido falar sobre débito técnico e sabia exatamente o conceito por trás dele. Porém, até setembro de 2017 eu nunca tinha ouvido falar da ferramenta NDepend. Eu fui ficar sabendo da existência dessa ferramenta através do contato do criador da ferramenta (Patrick Smacchia) pelo LinkedIn. Ele viu que eu tinha esse site onde eu publico conteúdos técnicos e resolveu me oferecer uma licença para que eu pudesse testar a ferramenta e escrever sobre as minhas experiências aqui no site.

Instalação do NDepend

A instalação do NDepend é muito tranquila. Você simplesmente receberá um arquivo zip, que você poderá descompactar em qualquer pasta que desejar. Dentro dessa pasta, você encontrará o executável do NDepend:

Ao abrirmos o NDepend, nós teremos a opção de instalarmos a extensão que fará a integração com o Visual Studio:

Analisando uma solução com o NDepend

Uma vez integrado ao Visual Studio, nós teremos à nossa disposição o menu exclusivo do NDepend. Para analisarmos uma solução com o NDepend, nós só precisamos compilar o projeto e, em seguida, nós escolhemos a opção para anexar o NDepend na solução atual:

Primeiras impressões

Eu testei o NDepend com duas soluções. Uma delas foi a solução principal da empresa onde eu trabalho, que é uma solução bem grande, contando com mais de 20 projetos, muitos deles bem complexos. A outra solução foi o projeto da aplicação que eu desenvolvi durante a minha série sobre desenvolvimento Android com Xamarin publicada aqui no site. Em ambos os casos, o processo de análise da solução foi bem rápido.

Uma vez concluída a análise, nós podemos ver os resultados em um dashboard, que eu gostei bastante:

Veja só quanta informação interessante nós temos nesse dashboard. Além do próprio cálculo do débito técnico e a quantidade de problemas categorizados por nível de criticidade, nós temos também a quantidade total de linhas de código, contagem de tipos, porcentagem de linhas com comentário, etc. Agora vamos focar nos problemas encontrados pelo NDepend:

Ao clicarmos na contagem de problemas, o NDepend mostrará o detalhamento dessas informações:

Para cada regra aplicada, nós temos acesso a uma explicação detalhada:

Apesar de todas essas informações serem muito interessantes e valiosas, eu particularmente achei muito complicada a navegação dessa parte de correção de problemas do NDepend (que é a principal funcionalidade dele, diga-se de passagem). Ao navegarmos pelos problemas, ele vai abrindo abas dentro da própria UI, e é muito fácil se perder no meio do caminho. Mas, de qualquer forma, depois de um tempo trabalhando com a ferramenta você acaba se adaptando.

Falsos-positivo

Um problema que eu encontrei ao utilizar o NDepend foram os “falso-positivos“. Como eu mencionei anteriormente, os screenshots da análise que eu estou mostrando para vocês são do projeto da aplicação Android que eu desenvolvi aqui junto com vocês durante o ano de 2017. Nesse tipo de aplicação, uma parte do código é gerado pelas ferramentas da Xamarin, e eu não tenho controle desse código que é gerado automaticamente.

Por exemplo, o NDepend sugeriu que não fossem criadas variáveis globais utilizando “public const“. Ao invés disso, o melhor seria definirmos essas variáveis em classes estáticas com campos públicos e estáticos. Isso evitaria que nós tivéssemos que compilar a solução inteira caso o valor dessas constantes fossem alterados (nós só teríamos que compilar o projeto onde elas foram definidas). O problema é que elas estão definidas na classe criada pela Xamarin:

Outro tipo de “falso-positivo” encontrado foi a questão do nome de alguns métodos que não estavam começando com letra maiúscula. Só que esses métodos na verdade eram “event handlers“:

Eu sei que o mecanismo de regras do NDepend é muito flexível (ele é baseado em consultas LINQ) e que eu poderia editar as regras para que esses “falsos-positivo” fossem ignorados. Porém, tudo o que eu não quero ter que fazer ao analisar problemas no meu projeto é ficar ajustando o código das regras para que determinados problemas sejam ignorados. Uma funcionalidade que faz muita falta no NDepend é a opção de clicar em um resultado e marcar para que ele seja ignorado (pelo menos eu não consegui encontrar essa opção).

Alguns problemas resolvidos

Depois de analisar todas as sugestões apresentadas pelo NDepend (processo que demorou uns 30 minutos para essa solução que é bem pequena), o fato foi que 80% dos problemas estavam localizados em classes que não foram criadas por mim e que não estavam sob o meu controle, mas sim, em classes geradas pelas ferramentas da Xamarin. Alguns problemas que eu realmente corrigi foram:

Campos que deveriam estar configurados como “readonly” porque eles não sofrem alteração depois de declarados:

Métodos que estavam dando um “throw NotImplementedException“:

Além disso, consertei também alguns métodos longos que estavam com poucos comentários.

Depois de consertar esses problemas que realmente faziam parte do meu code-base, eu rodei novamente a análise do projeto e obtive o comparativo com a análise anterior:

Outras funcionalidades

Além de análise estática de código, o NDepend também conta com algumas outras funcionalidades:

– Diagramas de dependência
– Matrizes de dependência
– Comparação entre duas versões de um assembly
– Possibilidade de plugar em sistemas de continuous integration
– E muitas outras funcionalidades que você pode conferir na página do produto

Coincidentemente, no dia em que eu estava escrevendo esse artigo, eu tive uma demanda no trabalho onde eu precisei comparar duas versões de um assembly da DevExpress para tentar contornar um bug introduzido na última versão. Apesar de eu não ter tido sucesso com a correção desse problema, o NDepend conseguiu me mostrar claramente todos os pontos de código que foram alterados de uma versão para a outra desse assembly da DevExpress.

Custos e versão trial

O NDepend não é uma ferramenta gratuita. No momento da escrita desse artigo, a licença para o NDepend está saindo por € 399,00 no primeiro ano (renovações saem com um desconto de 40%), sendo que as assinaturas de 2 e 3 anos também contam com descontos.

Se você quiser testar o NDepend, existe uma versão trial de 14 dias disponível na página de downloads.

Concluindo

Sem dúvida nenhuma o NDepend é uma ferramenta muito interessante, que produz informações significativas relacionadas ao código das nossas aplicações. Ela tem alguns pontos a serem melhorados (o principal deles sendo a questão de não conseguirmos ignorar ocorrências de um problema), mas com certeza é uma ferramenta que vem a agregar valor.

Entretanto, eu tentei analisar o principal projeto da empresa onde eu trabalho (projeto o qual é bem grande, como mencionei anteriormente) e eu acabei ficando bem confuso. O conjunto de regras do NDepend é bem abrangente, e ele acabou detectando trocentos problemas no projeto que, apesar de fazerem sentido, muitas vezes não podem mais ser ajustados sem causar breaking changes nos produtos derivados. Nesse caso, ao invés de corrigir os problemas existentes, o NDepend serviria mais como uma ferramenta de apoio para que nós não implementemos mais código ineficiente daqui para frente.

E aí, achou a ferramenta interessante? Então eu sugiro que você baixe e teste a versão trial. Eu acredito que você conseguirá obter alguns insights bem interessantes com essa ferramenta. E você não tem nada a perder. Como eu disse no início do artigo, a instalação é muito simples e não deixará rastros no seu computador se você optar por não continuar utilizando o NDepend depois que o trial acabar.

Antes de me despedir, convido você a inscrever-se na minha newsletter. Ao fazer isso, você receberá um e-mail toda semana sobre o artigo publicado, ficará sabendo em primeira mão sobre o artigo da próxima semana e receberá também dicas “bônus” que eu só compartilho por e-mail. Inscreva-se utilizando o formulário logo abaixo.

Até a próxima!

André Lima

Como podemos esconder o console de uma Console Application? Repetindo o cabeçalho do Tablix em todas as páginas no Report Viewer