¿Debería corregir defectos preexistentes mientras trabaja en otra cosa?

Enigma: durante el curso de trabajar en una nueva función o corregir un defecto, encuentra un problema heredado en el código. Que deberias hacer Arreglalo y corre el riesgo de alterar el comportamiento del código. Ha estado funcionando hasta ahora por alguna casualidad, o bien el defecto no ha sido detectado o no vale la pena el tiempo de nadie para informar. ¿Debería dejarlo solo y permitir que el problema dificulte el trabajo del código más adelante? La solución del problema solo aumentará el tiempo de su tarea original y lo obligará a realizar una prueba de regresión. Pocos apreciarán el trabajo. Sin embargo, solucionarlo parece correcto de alguna manera. El código con menos problemas es más fácil de refactorizar y desarrollar.

Me he encontrado en esta situación una y otra vez mientras trabajamos para modernizar una aplicación web. No puedo decir si estoy siendo obsesivo u honorable cuando salgo de la tangente trabajando en estos viejos errores. ¿Cómo manejas estas situaciones?

Gracias Corey

Trabajo en un equipo muy pequeño, por lo que depende de cuál sea el cambio:

Si se trata de una pequeña y obvia corrección de errores, definitivamente voy por ella. También incluyo comentarios adicionales si tengo que trabajar con el código de otra persona y otras pequeñas mejoras que me corresponden a la "regla de boycout".

Si el código está tan entrelazado que tiene que preguntar "Cambiar esto romperá algo y requerirá pruebas", entonces no, no debe cambiarlo. Créelo en su sistema de seguimiento de errores si le preocupa.

Por cierto, esta es la razón por la que trato de codificar métodos más pequeños con firmas de tipo más obvias también. Si sabe que no hay efectos secundarios y puede hacer que las entradas y salidas coincidan, puede arreglar, reorganizar o ajustar cualquiera de los códigos interiores sin riesgo.

Pero no sienta que la falta de apreciación es una razón para no corregir los errores que encuentre o para mejorar la base del código por cualquier motivo. Por lo menos, estás siendo amable con el futuro, que seguramente volverás allí para arreglar algo más.

EDITAR: También debe vigilar su tiempo en el proyecto. Obviamente, dentro de plazos ajustados, debe concentrarse en realizar el trabajo principal, pero si está bajo una "carga normal", entonces creo que un poco de limpieza aquí y allá hace a todos más felices a largo plazo.

Como siempre, depende.

• Si es trivial y estás seguro de que puedes arreglarlo, arréglalo.
• Si hay muchas pruebas unitarias, por lo que puedes estar bastante seguro de que no has roto nada, arréglalo.
• De lo contrario, agregue un // TODO, agréguelo a su seguimiento de errores, lo que sea

Básicamente está haciendo una evaluación de riesgos: ¿cuál es el riesgo de cambiar frente a no cambiar? Si no siente que tiene suficiente experiencia (con la programación en general, o el sistema en particular), pregunte a alguien más en el equipo.

El programador pragmático llama a estas 'ventanas rotas'.

Si no arregla ventanas rotas, entonces existe la tendencia de que creen una espiral descendente de calidad de código. Y cuanto más hay, mayor es el trabajo de arreglarlos y, por lo tanto, es menos probable que se solucionen.

Si solucionarlos ahora o más tarde depende de una cuestión de juicio. ¿Es una solución simple? ¿Estás seguro de que el código está haciendo lo que crees que es? ¿Es probable que te distraiga de tu tarea actual? ¿Estás bajo limitaciones de tiempo? ¿Es probable que introduzca más errores?

Como mínimo, marque el elemento en su sistema de seguimiento y asegúrese de que se arregle más tarde. Es importante marcarlo en el sistema de seguimiento, incluso si decide arreglarlo ahora, para asegurarse de que también se pruebe y para documentar los cambios.

Si se trata de un error obvio, como algo que violará la seguridad, dañará los datos o generará una excepción que se mostrará al usuario, luego corríjalo. De lo contrario, pregúntale a alguien que conozca la base de código mejor que tú.

Depende, si es un pequeño error en el que está seguro de que su solución tiene un bajo impacto, personalmente lo arreglaría como parte del otro trabajo y luego se lo haría saber al PM.

Si tiene algún riesgo para el cliente, los usuarios o la empresa, comuníquelo con el Gerente de Proyecto y discuta un curso a seguir. Es su trabajo evaluar el riesgo, así que llévelo a su atención y el caso para solucionarlo. Entonces honra su decisión.

Nuestros probadores odian esto. A menos que sea muy trivial, lo registramos en la base de datos de errores, luego lo asignamos a una versión y escribimos pruebas de regresión. Si los desarrolladores solo van a hacer cambios que no están en el cronograma, ¿cómo pueden mantener una fecha límite?

He estado en equipos donde los defectos no críticos o las violaciones estándar se envían como un defecto de "Código débil". Diría que la persona que encuentra un defecto crítico tiene la responsabilidad de arrojar algún tipo de bandera

Depende del error. La principal preocupación es la introducción de nuevos errores. Es mejor tratar un problema conocido que uno desconocido. Si es simple, digamos un cambio de texto o un simple error lógico, lo arreglamos, de lo contrario, déjelo en paz.

Una cosa a tener en cuenta, aunque, somos una pequeña tienda de 4 desarrolladores y un interno y el error que soluciono es probablemente el error que he creado.

Si el código es obviamente incorrecto, la solución es bastante sencilla y cree que el riesgo de afectar a los usuarios es bajo, entonces hágalo. Todo se reduce al juicio profesional.

Sin embargo, debe recordar que si lo ha encontrado, presumiblemente los usuarios no lo hayan hecho, o de lo contrario lo habrían informado. En lugar de perder tiempo solucionando un problema que un usuario nunca podría encontrar, es mejor que gaste ese tiempo solucionando problemas que están causando problemas a sus usuarios ahora.

Documente bien las observaciones primero y decida si solucionarlo más tarde.

Tenga una discusión formal (p. Ej., En la reunión regular) o informal (p. Ej., Durante el almuerzo) con sus colegas, y realice los cambios después de ganar más confianza en el comportamiento de los códigos que va a corregir.

Aunque le parezca un error / defecto, esta vez puede ser una "característica". Podría ser una solución mal implementada para solucionar algunos casos de esquina en el último minuto de la versión anterior, y su "solución limpia" puede revivir algunos problemas resueltos previamente.

Romperé la tendencia aquí. A menos que se encuentre en la fase inicial de desarrollo del prototipo, nunca debe solucionarlo de inmediato, debe presentar un informe de error. Esto tiene varias ventajas:

• el equipo llega a evaluarlo. ¿Es un error real, cuáles son los riesgos de solucionarlo?
• la administración decide si es lo suficientemente importante como para tener el impacto del cronograma de incluirlo en esta versión
• Se puede agregar un método para detectarlo al conjunto de pruebas, con suerte de una manera lo suficientemente general como para encontrar errores similares.
• proporciona métricas valiosas sobre cuántos errores se están deslizando a través de las fases anteriores