O que é refatoração?
Os desenvolvedores provavelmente podem pular esta seção.
Às vezes, quando você está trabalhando em um projeto, as coisas se encaixam de maneira rápida, mas de alguma forma não ideal. Funciona, mas não é bonito. Ou talvez até seja bonito, mas se você olhar de perto, não é REALMENTE bonito. Algo semelhante acontece na programação, onde as pressões de entrega no prazo, ou com uma determinada especificação, podem levar a escolhas e soluções que são mais rápidas de implementar no presente, mas são mais difíceis de trabalhar no futuro. O que também geralmente leva a um monte de desenvolvedores reclamando sobre “código espaguete” (pela confusão no código), “dívida de tecnologia” (devido ao retrabalho causado) e às vezes até “bus factor” (dependência de pessoas que podem sair a qualquer momento do projeto). Se os desenvolvedores tiverem sorte o suficiente, eles ainda estarão vivos quando um esforço de refatoração for feito: gastar tempo para revisar o código antigo e confuso e limpá-lo.
Por que refatorar o Status?
Quando começamos a montar o Status, fizemos várias escolhas como essa. Você pode ler sobre alguns deles em nosso post sobre a StatusQ. Ainda estávamos descobrindo a direção do Status e quais recursos queríamos no aplicativo. Acabamos escrevendo a maior parte do código de back-end em Nim, o que era novo para muitos de nós.
Tudo isso tornou o núcleo do aplicativo um tanto... vago no início. O desenvolvimento do aplicativo continuou e, à medida que mais e mais recursos foram adicionados, planos feitos, código escrito, o resmungo dos desenvolvedores atingiu um ponto muito alto... e uma refatoração foi solicitada. Percebemos que era insustentável a longo prazo continuar sem solidificar nossa base, por assim dizer.
Alguns dos objetivos do esforço de refatoração são:
- usar princípios SOLID em nosso código
- reescrever o backend em C++ em vez de Nim (o que é incrível! Mas não atendeu exatamente às nossas necessidades; problemas específicos foram a falta de herança múltipla e aninhamento de conceitos suportando apenas dois níveis)
- melhorar nossa estrutura de testes automatizados
- usar o Cmake para melhor compatibilidade com mais ferramentas de desenvolvimento
- melhorar a estabilidade de nossa biblioteca
vendor - documentar e padronizar a
status-lib, porque suporta múltiplas equipes - atualizar o frontend para Qt6
- encapsular melhor a lógica da interface do usuário nos
stores
Planejamos que a refatoração levasse aproximadamente um mês, mas mesmo naquela época estávamos imaginando que isso fosse um pouco otimista.
Começamos no dia 1º de outubro. Atualmente, a refatoração ainda está em andamento, mas fizemos muitas coisas importantes até agora, incluindo a refatoração dos store de interface do usuário. Algumas coisas importantes em que ainda estamos trabalhando são a reescrita do C++, a transição para o Cmake e a mudança para o Qt6.
Stores
Para um pouco mais de explicação sobre nossa Interface de Usuário e Qt, confira nosso último artigo (mencionado anteriormente) sobre a StatusQ! Os stores são objetos Qt não visuais que representam uma coleção de propriedades e funções que interagem com o backend. Esse isolamento de responsabilidade facilita o desenvolvimento e a colaboração do front-end e do back-end.
Então você tem uma refatoração pela metade…
Nós terminamos completamente partes de uma refatoração extremamente ambiciosa! E nossos desenvolvedores já atestam que o código está muito mais fácil de trabalhar - principalmente com o desejo de aderir aos princípios SOLID - e que o esforço de refatoração tornou nossos desenvolvedores melhores, dando a eles uma visão estendida da arquitetura multicamadas e ensinando muitas coisas novas. E manter as coisas mais simples significa menos frustração, confusão e esforço necessário para fazer alterações futuras na base do código. Se você quiser ver mais detalhes sobre o esforço de refatoração, você pode conferir alguns dos trabalhos feitos aqui.
É bom lidar com dívidas de tecnologia (tech debt).