Refactoring Cycle para projetos sem tempo para refactoring
Sabe quando a gente inicia em um projeto difícil de mexer, aquele código mais grudado que o pessoal dos blocos de carnaval (saudades carnaval). Então, esse artigo vai falar um pouco sobre como tenho trabalhado com código legado. Chega aqui, que é a festa do clean coach ♡
Então, se o projeto está difícil de manter, é só jogar tudo fora e começar tudo de novo?
Não, por favor!
Começar do zero, normalmente, não é uma boa opção. Mas existem casos onde o projeto já está engavetado a muito tempo, defasado, sem documentação e com complexidade muito alta, nesses cenários pode ser interessante sim iniciar um novo projeto.
Mas, imagine um cenário onde o projeto está em produção, rodando para muitos cliente, se os desenvolvedores são deslocados para criar um sistema do absoluto zero, com os mesmos processos, sem preocupação com boas práticas de código, sem arquitetura bem definida, aquela loucura que existe sempre em todos os projetos vivos. O que garante que dessa vez vai ser diferente? Mesmo com mais maturidade e conhecimento das regras de negócio, as chances de gerar novamente um código legado dificil de mexer, são grandes. (Essa é uma orientação do livro Clean Code)
Então vamo chorar todo mundo junto pelo resto da nossa vida de dev mortal ? Eu adoro um drama (◔◡◔)
As estratégias de refactoring que tenho utilizado para facilitar o onboarding e constantes updates desses códigos lindos #sqn, incluem esse refactoring cycle:
Quando o projeto tá mais junto que a galera do bloco de carnaval, iniciamos com a modularização, respeitando o principio da responsabilidade única (SRP) do SOLID. Se você acha legal criar um conteúdo para SOLID, comenta?
Depois que conseguimos entender cada módulo do software, utilizar testes é uma ótima prática. Código testado tráz mais segurança para as entregas e facilita a implementação de novas features. E um ponto interessante, se está muito difícil de testar, provavelmente você não finalizou a etapa de modularização, por isso esse ciclo de modularização e teste tem uma conexão forte.
Existe um módulo que poderia também estar na figura, que é a documentação. No entanto, não descrevemos como uma etapa pois ela normalmente é pouca ou inexistente. É mais comum essa preocupação surgir com maior maturidade do projeto. Não existe regra, mas o ideal seria que o projeto já começasse com técnicas de documentação viva. Pois essa prática descentraliza informações, descentralização de informação gera maior produtividade e pouca dependencia pra realizar o trabalho (pensa naquela informação importante que foi embora junto com aquele dev ultra mega blaster que saiu da empresa).
Com o código bem testado, mudanças de performance podem ser aplicadas, tendo o foco de melhorias de arquitetura em pontos específicos do software ou em toda a arquitetura do sistema. Nessa etapa, são considerados fatores que estarão além da vontade de ter um sistema bonito, mas também as necessidades de negócio e financeira. Em arquitetura de software existe uma imensidão de "depende" para ser analisada, mas o mais importante é que seja simples de entender (nunca é, mas eu precisava fazer um clean coach aqui) .
Essa hora que você me diz:
"Muito lindo falar, né querida. E o TIME TO MARKET?
Na vida real ninguém quer me dar tempo pra mudar nada, quando eu falo em refactory é um Deus nos acuda. "
(◔◡◔)
Buffer Refactoring Method
Esse "método" é muito simples, e é ideal para quando o projeto não tem tempo para refactory.
Nas cerimonias de planning ou groomming, é quando normalmente os desenvolvedores definem qual é o tempo para implementação de cada tarefa. Ao realizar a definição do tempo total para entregar a tarefa considere um tempo extra, que será o tempo de refactoring.
Nesse caso, o refactoring vai estar especificamente associado ao escopo da tarefa em questão. Ou seja, só o código afetado pela tarefa poderá ser refatorado. Essa forma tem se mostrado bem produtiva, os pontos positivos que eu citaria:
- Pessoas de produto tem mais visibilidade sobre o que está sendo feito, portanto, aceitam mais facilmente as alterações.
- O código já deverá ser testado, então não acrescentamos tarefas de teste.
- É mais fácil manter a entrega das sprints, pois o refactoring é inserido junto com as correções de bug.
Essa método é muito bom para esses cenários de software que precisa muito ser entregue logo. É interessante informar para o time de produto, negociar esse refactoring falando de todos os ganhos que o projeto terá, como entrega mais consistente, rápida e com mais segurança.
Coloque o seu lado Dev professor(a) e negociador(a) para trabalhar, mas se você não conseguir convencer as pessoas, faça o seu trabalho da mesma forma, afinal você e a empresa serão super impactados com a permanencia de código ruim.
Curtiu o #CleanCoach ? Deixa seu comentário aqui ♡
Achou que está tudo errado? Deixa se comentário também, quanto mais rápido a gente corrige, melhor ! ♡
