O artigo apresenta a ferramenta ReSharper, um add-in que se integra totalmente ao Visual Studio, auxiliando o programador a realizar refatorações e também durante a própria escrita do código fonte através de dicas “online”. Será demonstrado como a ferramenta auxilia a manter um código mais limpo, mais legível e consequentemente mais fácil de manter.
Em que situação o tema é útil
A qualidade do código que escrevemos é de extrema importância para qualquer organização. Não é raro encontrar códigos com elevado grau de dificuldade de compreensão. Mesmo códigos legados podem ser melhorados com o auxílio de ferramentas. Diante desse cenário, vamos ver como podemos tornar nosso código mais expressivo no nosso dia a dia.
Melhorando o código com ReSharper
Cada vez mais fica evidente a importância da qualidade do código. Seja para simples compreensão ou para a redução de custos. Isso mesmo, pois sabemos que quando mantemos um código profissional e de qualidade, a manutenção e a extensão tornam-se menos custosas financeiramente. Veremos quais são os impactos de um código ruim, alguns fatores que podem levar um desenvolvedor a escrever códigos de má qualidade, qual a nossa culpa nesse cenário e como podemos melhorar essa situação. Entenderemos como o ReSharper pode contribuir para um código mais limpo e de fácil manutenção. Veremos alguns recursos da nova versão como a transformação de expressões LINQ em códigos for e foreach, veremos também um recurso bastante interessante que permite o desenvolvedor descompilar e navegar pelos fontes tipo, método ou dll sem que se tenha o código fonte desse item. Vamos entender como podemos aprimorar a geração de testes de unidade fazendo o uso dos templates do ReSharper.
Escrever códigos para as aplicações é algo que faz parte do dia a dia de todo programador. Esse tipo de atividade é uma prática diária que exercemos com algum propósito, se caracteriza em resolver problemas, corrigir falhas ou adicionar novas funcionalidades em algum produto. Como toda atividade rotineira, é natural que venhamos a melhorar com o passar do tempo, mas isso não é uma regra, os motivos são os mais variados, algo nada surpreendente quando estamos falando de desenvolvimento de software.
Não há nenhuma novidade em dizer que devemos sempre procurar escrever um código que possua uma boa estética, que seja fácil de entender e fácil de manter. Sabemos que essas características não estão presentes em uma boa fatia dos softwares que produzimos. Muitos dos nossos códigos já nascem legados, nascem sem o emprego de boas práticas, sem preocupação com futuras alterações, isso é também conhecido como dívida técnica, ou seja, em algum momento futuro, distante ou não, virá à cobrança, o problema é que ela sempre vem muito maior do que quando foi gerada. Além dos fatores técnicos, há também os custos envolvidos nesse cenário, pois será necessário mais esforço para que alguma modificação possa ser feita nesse código.
Diversos são os motivos que levam a escrever códigos de má qualidade. Fatores como prazo apertado, inexperiência do desenvolvedor, comprometimento profissional além de outros, acabam por resultar em inúmeras ocorrências de códigos ruins. Obviamente que nenhum desses fatores é justificativa para que venhamos a escrever códigos dessa forma. Quando trabalhamos com códigos que são feitos sem a preocupação do uso de boas práticas de desenvolvimento, tudo fica mais difícil. Em boa parte dos casos a própria pessoa que escreveu aquele código, sequer o entende passado algum tempo. Quando outro desenvolvedor precisar fazer uma manutenção em um código desses, a situação piora muito, o tempo desprendido para a compreensão daquele código é extremamente grande, isso se depois de todo esse tempo houver alguma compreensão.
Um software escrito dessa forma tem um custo altíssimo de manutenção, e o seu futuro será tornar-se um software legado e que poucas pessoas poderão realizar alguma alteração. Existem casos em códigos de péssima qualidade levaram a empresa à extinção, ou seja, o problema que temos nas mãos é bem grande e precisamos mudar esse cenário de caos. Outro fator a ser considerado é a falsa percepção de produtividade que empregamos nos projetos, é falsa porque durante o início da codificação parece muito mais produtivo escrever códigos sem se preocupar com os códigrita (linhas desnecessárias), se não há ou poderá haver repetições de blocos de códigos que torna muito difícil uma manutenção futura e dessa forma à medida que o projeto avança, a produtividade tende a cair cada vez mais.
Por que escrevemos códigos ruins?
Essa é uma pergunta que pode ter (e tem) várias respostas, mas algumas são comuns em diversos casos. Além de alguns fatores já citados, existem outros de ordem maior que influenciam muitas vezes de forma inconsciente, mas perceptível a escrita de códigos ruins. Um desses fatores é o cronograma mal elaborado de um projeto de software. Nesse caso estamos trabalhando com um gargalo de tempo, os prazos estão muito apertados e para que seja possível a entrega na data proposta (ou com o menor atraso possível) a qualidade dó código é sacrificada. Nesse cenário, os desenvolvedores precisam fazer uma escolha entre a qualidade e o prazo, e o escolhido sempre é o prazo.
Outro ponto a ser destacado, é a falta de prática. Todo profissional de áreas como a música, esportes e cinema, fazem treinos e ensaios regulares e isso os leva a melhorar sua técnica constantemente. No universo do desenvolvimento de software, isso ocorre em alguns casos isolados. Programadores não costumam praticar no intuito de melhorar suas técnicas de desenvolvimento, eles desenvolvem fora do horário de trabalho sim, mas envolvidos em outros projetos, projetos pessoais, testando ou pesquisando novas tecnologias, não há uma prática voltada para a escrita de códigos de maior qualidade.
...
