Seguimiento de refactorizaciones en una base de datos de errores

Question

Digamos que trabaja en un lugar donde cada cambio en el código fuente debe asociarse con un informe de error o solicitud de función, y no hay forma de que se modifique esa política. En dicho entorno, ¿cuál es la mejor manera de tratar con refactorizaciones de código (es decir, cambios que mejoran el código pero no corrigen un error ni agregan una característica)?

• Redacte un informe de error y asocie la refactorización con él.
• Escriba una solicitud de función y asocie la refactorización con ella.
• Acceda a las refactorizaciones mientras trabaja en el código que está asociado con un informe de error/solicitud de función.
• Simplemente no haga ninguna refactorización.
• Otros

Tenga en cuenta que todos los informes de errores y descripciones de las características serán visibles para los administradores y clientes.

Answer 1

Voto por el enfoque "furtivo en refactorizaciones", que es, creo, la manera en que la refacturación debe hacerse en primer lugar. Probablemente sea una mala idea refactorizar solo por "limpiar el código". Esto significa que estás haciendo cambios sin una razón real. Refactorizar es, por definición, modificar el sin la intención de corregir errores o agregar características. Si sigues el principio de KISS, cualquier característica nueva necesitará al menos alguna refactorización porque no estás realmente pensando en cómo hacer que el sistema más extensible sea posible la primera vez.

Answer 2

La forma en que trabajamos es: debe haber una buena razón para refactorizar el código; de lo contrario, ¿por qué?

Si el motivo es permitir que otra característica use el mismo código, asocie los cambios con la solicitud de la otra característica.

Si se trata de hacer algo más rápido, cree una solicitud de función para un "xyz" más rápido y asocie los cambios con eso, entonces los clientes verán que está mejorando el producto.

Si es para diseñar un error, registre el error.

Vale la pena señalar que en mi entorno, la política no se puede aplicar. Pero los gerentes inteligentes pueden recibir informes de cambios y si no tienen una referencia de solicitud de error en el texto de compromiso, se realiza un seguimiento.

Answer 3

Vamos a echar un vistazo a cada opción:

• Escribir un bug-informe y asociar la refactorización con él.

Si considera que, en su opinión, el código original representa un riesgo de seguridad o potencial de bloqueo o inestabilidad. Escribe un pequeño informe de error que describa el peligro y luego soluciónalo.

• Escriba una solicitud de función y asocie la refactorización con ella.

Podría ser más difícil para el código del reactor en función de una solicitud de función. Pero podría usar una solicitud de función válida para hacer esto que me lleve al próximo punto ...

• Acceda a las refactorizaciones mientras trabaja en el código que está asociado con un error-informe/función-solicitud.

Si hay un error o una característica válida, indique que la función x tuvo que modificarse ligeramente para corregir el error o agregar la característica.

• Simplemente no haga ninguna refactorización.

Esto parece sugerir que el autodesarrollo mediante la mejora de una aplicación no está permitido. Los desarrolladores deben estar autorizados, si no, fomentar las nuevas técnicas y tecnologías del explorador.

• Otros

Tal vez podría hablar de su mejora en la reunión correspondiente, dando razones convincentes para que se deben hacer los cambios. Entonces, al menos, tendrá respaldo de la administración para el cambio sin tener que colar el código a través de otro método.

Answer 4

Si está trabajando en un bloque de código, en la mayoría de los casos es porque hay una corrección de error o una nueva función que requiere que ese bloque de código cambie, y la refactorización es anterior al cambio para poder hacer es más fácil, o después del cambio para ordenar el resultado. En cualquier caso, puede asociar la refactorización con esa corrección o función de error.

Answer 5

• Otros

Si usted trabaja en un lugar con ese tipo de política inflexible (y ridícula), la mejor solución es encontrar otro trabajo!