Refatorações são polêmicas

Todo dia, conscientemente ou não, desenvolvedores fazem várias refatorações nos codebases de suas aplicações. Seja alterando nomes de variáveis e métodos, ou remodelando entidades do domínio, tendemos a incorporar o princípio escoteiro e melhorar os trechos por onde passamos.

Refatorar é uma prática encorajada por movimentos importantes, como por exemplo, Domain-driven Design e Test-driven Development. Alguns dos benefícios obtidos com isso são:

  • Deixar o código mais fácil de ser compreendido, e por consequência, mais fácil de ser mantido;
  • Fazer com que o código represente adequadamente o domínio da aplicação;
  • Melhorar a manutenibilidade da arquitetura;
  • Manter o crescimento do sistema em um ritmo sustentável;
  • E, principalmente, refatorar constantemente ajuda a manter o débito técnico sob controle.

Mas se os benefícios são tantos e tão claros, porque costumamos enfrentar resistências por uma parte dos stakeholders?

Diferenciando refatoração de melhoria técnica

É importante diferenciar refatoração de melhoria técnica. Ao refatorar, o programador adequa o código ao conhecimento compartilhado que o time tem sobre o domínio ou arquitetura. Com isso, se obtém os benefícios listados acima.

Por outro lado, refatorações geralmente são difíceis de se prever. É necessário estar escrevendo código para identificar os pontos a serem refatorados e essa atividade só é feita quando se inicia o desenvolvimento de uma tarefa. Logo, nem sempre isso pode ser previsto no planejamento ou estimativa de uma feature.

melhorias técnicas são ações quase sempre opcionais. Exemplos de melhoria são: segregação entre front-end e back-end, atualização da versão de uma biblioteca ou framework e melhorias não solicitadas na performance da aplicação.

É muito pouco provável que você tenha problemas com melhorias técnicas. Por serem tarefas opcionais, naturalmente o time envolve os stakeholders e isso é priorizado em conjunto.

O conflito

Eventualmente, quando algum desenvolvedor menciona que está trabalhando em uma refatoração, outras pessoas podem entender:

A aplicação já funcionava, mas estou melhorando o código. Logo, não estou trabalhando em funcionalidade.

Isso é um problema. Essa construção dá a entender que houve preciosismo do desenvolvedor e pode-se questionar seu compromisso com os objetivos do time. Parece uma melhoria técnica não solicitada e fora de hora.

Pessoas com olhos voltados ao negócio têm prioridades diferentes de pessoas com os olhos voltados para o desenvolvimento. E isso é uma coisa boa quando existe colaboração entre essas pessoas dentro do time.

Fornecer previsibilidade e minimizar riscos são responsabilidades de todas as pessoas em um time de software. Porém, infelizmente, na prática, não é bem assim. Nem todos os times têm maturidade suficiente para assumir esses compromissos em conjunto. Nesses casos, um gerente ou um outro líder costuma ser o responsável pela previsibilidade, mitigação de riscos e, até mesmo, por “assumir o compromisso da entrega”.

Em um cenário como esse, é muito fácil que surja desconfiança com as decisões que não são bem compreendidas. Qualquer potencial ameaça ao plano ou à entrega pode criar resistências.

Duas possíveis soluções

Nessas horas, é importante que se estabeleça confiança entre as pessoas de negócio e os desenvolvedores. Tente tirar todas as dúvidas e deixar todos na mesma página. Todos devem se lembrar que o time trabalha por um bem comum. Todos tomam as melhores decisões possíveis com o contexto e o conhecimento disponíveis.

Caso isso não seja possível, e em alguns momentos não vai ser, lembre-se quem é o responsável pela qualidade do codebase e quem sofre com isso diariamente. Mantenha-se pragmático, refatore e continue entregando valor. Vai ficar tudo bem.