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

12

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?

Nattfrosten
fonte
Eu costumo ir com a segunda opção. Mas se eu fiz muita refatoração, fiz dois commits separados. 1 para minha tarefa específica e outra apenas rotulada como "Refatoração", que eu em rebasevez de merge.
Alternatex

Respostas:

7

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 ...").

sleske
fonte
Para seu primeiro marcador, pequenas correções, confirmar a edição imediatamente parece ser a melhor opção. Eu não tenho idéia do por que não pensei nisso, acho que há maus hábitos. Eu tendem a ficar um pouco na parte de codificação da programação, ao contrário da parte de gerenciamento de código :)
Nattfrosten
@Nattfrosten: Sim, isso é natural e não é ruim - afinal, o foco geralmente deve estar na codificação. O gerenciamento de código é apenas para facilitar a codificação.
sleske
5

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.

Roger escasso
fonte
1
Muito obrigado por esta resposta, até agora eu estive envolvido principalmente em projetos solo, então é daí que veio a minha perspectiva. Terei que mudar muitos hábitos para me encaixar melhor em uma equipe mais tarde, e esse tipo de coisa é exatamente o que eu precisava.
Nattfrosten
A mesma conclusão, mas geralmente são os chefes que decidem usar novos recursos e não refatorar: - |
Mark Hurd