Miles de errores!

Me asignaron a un nuevo proyecto recientemente. Bueno, un proyecto antiguo en realidad, escrito en ASP clásico. Ahora se está escribiendo una nueva versión de la aplicación en la última ASP.NET, pero no se espera que sea RTM en un tiempo (la fecha estimada de lanzamiento es enero de 2017), por lo que tengo que realizar un mantenimiento en la aplicación anterior hasta que pueda ser descartado.
Además, tengo la sensación de que no todos los clientes cambiarán al nuevo programa de inmediato, por lo que esta versión probablemente estará disponible por un tiempo.

Y el problema es que está lleno de errores. Algunas partes se remontan al siglo anterior, cuando no había estándares web, y realmente no me importa el modo Quirks widthy los heightatributos en lugar de CSS, tablas utilizadas para el diseño, conjuntos de marcos, etc., pero ¡oh, todos esos errores! width="20px"por todo el lugar, onchange="javascript:..."y en aquellos lugares donde usan CSS, style="width:20"y style="width=20px"son comunes. Sin mencionar muchas líneas donde hay contradictorios widthy styleatributos. Etc etc.
Como resultado, la aplicación web solo se ejecuta bajo IE, y solo en modo de compatibilidad. Está claro que los desarrolladores nunca miraron la validez del código, solo si lo que salió parecía ser lo que tenían en mente que debería ser.

Y no sé cómo manejar eso. Me resulta imposible cerrar los ojos ante esos errores mientras busco otros errores en el código.
Por supuesto, puedo hacer una búsqueda y reemplazo global para eliminar la mayoría de los problemas, pero eso significaría que mi primera confirmación consistiría en miles de archivos .asp modificados. ¿Puedo hacer eso?

Parece que estás confundiendo varias cosas en el término "errores"

• atributos html heredados
• estilo de codificación
• errores de codificación que no causan errores
• errores no reportados
• errores que ahora son características
• errores reportados
• errores reportados que le han asignado para corregir

En una aplicación heredada que será reemplazada, solo uno de estos tipos de error debería preocuparte. El último.

Me atrevería a decir que ni siquiera debería refactorizar otras cosas en una función que está solucionando errores, principalmente debido a:

• errores que ahora son características

Puede ver en el código cómo tal vez estaba destinado a funcionar, pero nunca lo hizo, pero todos los usuarios se han llevado bien con el elemento indefinidamente oculto durante los últimos 10 años y no le agradecerán por solucionarlo.

En el lado positivo, si pone su cínico JFDI de frente, podrá grabar aunque los errores sean súper rápidos y el equipo de la nueva versión no podrá mantenerse al día con las características de las versiones anteriores.

Esto le dará una sonrisa irónica y regocijada de alegría irónica, ya que recomienda un plugin de cromo ie6 emulator a los clientes para que puedan seguir usando la 'característica' de marquesina que aman

Lo que preguntas no es una pregunta técnica, y nadie aquí puede responderla.

Está trabajando en una pieza de software en modo de mantenimiento y observa tecnología pasada de moda y una gran cantidad de imperfecciones e inconsistencias. Tú preguntas qué hacer. ¿Debería, por ejemplo, extender el esfuerzo para que sea compatible con varios navegadores? ¿Debería alinearlo con los estándares modernos? ¿Debería corregir las inconsistencias sintácticas en la aplicación? La cuestión es que estas son decisiones comerciales . Debe preguntarle a su gerente o propietario del producto qué problemas quieren que resuelva y cuáles son sus prioridades. Como ya hay un proyecto en marcha para reescribir la aplicación, lo más probable es que la administración ya esté al tanto de los problemas que observa.

Si la aplicación se reemplaza por completo en cuestión de meses, es probable que solo quieran que solucione problemas críticos específicos y que deje el resto del desastre solo. Pero no lo sabemos.

Pregunta si puede realizar operaciones de búsqueda y reemplazo de barrido a través de la base de código, cambiando miles de archivos. Por supuesto que puede. La pregunta es si deberías . Esos cambios radicales probablemente requerirán pruebas exhaustivas para garantizar que nada se rompa. Una vez más, es una decisión comercial si el beneficio supera el costo en tiempo y riesgo.

Cuando la solicitud se reemplace en 18 a 24 semanas (agregando los retrasos esperados a las 6 a 8 semanas estimadas presentadas anteriormente), realmente debe preguntarse qué valor agrega al negocio al seguir invirtiendo una cantidad considerable de trabajo en La versión anterior.

Claro, cuando estaría atascado con el soporte de la aplicación durante varios años, entonces deshacerse de la deuda técnica puede valer la pena a largo plazo. Pero cuando todo va a ser abandonado de todos modos, ¿por qué molestarse? Simplemente agregue otra solución pirata además de todas las otras soluciones piratas para reparar cualquier problema, simplemente no puede esperar hasta el lanzamiento de la nueva versión y llamarlo un día.

También puede preguntarse qué puede hacer para la aplicación en la poca vida útil que aún le queda. Cuando esté realmente aburrido en este momento y simplemente no tenga nada mejor que hacer con su tiempo, podría darle una gran revisión y eliminar todos los problemas de estilo que mencionó, pero es muy probable que esto al principio rompa más cosas de las que solucionará. . Es posible que pueda deshacerse de estos nuevos problemas con el tiempo suficiente, pero no tiene ese tiempo.

Razones para NO realizar grandes cambios:

Uno: el código desaparecerá en unos meses. ¿Realmente valdría la pena el tiempo de la compañía para que pases 5 meses arreglando un sistema que luego será desechado 1 mes después? Advertencia: los sistemas rara vez desaparecen cuando están programados para desaparecer. El sistema de reemplazo casi siempre llega tarde, hay usuarios que no pueden actualizarse por cualquier razón, etc. Pero este es un problema complejo.

Dos: si realiza muchos cambios, especialmente la búsqueda masiva y los reemplazos, introducirá errores. No podrías introducir errores: lo harás. Supongamos que hizo un S&R y cambió "ancho = 200" a "ancho: 200 px". ¿Hay código C # o VB en sus páginas ASP? Porque si tenía una variable llamada "ancho" que estaba configurando en 200, simplemente la rompió. (O, para el caso, ¿pensaste en limitar el S&R a las páginas ASP?) O si cambiaste "ancho: 200" a "ancho: 200 px", ¿qué sucede si había un lugar en el código que decía "ancho: 200 mm? "? Ahora dice "ancho: 200pxmm". Bien, supongamos que piensas en eso. ¿Qué pasa si hay un lugar que tenía la especificación de ancho no válido, que por supuesto se ignora, y ahora se presenta bastante bien? Tu arreglas" el ancho y ahora se presenta con 200 px ... y la pantalla está arruinada, porque 200 px es, de hecho, el ancho incorrecto para dar y solo funcionó porque ese valor fue ignorado. Los Mass S&R son muy peligrosos, porque casi seguro que no estás estudiando cada lugar que cambias. Es probable que ni siquiera estés seguro de qué probar.

Tres: el código que es "obviamente" incorrecto puede ser lo que el usuario quiere. He visto muchas especificaciones de requisitos que requieren un comportamiento que obviamente es incorrecto y loco ... y luego vuelvo a los usuarios y les pregunto qué es lo que REALMENTE quieren, y resulta que realmente quieren este comportamiento loco, porque eso es cómo funciona su negocio o las regulaciones gubernamentales lo requieren o lo que sea.

Incluso si el comportamiento es realmente incorrecto, tal vez los usuarios hayan llegado a esperarlo y habitualmente lo solucionen, y al solucionarlo, romperá sus soluciones. Ejemplo: trabajo en un sistema en el que tenemos un lugar donde usted especifica desde y hasta las fechas en que una venta está disponible al público. Ambas fechas eran realmente la medianoche que comenzó ese día, así que si dijiste "hasta el 30 de julio", eso significaba que terminaba al final del día 29 de julio, es decir, un minuto antes de las 12:01 a.m.30 de julio, no al final del 30 de julio En un momento arreglé esto, pero solo pude hacerlo porque había menos de media docena de personas con autoridad para usar esa pantalla, y simplemente podía decirles a todos que lo había arreglado. Si había cientos de usuarios, y todos ya habían descubierto que realmente tenía que dar el día después de la fecha de finalización, entonces mi "reparación"

Por supuesto, puedo hacer una búsqueda y reemplazo global para eliminar la mayoría de los problemas, pero eso significaría que mi primera confirmación consistiría en miles de archivos .asp modificados. ¿Puedo hacer eso?

No veo por qué no. Un commit debería ser conceptualmente una cosa, pero no veo ninguna razón por la cual un hallazgo global y un reemplazo de style="width=20"a style="width: 20px"no cuente como "una cosa", conceptualmente hablando. Y si eso te ayudara a dormir mejor, evitar que te distraigas mientras arreglas otras cosas y no arruines nada , ¿ por qué no?

Su problema es establecer prioridades : ¿cuáles de los problemas son showtoppers (en producción)? ¿Cuáles son las bombas de tiempo? ¿Y qué se puede dejar en un tiempo más (porque funciona y lo ha hecho durante años, incluso más o menos)?

Lo que haría en su situación sería hacer listas de clases problemáticas que me gustaría ver. Por ejemplo, reemplazar style="width=(\d+)"con style="width: \1px"(que probablemente se puede rectificar con una búsqueda / reemplazo global usando regexp - perdón si el mío no es 100%) sería una clase, y si solo hay una ocurrencia, que así sea. Para cada categoría, enumere una prioridad (qué tan urgente es hacer esto) y una estimación del trabajo (cuánto tiempo llevará hacer esta categoría).

Sus tareas de mantenimiento también figurarán en esta lista. Ahora está comenzando a aplicar algo de administración, aunque solo sea para usted, y tiene una herramienta que usar cuando tiene tiempo libre y nada que hacer, o cuando necesita negociar con su gerente sobre el trabajo que debe hacer (o solicitar tiempo para ser asignado a algo de lo que podría no estar al tanto). (Este tipo de proactividad podría ayudarlo a ser notado para las promociones, si se hace correctamente).

Supongo que disfrutas la programación porque tienes una ligera personalidad perfeccionista hasta cierto punto. PERO en un entorno comercial, debes comenzar a darte cuenta de que lo perfecto es enemigo de lo bueno (y lo bueno trae el dinero, lo perfecto no necesariamente trae mucho más por mucho más trabajo). Primero haga lo que se necesita, luego haga lo que sea bueno tener. Sí, esto podría ir en contra de su grano sin fin. Solo sonríe y aguanta, y quizás tengas un pasatiempo para ejercitar tu perfeccionismo y mantenerte cuerdo ;-)