C# - A refatoração rumo ao código limpo - I

Hoje vamos iniciar a abordagem do conceito de refatoração tendo como objetivo obter um código limpo.

Podemos entender a refatoração como sendo o processo de reestruturação de um sistema com o objetivo de simplificar, tornar mais legível e diminuir o custo de manutenção do código sem alterar as funcionalidades do sistema.

Usando técnicas de refatoração você pode reestruturar partes do código do seu sistema alterando sua estrutura interna sem mudar o seu comportamento externo.

Assim, Refatorar é melhorar a estrutura do código de um sistema preservando as suas funcionalidades.  Os objetivos básicos de efetuar uma refatoração seriam:

O principal objetivo da refatoração é combater o que se chama de 'dívidas técnicas' transformando uma bagunça em um código limpo e um design simples.

Segundo a  wikipédia,  Dívida técnica é um conceito no desenvolvimento de software que reflete o custo implícito de retrabalho adicional causado pela escolha de uma solução fácil agora, em vez de usar uma abordagem melhor que levaria mais tempo.

Precisamos deixar claro o que é esse tal de código limpo. A seguir temos uma relação das principais características de um código que pode ser considerado código limpo:

1- Ele é óbvio para outros programadores

Um código com nomenclatura confusa e ineficiente com nomes não significativos, números mágicos, classes e métodos inchados  são o que tornam o código difícil de entender.

2- Ele não contém duplicação

Código duplicado esparramado pelo projeto faz com que a manutenção seja difícil de ser feita pois você tem que fazer o acerto em mais de um local no seu código. Isso aumenta o trabalho e retarda o progresso do desenvolvimento do seu projeto.

3- Ele contém um número mínimo de classes

Quanto menos código você tem menos código requer manutenção e isso implica em ter menos bugs. Um código limpo é simples, objetivo e focado na tarefa que tem que realizar.

4- Ele passa em todos os testes

Um código limpo vai passar em todos os testes, isso significa 100%.  Um código que passa em 95% dos testes não é um código limpo.

5- Ele é mais fácil e barato de manter

Um código limpo vai ser mais fácil manter e com isso o custo de manutenção cai.

Dívida Técnica - Conceito e causas

Como o objetivo da refatoração é combater as dívidas técnicas vamos entender o que isso significa e o que causa uma dívida técnica.

A princípio nenhum desenvolvedor escreve um código sujo de propósito. Todos querem fazer o melhor desde o princípio mas, seja por falta de conhecimento ou por inabilidade, muito código sujo acaba sendo produzido.

Mas em que ponto o código limpo se torna sujo ou impuro ?

A metáfora de “dívida técnica” em relação ao código impuro foi originalmente sugerida por Ward Cunningham.

Uma das principais causas da criação do código sujo é a pressa. Sim, isso mesmo, você pode acelerar temporariamente a criação do seu código escolhendo um caminho mais fácil e com menos esforço onde a criação de testes não é utilizada e assim aparentemente você esta ganhando tempo e seu projeto vai ser entregue mais rápido.

Acontece que isso vai apenas retardar a aparição dos problemas e quando eles surgirem o custo com certeza será maior para corrigir e realizar os testes.

Vejamos a seguir as principais causas das 'dívidas técnicas' :

Às vezes, as circunstâncias de negócios podem forçar você a implementar recursos antes que eles estejam completamente concluídos. Nesse caso, correções e gambiarras aparecerão no código para ocultar as partes não concluídas do projeto.

2-Falta de compreensão das conseqüências do código sujo

Às vezes, sua gerência pode não entender que a dívida técnica tem “juros”, na medida em que diminui o ritmo de desenvolvimento à medida que a dívida se acumula. Isso pode tornar muito difícil dedicar o tempo da equipe à refatoração, porque a gerência não vê o valor disso.

3-Falta de testes

A falta de feedback imediato incentiva soluções alternativas ou desastres rápidos, mas arriscados. Na pior das hipóteses, essas mudanças são implementadas e implantadas na produção, sem nenhum teste prévio. As consequências podem ser catastróficas. Assim, um simples código de aparência inocente pode enviar um estranho e-mail de teste para milhares de clientes ou, pior ainda, liberar ou corromper um banco de dados inteiro.

4-Falta de documentação

Isso retarda a introdução de novas pessoas no projeto e pode paralisar o desenvolvimento se pessoas importantes deixarem o projeto.

5-Falta de interação entre os membros da equipe

Se a base de conhecimento não for distribuída por toda a equipe, as pessoas vão acabar trabalhando com uma compreensão desatualizada dos processos e informações sobre o projeto. Esta situação pode ser exacerbada quando os desenvolvedores juniores são treinados incorretamente por seus mentores.

6-Refatoração adiada ou retardada

Os requisitos do projeto estão mudando constantemente e em algum ponto pode se tornar óbvio que partes do código estão obsoletas, se tornaram pesadas e devem ser reprojetadas para atender a novos requisitos.

Por outro lado, os programadores do projeto estão escrevendo novos códigos todos os dias que funcionam com as partes obsoletas. Portanto, quanto mais a refatoração for adiada, mais código dependente terá que ser retrabalhado no futuro.

7-Falta de monitoramento de conformidade

Isso acontece quando todos que trabalham no projeto escrevem o código como acham adequado (ou seja, da mesma forma que escreveram no último projeto).

8-Incompetência

Isso ocorre quando o desenvolvedor simplesmente não sabe como escrever um código decente.

Assim o objetivo da refatoração é evitar e também resolver os problemas decorrente das dívidas técnicas.

A seguir veremos quando devemos iniciar a refatoração.

"Mas, se o nosso evangelho ainda está encoberto, é para os que se perdem que está encoberto, nos quais o deus deste século cegou o entendimento dos incrédulos, para que lhes não resplandeça a luz do evangelho da glória de Cristo, o qual é a imagem de Deus."
2 Coríntios 4:3,4