O segundo post da série Baixa Qualidade Interna de Software.

Realizar uma refatoração grande¹ de software não é algo simples. Há muitos pontos que você deve considerar, desde o planejamento e priorização até a motivação e execução da equipe. Entender esses pontos de forma estruturada e clara faz parte do processo. A boa notícia é que já passamos por essa situação antes e aprendemos quais os pontos principais com os quais você deve se preocupar.

Aqui estão os pontos principais que você deve considerar ao planejar e executar uma refatoração grande do seu sistema.

1. Defina metas de negócios

Uma refatoração grande de software não deve ser iniciada sem metas de negócios claras, caso contrário, você pode sofrer com a falta de comprometimento das partes interessadas. Aqui estão alguns exemplos de metas:

• O objetivo da refatoração é possibilitar a conexão de vários gateways de pagamento.
• O objetivo da refatoração é melhorar a velocidade de entrega.
• O objetivo da refatoração é viabilizar uma arquitetura multi-tenant para simplificar operações de infraestrutura.

2. Faça a medição do progresso

Em sua essência, o processo de refatoração de software é um esforço técnico, razão pela qual é comum não medir o progresso de forma estruturada, como é medido o progresso do desenvolvimento de novas features. Não caia nessa armadilha.

Assim como cada tarefa em um projeto, uma refatoração deve sempre ser planejada e medida.

3. Preste atenção à motivação da sua equipe

Trabalhar em base de código legado pode desmotivar os desenvolvedores, especialmente se não conseguem visualizar o progresso de suas atividades, ou se não sabem quando vão acabar. Ao passar por um processo de refatoração, você deve ter isso em mente.

Mostre à sua equipe que estão avançando. Planeje pequenas entregas, para viabilizar liberações contínuas e celebrar o bom trabalho feito. Além disso, pense em rotacionar os desenvolvedores para essa tarefa de refatoração, pois pode ajudar a manter a motivação.

4. Defina sua abordagem: puxada ou empurrada?

Você vai melhorar a base de código apenas quando encontrar um problema, ou escolherá de forma proativa as partes a melhorar?

Clique aqui para assistir o webinar Migração de Plataforma Tecnológica. É grátis!

5. Priorização

Se você tem uma meta de negócios clara, é mais fácil escolher proativamente as partes que precisam ser melhoradas para alcançar a meta. Com as partes listadas, você pode priorizar, como de costume.

Por outro lado, se você imagina que a base de código inteira deve ser refatorada, priorizar torna-se complicado, porque não há uma ou duas partes principais que precisam de melhorias, há muitas. É difícil saber por onde começar.

Uma solução é pedir ao time para avaliar a complexidade e churn do código para apontar as partes a refatorar. Para chegar numa conclusão se o código deve ou não ser refatorado, eles tem de se perguntar:

• A complexidade dessa classe é muito alta comparada às outras?
• Precisamos fazer mudanças constantes nesse arquivo?

Se ambas as respostas forem sim, essa parte do código parece um bom candidato para refatoração. Trace um gráfico de “complexidade de classe X churn”, priorize as partes que são mais complexas e que passam por alterações com frequência.

As partes do código que tem complexidade alta e que sofrem poucas modificações não são boas candidatas para serem refatoradas. Isso porque apesar de feias, funcionam. E também tem pouco impacto no desenvolvimento, já que a os desenvolvedores precisam modificá-las pouco no seu dia a dia.

6. Defina o “pronto”

O processo de refatoração de software pode se transformar em esforço infinito se você não planejar, priorizar e medir o progresso. Você deve tratá-lo como um projeto. Deve ter começo, meio e fim.

7. Cobertura da suíte de testes

A refatoração deve melhorar o que já está funcionando, sem quebrar nada. Certifique-se que a cobertura de testes está adequada, caso contrário, o processo pode gerar mais bugs do que melhorias de qualidade.

8. Desempenho da suíte de testes

Se a suíte de testes é lenta, refatorar também se tornará um processo lento, visto que a refatoração de software é fortemente baseada na execução contínua dos testes. Assegure que o desempenho da suíte de testes não seja um gargalo.

9. Compromisso dos patrocinadores

O processo de refatoração pode levar muito tempo: semanas, meses. Durante esse período, a velocidade das entregas de novas features será comprometida.

Certifique-se que stakeholders das áreas de negócio entendam os objetivos e a natureza desse tipo de trabalho para evitar que eles desistam no meio do caminho.

E você tem alguma dica além dessas para grande refatoração de software? Compartilhe conosco!

Leia os outros posts da série Baixa Qualidade Interna de Software

1. Sintomas da Baixa Qualidade Interna de Software
2. 9 Pontos-chaves ao se fazer uma refatoração grande de software você está lendo
3. 8 pontos-chaves para reescrever um software