Si el error tiene más de 5 años, ¿es una característica? [cerrado]

Permítame agregar detalles: trabajo en un lugar institucional con muchos programadores, evaluadores, analistas de control de calidad, propietarios de productos, etc. y aquí hay algo que me molesta:

Hemos podido vender software de mala calidad (aunque bastante funcional) durante más de una década. Tiene muchas características y el producto es competitivo, pero hay algunos errores graves, así como miles de "recortes de papel", pequeñas molestias a las que los clientes deben acostumbrarse.

Me duele mirar algunas de las cosas porque creo firmemente que si las computadoras no ayudan a hacernos la vida más fácil, entonces no debemos usarlas. Tengo confianza en mis colegas: son inteligentes, capaces y pueden mejorar las cosas cuando la atención se centra en hacerlo.

Pero, puede ser difícil archivar errores contra alguna funcionalidad antigua sin verlos cerrados u olvidados. "Funcionó así por eones" es una respuesta típica. Además, cuando el control de calidad hace una regresión, tienden a buscar cualquier cosa que sea diferente a cualquier cosa que no parezca correcta. Por lo tanto, una solución a un viejo problema puede escribirse como un error, porque "ha sido así incluso antes de mi tiempo".

El joven codificador en mí piensa: ¡reescribe esta maldita cosa! Como alguien que tuvo la oportunidad de estar cerca de las ventas, clientes, quiero dar un beneficio de una duda a este enfoque.

Estoy interesado en su opinión / experiencia también. Intente tener en cuenta el riesgo, el costo-beneficio y otros factores no técnicos.

Siento tu dolor.

Pero arreglar algo solo porque es un error no es una razón suficientemente buena.

Debe asegurarse de que su solución no rompa ningún otro código (no solo el suyo, sino el código de su cliente que usa su código). Si saca una solución y esto rompe el sistema de todos los clientes, tendrá algunos clientes muy descontentos.

Hay muchos ejemplos famosos donde se escribió un nuevo código para reemplazar un sistema antiguo. Donde tuvieron que agregar explícitamente la funcionalidad de un error en el sistema anterior porque los usuarios dependían de ese error (no voy a nombrar nombres, pero estoy seguro de que puedes buscarlo en Google).

Las pruebas de regresión son básicamente una prueba de lo que sus clientes esperan que suceda. Antes de eliminar una prueba de regresión, asegúrese de que no le hará daño a nadie (esto es casi imposible). Si puede corregir un error Y esto no interrumpe las pruebas de regresión, entonces es una solución real.

Algunas cosas a tener en cuenta al decidir corregir un error ... de ninguna manera todo incluido.

• ¿Es crítico (el sistema se bloquea)? ... claramente estos se arreglan
• ¿Los clientes a menudo se quejan de ello? Esto podría ser un error ya que algo está roto en el código o podría ser un error de requisitos, ya que la función no es fácil de usar o esperan que funcione de manera diferente.
• Desde el punto de vista empresarial, ¿es más beneficioso corregir el error o implementar una nueva característica?
• ¿El error requiere cambios arquitectónicos significativos o está en una parte del sistema en la que otros subsistemas confían mucho? ¿Esto podría afectar drásticamente el tiempo de prueba y complicar la cobertura de prueba necesaria para validar el error? Si es realmente viejo, a veces es difícil entender exactamente qué más se verá afectado en el sistema modificando la sección de código con errores.
• ¿Está perdiendo clientes potenciales debido a un sistema defectuoso?

Definir error. "La especificación dice que está ordenada por fecha, pero está ordenada por monto de transacción" no es necesariamente un error en el código. Puede ser un cambio indocumentado: en algún momento, en algún lugar, alguien pidió que se cambiara el orden de clasificación, pero las especificaciones, los requisitos, el manual (incluso los botones y las etiquetas en la interfaz de usuario) no se cambiaron para que coincidan, y a nadie le importa. Para que aparezca y vuelva a cambiarlo a "por fecha", causará caos, y para que actualice la interfaz de usuario, las especificaciones, el manual, etc. básicamente está desperdiciando su tiempo, con la posible excepción de un poco de "teoría de ventanas rotas" ".

Algunas cosas son obviamente errores. Si hace clic en este botón, explota. O, si hace clic en este botón los lunes, explota. A menos que alguien le haya encomendado invertir tiempo entendiendo por qué, podría dedicar mucho esfuerzo a investigar. Y una vez que descubras por qué, bien podría ser que no puedas cambiarlo, porque eso arruinaría algo que es más importante para los usuarios o para la administración.

Si ve "descuido" (pérdidas de memoria, código que claramente necesita algunas convenciones de optimización, sangría y nomenclatura que no coinciden con las suyas) es muy tentador arreglarlas un día cuando no tiene nada más que hacer, o en su propio tiempo . Sin embargo, estas "correcciones" desordenan el historial en el control de origen por poco o ningún beneficio, riesgos de desastres como "nunca compilamos ese módulo porque el binario que estamos usando en la producción se creó a partir del código que se ha perdido, y simplemente lo sobrescribió". ", y puede molestar seriamente a las personas cuyos" errores "estás" arreglando ".

Recomiendo uno a uno con su jefe. Explique lo que le molesta: ¿es el estilo de codificación, cosas que está seguro que deben molestar a los usuarios, números inexactos, inconsistencias o desastres que esperan que suceda? Luego pida dirección y (esta es la clave) tómala.

Si desea corregir un error que era antiguo, tendrá que tener cuidado de no romper ninguna funcionalidad existente. Si hay pruebas unitarias, esto es más fácil, pero dada la antigüedad implícita de la empresa y el software, no existen. Recomendaría leer el libro Refactorización de Martin Fowler porque trata sobre cómo refactorizar y corregir errores de manera adecuada mientras se intenta minimizar los efectos secundarios. También recomendaría asegurarse de que la empresa esté bien con usted para solucionar errores antiguos durante el tiempo regular. Es posible que solo te permitan hacer esto si lo haces en horas extras fuera del reloj.

Además, si un error se ha convertido en una característica, es decir, en realidad lo usan los clientes porque proporciona algo, asegúrese de proporcionar un reemplazo adecuado para cuando desean ese comportamiento (o simplemente documentarlo como una característica en lugar de un error).