Refatoração de código

O principal objetivo de refatorar o código é combater débitos técnicos. Todo mundo faz o possível para escrever um excelente código. Provavelmente, não existe um programador que crie código ruim de proposito. Mas em que momento o código se torna ruim?

Acelerar o modelo de desenvolvimento pode temporariamente dar certo, pois nesse processo normalmente se passa a ignorar testes para novos recursos, e em alguns casos passa a executar demandas sem o adequado conhecimento do negócio, mas isso diminuirá gradualmente o progresso, podendo gerar problemas em produção e muitas vezes precisando refazer o trabalho ou refatorar muito código.

Principais causas do débito técnico

Pressão das áreas de negócio

Às vezes, as circunstâncias comerciais podem forçá-lo a implementar os recursos antes que eles estejam completamente planejados, faltando documentação, faltando conhecimento necessário para executar a tarefa. Nesse caso, possivelmente aparecerão “gambiarras” no código para ocultar as partes inacabadas do projeto.

Falta de entendimento do custo dos débitos técnicos

Às vezes, seu empregador pode não entender que a débito técnico tem custo alto e pode gerar retrabalho, pois normalmente surgem bugs que precisam ser corrigidos e isso impacta a evolução do produto, pois é gasto tempo do time para corrigir coisas que poderia ter sido feitas da forma correta. Isso pode tornar muito difícil dedicar o tempo da equipe à refatoração, porque a gerência não vê o valor disso e gasta mais tempo e dinheiro corrigindo bugs ao invés de realizar refatoração.

Deixar de criar uma arquitetura coesa e difundir ao membros do time de desenvolvimento

É quando o projeto vira a um monólito e não um produto de módulos individuais em formato de microserviços. Nesse caso, qualquer alteração em uma parte do projeto afetará outras. O desenvolvimento da equipe fica mais difícil porque é difícil isolar o trabalho sem afetar outras partes do sistema.

Falta de testes

A soluções rápidas incentivam a não realizar testes, que nos piores casos essas alterações são implementadas e implantadas diretamente em produção sem a devida validação. As consequências podem ser catastróficas. Por exemplo, um hotfix de aparência inocente pode enviar um e-mail de teste estranho para milhares de clientes ou, pior ainda, liberar ou corromper um banco de dados inteiro.

Falta de documentação ou conhecimento do negócio

Isso atrasa a introdução de novas pessoas no projeto e pode interromper o desenvolvimento se as pessoas-chave deixarem o projeto.

Falta de interação entre os membros da equipe

Se a base de conhecimento não for distribuída por toda a empresa, as pessoas acabarão trabalhando com um entendimento errôneo dos processos e informações sobre o projeto. Essa situação pode ser exacerbada quando os desenvolvedores são treinados recebendo informações incorretas de seus mentores.

Desenvolvimento simultâneo a longo prazo por várias equipes

Isso pode levar ao acúmulo de débito técnico, que é aumentada quando as alterações são “mergeadas”. Quanto mais alterações forem feitas isoladamente, maior será o total do débito técnico.

Falta ou demora na Refatoração

Os requisitos do projeto estão mudando constantemente e, em algum momento, pode se tornar óbvio que partes do código ficam obsoletas, tornaram-se complicadas e precisam ser reprojetadas para atender a novos requisitos.

Por outro lado, os programadores do projeto estão escrevendo um novo código todos os dias que funciona com as partes obsoletas. Portanto, quanto mais tempo a refatoração for adiada ou não realizada, mais código dependente precisará ser reformulado no futuro.

Falta de monitoramento de conformidade

Isso acontece quando todos que trabalham no projeto escrevem o código como acharem melhor sem nenhum tipo de coesão entre os membros da equipe.

Incompetência

É quando o desenvolvedor simplesmente não sabe escrever código decente e muitas vezes por falta de estudo adequado, produz código ruim gerando “débito técnico”.

Quando refatorar

Ao adicionar um recurso

• A refatoração ajuda a entender o código de outras pessoas. Se você precisar lidar com o código ruim de outra pessoa, tente refatora-lo primeiro. “Clean code” é muito mais fácil de entender. Você o aprimorará não apenas para si mesmo, mas também para aqueles que irão usar depois de você.
• A refatoração facilita a adição de novos recursos. É muito mais fácil fazer alterações em um “clean code”.

Ao corrigir um bug

Os erros no código se comportam exatamente como os da vida real: eles vivem nos lugares mais escuros e mal feitos do código. Limpe seu código e os erros praticamente se descobrirão.

Os gestores apreciam a refatoração proativa, pois elimina a necessidade de adicionar tarefas especiais de refatoração posteriormente. Líderes felizes fazem programadores felizes!

Durante uma revisão de código

A revisão do código pode ser a última chance de organizar o código antes que ele se torne disponível ao público.

É melhor executar essas revisões em um par com um autor(es). Dessa forma, você pode resolver problemas simples rapidamente e avaliar o tempo para corrigir os mais difíceis.

Como refatorar

A refatoração deve ser feita como uma série de pequenas alterações, cada uma delas tornando o código existente um pouco melhor e ainda deixando o programa em boas condições de funcionamento.

Lista para realizar uma refatoração de maneira correta

O código deve ficar mais limpo “Clean code”.

Se o código permanecer ruim após a refatoração … desculpe, mas você perdeu uma hora da sua vida. Tente descobrir por que isso aconteceu.

Isso acontece frequentemente quando você se afasta da refatoração com pequenas alterações e tenta fazer uma grande mudança. Portanto, é muito fácil perder a cabeça, especialmente se você tiver uma data muito próxima para realizar a entrega.

Mas isso também pode acontecer ao trabalhar com código extremamente mal feito. O que quer que você melhore, o código como um todo continua sendo um desastre.

Nesse caso, vale a pena pensar em reescrever completamente partes do código ou até mesmo a separação em serviços menores caso seja um monólito. Mas antes de fazer isso, é bom você escrever testes e ter tempo hábil para realizar a refatoração.

Novas funcionalidades não se misturam com refatoração.

Não misture refatoração e desenvolvimento de novos recursos. Tente separar esses processos para não gerar mais problemas ao invés de corrigi-los.

Todos os testes existentes devem passar após a refatoração.

Há dois casos em que os testes podem ser interrompidos após a refatoração:

• Você cometeu um erro durante a refatoração: vá em frente e corrija o erro.
• Seus testes foram de nível muito baixo. Por exemplo, você estava testando métodos particulares de classes. Nesse caso, os testes são os culpados. Você pode refatorar os testes ou escrever novos testes de nível superior. Uma ótima maneira de evitar esse tipo de situação é escrever testes no estilo BDD.

Bom pessoal, essa foi apenas a introdução do que vem por ai, nos próximos posts falarei sobre técnicas para refatorar código. Até mais..