Afinal, quando é natural dar um tempo para refactoring e quando é um sinal que o projeto está quase afundando?
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.
É 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...
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.
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:
É 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:
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?