Flujo de trabajo, edición de cosas que no están en su tarea actual

Por lo general, cuando programo, tengo una tarea clara por delante, pero encuentro cosas molestas que me gustaría limpiar a medida que avanzo.

Aquí veo tres opciones:

• Hágalo más tarde (puede haber olvidado / tener que pasar tiempo agregando un boleto)
• Hazlo ahora y compromételo junto con mi trabajo actual (poco claro)
• Hágalo ahora y confírmelo por separado (tiene que encontrarlo, podría cometer un error e ir a la opción # 2 sin querer)

Esto es probablemente bastante básico, pero ¿cuáles son algunas formas de evitar esto usando svn / git / other?

Personalmente, creo que depende :-).

• Para pequeñas correcciones , la opción tres (ahora, en una confirmación separada) es la mejor, porque la sobrecarga de hacerlo más tarde no vale la pena. En ese caso, simplemente crea una confirmación por separado. Cómo hacerlo depende del VCS que use, y es una pregunta separada :-).

• Si es una solución más grande , crea un ticket. De lo contrario, corre el riesgo de que se descarrile constantemente de su tarea principal ("Oh, mira, otra oportunidad para refactorizar, oh, hay otra, y allí, y allí ...").

Considera esto. Cuando "encuentra cosas molestas (...) que limpiar" y toma una decisión ejecutiva para hacerlo, está excluyendo al resto de su equipo de una discusión y decisión de prioridades. Estás dejando que tu agenda triunfe sobre todos los demás debido a tu relación privilegiada con el código. No creo que sea lindo. Por experiencia, también genera resentimientos entre el equipo y los accionistas.

En su lugar, cree un problema / tarea para la limpieza / refactorización. Si bien está fresco en su mente, enumere las razones por las que es importante: estimaciones de mayor estabilidad, facilidad de mantenimiento, ese tipo de cosas. Tal vez incluya una estimación del esfuerzo dependiendo de cómo trabaje su equipo. Luego, en su próxima reunión de selección / asignación / prioridades de tareas, presente su tarea de refactorización y colóquela frente a otras tareas. Como equipo, decida cuándo debe completarse.

Por favor, no creas que te estoy diciendo que deseches el sentido común en nombre de los principios. Usa tu cabeza. Si hay algo feo en la función que está editando, no es una nueva tarea de refactorización. Arregle y verifique todo. Si renombrar la propiedad con la que está trabajando a algo más sensible afecta un par de archivos fuente adicionales, no es una nueva tarea de refactorización. Arregla y revisa todo. Si, por otro lado, no te gusta la forma en que otro desarrollador (Mitch, odio a ese tipo) hizo algo en una función que no estás editando y dicha función parece estar funcionando bien, déjalo solo por ahora. Cree una tarea de refactorización y presente su caso a su equipo.

Si su equipo siempre rechaza la refactorización a favor de las nuevas funciones, comience a buscar otro trabajo. Es más fácil encontrar trabajo cuando ya lo tienes.