Antes, o conceito. Segundo o ChatGPT:
Refactoring é o processo de alterar a estrutura interna de um código sem mudar sua funcionalidade externa. Isso pode ser feito por várias razões, como tornar o código mais legível, mais fácil de manter ou mais eficiente. Refactoring é uma prática importante em desenvolvimento de software, pois ajuda a manter o código limpo e organizado, o que pode tornar mais fácil adicionar novas funcionalidades e corrigir erros.
Se você já tiver se deparado com o termo refactoring, muito provavelmente deve ter sentido arrepios. Isso porque se trata de reestruturação de código, algo que muitas empresas, principalmente startups, uma hora ou outra acabam precisando.
É fácil entender o motivo: digamos que uma startup tivesse que validar um produto rapidamente no mercado. Para isso, ela pode ter partido de uma aplicação low-code ou simplesmente partido de uma API, ou biblioteca básica de JavaScript, por exemplo.
Com a necessidade de justificar aporte, o produto foi sendo moldado a partir de uma estrutura pouco escalável. Resultado? Vai chegar uma hora que a aplicação ficará pesada, com baixa performance ou até mesmo limitada a inovações.
Grandes empresas também passam por problemas semelhantes, seja na hora de criar um produto para ampliação do portfólio, para adequar produtos adquiridos em sua estratégia de M&A ou para dar escalabilidade para algo que já tenha sido validado.
Sendo bem simplista, refactoring deveria ser uma preocupação apenas do time de Tecnologia. Mas, como todo produto ou serviço digital é geralmente construído a partir de código, toda e qualquer iniciativa de refactoring impacta o seu produto.
A seguir, trago alguns erros e aprendizados que tive lidando com o tema refactoring como Product Manager.
1) Achar que produto pode liderar um refactoring
Mudança de código deve ser feita e liderada pelo time de Tecnologia. O que acontece é que, em muitas estruturas, não existe uma distinção clara entre produto e tecnologia. Já vi acontecer casos de conflitos de interesse: um se preocupa mais com segurança, outro em métricas de negócio e, por fim, com receio de um desdobramento conflituoso dessas estratégias, as coisas não ficam claras para o time (produto e engenharia).
Em busca de ter algum tipo de destaque, o Product Manager pode acabar tomando a frente da implementação de um projeto que certamente lhe dará visibilidade. Infelizmente, caí nessa armadilha ao me deparar com essa situação: liderando um time de Plataforma, reuni os engenheiros mais seniores da companhia, fiz diversos alinhamentos e estabelecemos um plano para estruturar o refactoring do produto.
Porém, outras necessidades foram entrando no meio e, sem autonomia para tomadas de decisão nesse sentido, o refactoring foi sendo postergado. A boa notícia é que, em dado momento, tive a oportunidade de montar o time que cuidaria disso. Mas, até isso acontecer, muitos murros em ponta de faca, tentativas, acertos e erros consumiram os times envolvidos. Pior de tudo: perdemos tempo. E tempo, vocês sabem…
2) Juntar refactoring com redesign e design system
Refactoring tem a ver com mudar código. Redesign tem a ver com propor ou melhorar a experiência - quando não estiver conectado com uma estratégia de rebranding, que é outro assunto. E design system tem o propósito de padronizar os componentes do produto, com objetivo de dar escala ao desenvolvimento e gerar unidade visual no produto como um todo.
Enfim, sabendo da necessidade de refatorar o código, havia uma pressão dos executivos da companhia de melhoria de design.
Bom, se tanta coisa tinha que mudar, por que não casar tudo de uma vez, não é mesmo?
Por mais que tivesse alinhado essas duas iniciativas de uma só vez com o time executivo, a empresa não tinha os profissionais adequados no momento para essa condução. Além disso, o tempo era escasso, e o processo de redesign foi conduzido basicamente por meio de análise heurística - com pouca leitura, contextualização e debate dos dados gerados pelo produto.
Por fim, o refactoring veio com uma nova proposta de design. Conduzimos testes de usabilidade e realizamos rollout de forma progressiva. Porém, alguns elogios do público não foram o suficiente para o valor esperado. Perdemos a oportunidade de fazer um diagnóstico crítico do produto para acelerar o dual tracking do redesign e do refactoring. Deu certo, mas gerou pouco valor.
Faltou seguir uma das regras de ouro de Martin Fowler, que dedicou um livro inteiro a este assunto:
“Melhorar o design depois que tiver escrito código”. É uma frase estranha. Pelo nosso entendimento atual de desenvolvimento de software, acreditamos que nós fazemos o design e, então, codamos. Um bom design vem antes, e o código vem em seguida. Ao longo do tempo, o código será modificado, e a integridade do sistema, além de sua estrutura, de acordo com aquele design, gradualmente desaparece. O código afunda lentamente da engenharia para hacking”.
Em resumo, primeiro você propõe uma mudança de design para, então, seguir com escrita de código. No contexto em que atuei, isso significaria postergar a prioridade da refatoração de código - e o motivo é tema do próximo tópico.
3) Falta de apoio da liderança
Como o trabalho do refactoring não é tão visível, os alinhamentos e o buy-in da liderança eram complicados. Embora o CTO tivesse imposto a agenda do refactoring, as discussões com os demais líderes não dimensionaram a complexidade e a necessidade de comprometimento dos times.
Infelizmente, eram comuns discussões de cobrança para lidar com funcionalidades e desconfiança de diversos stakeholders executivos.
Em busca de lidar com essa gangorra, fiz uma divisão das pessoas que deveriam atuar com refatoração de código e com novas funcionalidades - sem esquecer, claro, dos bugs. A cadência do time melhorou, mas a falta de envolvimento da liderança complicou bastante o processo.
4) Não ter uma medição tangível dos ganhos
Refactoring é um trabalho a longo prazo: precisa de preparo dos líderes de engenharia, treinamento para os desenvolvedores, envolvimento do início ao fim dos testers e um longo processo de desenvolvimento - algo que pode facilmente levar 1 ano da concepção à entrega completa.
Geralmente, prevê-se uma melhora na performance da aplicação e na redução do tempo de desenvolvimento. Mas, como fazer esse comparativo, se não acompanhávamos essas métricas à risca antes do refactoring?
Embora o processo de redesign tenha sido concebido e executado com poucos recursos e pouco tempo, o refactoring exigiu um tempo maior. Além disso, faltou comprometer um engenheiro sênior da área de qualidade para acompanhar o processo do início ao fim.
Como líder dessa iniciativa, não dei a devida importância em entender em detalhes o impacto do código legado no produto para além de métricas de performance. Por mais que tivéssemos separado instâncias e funcionalidades como fatiamento do refactoring como um todo, um longo trabalho foi feito, em detrimento de outras atividades que poderiam alavancar as métricas de negócio do produto nesse decorrer.
Conclusão
No contexto que trouxe para este artigo, era mandatório fazer refactoring. Mas, para isso, não é necessário o envolvimento de um PM. É um alinhamento do time técnico de Engenharia, envolvendo arquitetura, desenvolvimento e qualidade.
Vale lembrar que o usuário final não está nem aí para o código - logo, o valor para o usuário final deveria ser refletido pelo menos em melhoria de performance. Isso aconteceu, claro, mas não conseguimos captar como isso se refletiu em tempo de desenvolvimento, agilidade nos deploys, entre outras métricas internas de produtividade.
Refactoring é um tema importante. Empresas grandes e startups, em algum momento, terão que lidar com revisão de código. Para isso, porém, é necessário que a liderança executiva de Engenharia conduza esse processo do início ao fim, seja na orientação aos Tech Managers, com a construção de um time técnico focado nessa iniciativa, com o buy-in da liderança e, principalmente, com clareza de onde se está e para onde se quer chegar.
Todo e qualquer produto é impactado por uma refatoração de código. Porém, isso precisa ser debatido e priorizado a nível estratégico, com protagonismo do time técnico e métricas apropriadas de acompanhamento e evolução.
