Quando seu time pede um tempo para refactoring
Thiago Brito
18 de Fevereiro de 2019 4 minutos de leitura

Afinal, quando é natural dar um tempo para refactoring e quando é um sinal que o projeto está quase afundando?

Quando você está gerenciando um time de desenvolvimento sempre existe a necessidade de gastar um tempo para garantir que o código está em um bom caminho e continuará assim no futuro.

No artigo que falo sobre como lidar com a complexidade dos Unit Tests dou uma grande ênfase na capacidade do código de tender ao caos, sempre aumentando a entropia.

Além das necessidades de gerar valor aos clientes, quanto tempo devemos gastar melhorando nossos códigos? Quando criar novos testes, refatorar um determinado ponto do sistema ou até mesmo reescrever todo o código?

Antes de arrumar o código, comece analisando a cultura. O ato de refatorar, criar novos testes (não apenas Unit Tests), garantir que nada está sendo quebrado com a nova alteração é responsabilidade de todos e deve ser constante.

Os pequenos refactorings

É importante manter o desenvolvedor com foco no valor que deve ser entregue ao cliente. Código bem escrito é aquele mais simples, que faz o que se propõe e é fácil de ser mantido.

Pequenos refactorings devem ser continuamente estimulados dentro do time. E desta forma que o código fica fácil de ser mantido. Com mudanças pequenas as entregas aos clientes são pouco impactadas e a degradação do código é reduzida.

Negligenciar os pequenos refactorings do dia-a-dia, nos leva a um problema maior. Amado pelos desenvolvedores e temido pelos gestores, eles são:

Os grandes refactorings...

Os grandes refactorings

Chega um momento em que uma parte do código está um caos. Ninguém consegue mexer e quando mexem gera um efeito colateral causando outros bugs ou gerando instabilidade.

A dificuldade em criar Unit Tests é enorme, pois aquela parte do código traz uma enorme gama de dependências e efeitos indesejados.

Existem várias formas de trabalhar neste tipo de problema, um deles é isolar o monstrinho o mais rápido possível e deixar ele na jaula até alguém conseguir domar ele.

Tente separar em uma biblioteca, repositório bem isolado com suas próprias dependências bem geridas. Prepare o resto do sistema para usar este código da forma mais desacoplada possível.

Crie testes que exercitem o código problemático ao máximo, talvez Unit Tests não sejam os melhores. Talvez Integration Tests são mais eficientes... Aliás, não se atenha ao tipo de teste que irá criar, o importante é testar!

Somente depois disso seu time estará pronto para fazer experimentos que visam matar aquela área do código e trazer algo mais simples.

Existem varias técnicas para fazer isso, mais uma vez recomendo fortemente o livro Working Effectively With Legacy Code, ele mostra com exemplos diversas formas de simplificar o código isolando e garantindo que as alterações continuarão seguras e não gere um efeito cascata que impossibilita a liberação de versões no meio do processo.

Lascou, vamos reescrever todo o código!

Até que chega um dia que um desenvolvedor sugere para reescrever todo o código. Antes de sair reescrevendo tudo, é importante levar em consideração alguns pontos:

  • No tempo levado para reescrever o código, como serão geridas as melhorias do produto ao cliente final?
  • O código atual, mesmo ruim, já foi testado em produção, o que faz dele mais resiliente a diversos problemas que aconteceram nos últimos anos. O que faz acreditar que o novo código terá menos problemas do que o atual?
  • Por que chegamos neste ponto? Quais as razões que fizeram este projeto chegar no caos em que está agora? Se não houverem ajustes na cultura as chances do código reescrito chegar ao caos serão enormes no futuro!!!
  • É importante manter a cultura otimizada para identificar os problemas e resolve-los o mais rápido possível. Algumas atitudes que podem ajudar a garantir a boa qualidade:

  • Considere um tempo para refactoring na iteração
  • Faça Code Review e garanta que todos os desenvolvedores aceitem e levem a sério este processo
  • Defina padrões de código com todo o time e garanta que todos sigam de modo que o código fique mais consistente
  • Em implementações novas, escolham uma arquitetura que facilite o processo de alterações futuras, não tente prever tudo. Mantenha o código o simples possível
  • Fique de olho nos sintomas: novos códigos sem testes, correção de bugs geram outros bugs, falta de padronização, atrasos nas entregas, falta de propriedade coletiva de código. Podem ser indicativos de que a qualidade do código está sendo deixada de lado para entregas “rápidas”
  • Garantir a qualidade do código é algo que gera valor pro cliente com toda certeza! Afinal, desta forma você garante que as entregas sejam constantes e não tenham que ser interrompidas de tempos em tempos para limpar toda a casa e “refatorar tudo”.

    E aí... Você já fez seu refactoring hoje?