Analisadores de Código do Roslyn: o conceito por detrás do conceito
O recente lançamento do Visual Studio 2015 Preview trouxe, dentre diversas novidades, uma que despertou a atenção da comunidade de desenvolvedores .NET: os analisadores de código (“code analyzers”). Isso porque desde que o novo compilador gerenciado do C# e VB (codinome “Roslyn”) foi anunciado, um dos tópicos mais discutidos nas rodas de desenvolvedores era “o ReSharper está com seus dias contados!”
Afinal, quase toda demo de Roslyn mostrava como inspecionar o código-fonte à medida que ele era digitado, sendo compilado e disponibilizado em tempo real através dos serviços do compilador, de modo que fosse possível sugerir correções de código (“code fixes”).
Agora que o VS2015 está disponível para experimentação, finalmente a comunidade open-source de .NET tem a oportunidade de materializar seu sonho de “matar” o ReSharper, oferecendo nativamente no Visual Studio os mesmo recursos que até então só estavam disponíveis em ferramentas comerciais como o próprio ReSharper e seus concorrentes (como o CodeRush).
O que ninguém ainda havia te contado é que o recurso de Code Analyzers não foi criado para ser um substituto do ReSharper. Esse é apenas um efeito colateral positivo. O propósito real é o de corrigir as limitações de uma outra ferramenta do Visual Studio: o Code Analysis (também conhecido como FxCop).
Consertando o “inconsertável”
O FxCop (incorporado ao Visual Studio com o nome de Code Analysis) era, originalmente, uma ferramenta criada pelo time do .NET Framework para inspecionar o código do próprio .NET, de modo a reduzir o risco de produzirem código inadequado para um framework com a abrangência e criticidade do .NET (daí o nome FxCop, ou “Framework Cop”).
Apesar de extremamente útil, a ferramenta de Análise de Código do Visual Studio, em sua atual implementação baseada no FxCop original, tem diversas limitações. Algumas delas são:
- Feedback lento: O FxCop analisa código compilado. E como ele é uma ferramenta externa ao compilador, precisa esperar que este produza os assemblies antes de poder fazer seu trabalho. Com isso, para se obter algum feedback do FxCop é necessário primeiro compilar o projeto para, então, fazer a análise estática do código (que, por si só, já é lenta). Resumo da ópera: muitos desenvolvedores deixavam de usa-lo para não ter de ficar esperando preciosos segundos a cada compilação;
- Resultados pouco práticos: Ainda que o FxCop tenha regras úteis e que deveriam ser seguidas para garantir um mínimo de consistência em seu código .NET, o fato é que para muitos desenvolvedores as mensagens do FxCop são totalmente crípticas. O que devo fazer ao receber um alerta de regra violada? Qual correção devo fazer no meu código para atender à regra? Na maioria das vezes, isso não ficava claro;
- Difícil de estender: Frequentemente, em meus trabalhos com ALM/TFS, sou questionado por clientes se é possível criar regras personalizadas para o FxCop/Code Analysis. Minha resposta é “sim, é possível. Mas é mais fácil achar dinheiro no chão do que criar uma regra para o FxCop.” Não há um SDK formal, e a documentação se restringe a um poucos blogs espalhados pela internet. Estimulante, não?
- Difícil de distribuir: Mesmo que você eventualmente conseguisse criar sua regra personalizada, distribuí-la não seria exatamente a coisa mais fácil do mundo. Seria necessário instalar o assembly com suas regras na máquina de cada desenvolvedor, bem como em seus servidores de build. Esqueça de uma única máquina e seu processo fica comprometido.
Com o novo modelo de Analisadores de Código introduzido pelo Roslyn, o time de produto endereçou os pontos acima de maneira exemplar. Dê uma olhada no que mudou.
Feedback mais rápido
O serviço de análise de código agora é provido pelo próprio compilador. Ou seja, a compilação e a análise acontecem de forma contínua e transparente, de modo que o feedback possa ser provido no melhor momento possível: no instante em que o código é digitado. Ou seja, ao invés de ter de esperar a compilação e a posterior análise do FxCop, agora temos esse processo acontecendo em tempo real.
Sugestão de Correções
Este é o ponto que leva as pessoas a acreditar que estamos falando de um “substituto do ReSharper.” Mas a motivação aqui é outra: já que minha ferramenta de análise de código detectou um problema potencial, ao invés de simplesmente direcionar o desenvolvedor para uma documentação sobre o problema – e deixar a cargo do desenvolvedor entender como corrigir o código – por que não já oferecer logo sugestão de correção?
Esse acaba sendo o melhor dos mundos: não apenas um problema potencial foi apontado, mas uma correção potencial foi também sugerida e pode ser aplicada ao código sem depender do desenvolvedor ter de reescrever esse código por conta própria.
Fácil de estender
Agora finalmente há um SDK para a criação de regras personalizadas para o FxCopRoslyn. Essas regras (chamadas de analyzers na nomenclatura do Roslyn) são muito mais fáceis de ser implementadas, graças ao novo modelo de interação com o compilador e de acesso à árvore de sintaxe do código – que agora atua sobre o código-fonte e não sobre o código compilado, permitindo fazer coisas que não eram possíveis para o FxCop – por exemplo, integrar regras de estilo de código (tais como as do StyleCop). Não é surpresa, portanto, que projetos como o CodeCracker (iniciado por MVPs brasileiros) esteja produzindo tantas regras em tão pouco tempo!
Fácil de distribuir
Essa foi, para mim, uma das maiores surpresas do novo modelo. Analisadores personalizados podem ser incorporados a um projeto e distribuídos via… NuGet! Nada mais de instalar assemblies nas máquinas de desenvolvedores e em servidores de build. O NuGet faz a mágica para nós, através de seu package restore.
Conclusão
Temos um belo futuro pela frente. A tecnologia do FxCop já estava obsoleta e pedindo por uma atualização há vários anos. O novo serviço de compilação introduzido pelo projeto Roslyn resolve essas e outras limitações com maestria. Agora é a hora de se envolver, estudar mais sobre a tecnologia e dar asas à imaginação. Que tipos de analisadores de código você gostaria de ter em sua empresa?
Um abraço,
Igor
24/11/2014 | Por Igor Abade V. Leite | Em Técnico | Tempo de leitura: 5 mins.
