Fluxo de trabalho, editando itens que não estão na sua tarefa atual

Normalmente, quando programa, tenho uma tarefa clara pela frente, mas encontro coisas irritantes que gostaria de limpar enquanto continuo.

Aqui eu vejo três opções:

• Faça isso mais tarde (pode esquecer / precisar gastar tempo adicionando um ticket)
• Faça agora e comprometa-o juntamente com o meu trabalho atual (claro)
• Faça agora e confirme-o separadamente (tem que encontrá-lo, pode cometer um erro e optar pela opção 2 sem querer)

Provavelmente isso é bastante básico, mas quais são algumas maneiras de contornar isso usando svn / git / other?

Pessoalmente, acho que depende :-).

• Para pequenas correções , a opção três (agora, em um commit separado) é melhor, porque a sobrecarga de fazer isso posteriormente não vale a pena. Nesse caso, você apenas cria um commit separado. Como fazer isso depende do VCS que você usa e é uma pergunta separada :-).

• Se for uma correção maior , você cria um ticket. Caso contrário, você corre o risco de ficar constantemente impedido de realizar sua tarefa principal ("Oh, veja, outra oportunidade de refatoração, oh, há outra, e ali, e ali ...").

Considere isto. Quando você "acha coisas irritantes (...) para limpar" e toma uma decisão executiva, está cortando o restante de sua equipe de uma discussão e decisão sobre prioridades. Você está deixando seu agenda superar os outros por causa de seu relacionamento privilegiado com o código. Eu não acho isso legal. Por experiência, também leva a ressentimentos de equipe / acionistas.

Em vez disso, crie um problema / tarefa para a limpeza / refatoração. Enquanto estiver fresco em sua mente, liste os motivos importantes: estimativas de maior estabilidade, facilidade de manutenção, esse tipo de coisa. Talvez inclua uma estimativa do esforço, dependendo de como sua equipe trabalha. Em sua próxima reunião de seleção / atribuição / prioridades, apresente sua tarefa de refatoração e posicione-a em relação a outras tarefas. Como equipe, decida quando deve ser concluída.

Por favor, não pense que estou lhe dizendo para despertar o bom senso em nome dos princípios. Use sua cabeça. Se houver algo feio na função que você está editando, não é uma nova tarefa de refatoração. Corrija e verifique tudo. Se renomear a propriedade com a qual você está trabalhando para algo mais sensato afetar alguns arquivos de origem extras, não é uma nova tarefa de refatoração. Corrija e verifique tudo. Se, por outro lado, você não gostar da maneira como outro desenvolvedor (Mitch, eu odeio esse cara) fez algo em uma função que você não está editando e a função parece estar funcionando bem, deixe em paz por enquanto. Crie uma tarefa de refatoração e apresente seu caso à sua equipe.

Se a refatoração for sempre rebaixada por sua equipe em favor de novos recursos, comece a procurar outro emprego. É mais fácil encontrar um emprego quando você já tem um.