Esse é um conceito que sempre me deixou com uma pulga atrás da orelha. Uncle Bob cita isso em mais de um livro, e não consigo me imaginar fazendo isso num código da empresa em que trabalho.
Pense o seguinte cenário, peguei uma tarefa grande, que no final das contas vai dar uns 30 arquivos alterados no PR, se eu aplicar esse conceito de melhorar alguma coisinha sempre que eu puder, a tarefa dobra de tamanho e fica muito mais coisa pra quem for revisar.
Pode ser uma má interpretação minha, mas como fica pra resolver esse problema?
Fala, @felprangel! 🤙
Massa demais esse ponto que você trouxe! E faz total sentido. Se toda PR já vem daquele jeito, cheia de mudanças, sair melhorando tudo no caminho pode transformar o code review num verdadeiro modo hardcore. 😅
Mas a parada da Regra do Escoteiro não é sair refatorando geral sempre que der na telha (até porque aí vira "Refactor Driven Development" 😂). O ideal é ir na manha, aplicando melhorias pequenas e cirúrgicas que não impactem demais a PR. Tipo:
🔹 Ajustar um nome de variável que estava gritante de ruim. 🔹 Simplificar um if caótico, mas sem mudar toda a lógica do fluxo. 🔹 Extrair um método quando fica óbvio que algo pode ser reutilizado.
Agora, se a gente trombar com um monstro de espaguete, a real é que talvez seja melhor abrir um tech debt separado e discutir com o time. Senão, o PR vira um "refatora tudo e mais um pouco", e aí complica mesmo. 😆
Resumindo: pequenos passos, grandes impactos no longo prazo. Não precisa dobrar o tamanho da tarefa, só dar aquela ajeitada onde der sem complicar. 🚀
O que acha? Curtiu essa abordagem? 😃