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 estar asociado con un informe de error o una solicitud de función, y no hay forma de reformar esa política.En tal entorno, ¿cuál es la mejor manera de lidiar con las refactorizaciones de código (es decir, cambios que mejoran el código pero no corrigen un error ni agregan una característica)?

• Escriba un informe de error y asocie la refactorización con él.
• Escriba una solicitud de función y asocie la refactorización con ella.
• Ingrese furtivamente a las refactorizaciones mientras trabaja en el código asociado con un informe de error/solicitud de función.
• Simplemente no hagas ninguna refactorización.
• Otro

Tenga en cuenta que todos los informes de errores y descripciones de funciones serán visibles para los administradores y clientes.

Answer 1

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

Answer 2

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 característica que requiere que ese bloque de código cambie, y la refactorización es antes del cambio para hacerlo más fácil, o después del cambio para ordenar el resultado.En cualquier caso, puede asociar la refactorización con esa característica o corrección de errores.

Answer 3

La forma en que lo 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, regístrelo.

Vale la pena señalar que en mi entorno la política no se puede hacer cumplir.Pero los administradores inteligentes pueden obtener informes de cambios y, si no tienen una referencia de error/solicitud en el texto de confirmación, se les da seguimiento.

Answer 4

Echemos un vistazo a cada opción:

• Escriba un informe de error y asocie la refactorización con él.

Si cree que, en su opinión, el código original representa un riesgo de seguridad o potencial de falla o inestabilidad.Escriba un pequeño informe de error que describa el peligro y luego corríjalo.

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

Puede ser más difícil reaccionar el código basándose en una solicitud de función.Pero podrías utilizar una solicitud de función válida para hacer esto, lo que me lleva al siguiente punto...

• Ingrese furtivamente a las refactorizaciones mientras trabaja en el código asociado con un informe de error/solicitud de función.

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

• Simplemente no hagas ninguna refactorización.

Esto parece sugerir que no se permite el autodesarrollo mediante la mejora de una aplicación.A los desarrolladores se les debe permitir, si no, alentarlos a explorar nuevas técnicas y tecnologías.

• Otro

Quizás podría discutir su mejora en una reunión relevante y dar razones convincentes de por qué se deben realizar los cambios.Entonces, al menos, la administración respaldará el cambio sin tener que introducir el código a través de otro método.

Answer 5

• Otro

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