Con frecuencia tengo la tarea de depurar una aplicación en mi trabajo. Es una aplicación de BI que implementamos en las empresas, que incluye un entorno de prueba y un entorno de producción. Me pregunto si hay aplicaciones / herramientas / métodos que la gente pueda sugerir, en base a estas restricciones:
El depurador no se puede usar en el sitio del cliente o localmente, porque el software depende de aplicaciones de terceros personalizadas para las que no tenemos entornos de prueba. (EDITAR: para ser justos, es posible depurar localmente en algunos casos. Si usamos nada más que el código central. Gran parte del código problemático reside en un dll que encapsula la comunicación específica de terceros: enchufes, tuberías de proceso, llamadas de jabón, lógica personalizada que cambia el comportamiento del código central. Normalmente, durante una implementación o mejora para un cliente, estaríamos escribiendo código nuevo en esta área).
Prácticamente no hay registro realizado en nuestras aplicaciones. No hay pruebas unitarias.
El control de versiones solo tiene 1 versión de la solución completa (usando source safe 2005). Por lo tanto, no es posible obtener una versión anterior de la solución completa, solo archivos individuales. (A menos que alguien sepa cómo solucionar esto).
No se puede reproducir localmente, a menudo no se puede reproducir en el entorno de prueba (alta probabilidad de que la prueba y la producción no sean la misma versión).
Existe una gran posibilidad de que la versión que utiliza el cliente sea diferente de la que está en la fuente segura. Esto se debe a que se actualizan los archivos individuales, que tienen lógica personalizada integrada para ese cliente específico. A menudo, lo que sucede es que se actualiza un archivo binario, lo que requiere cambios en varios otros archivos binarios, pero cuando se realiza una confirmación, nadie tiene ningún registro o conocimiento de esto. Un error algo común que veo es 'Función / Método no encontrado' o 'La llamada al método tiene demasiados / muy pocos parámetros especificados' en un entorno de clientes.
Esta es una solución .net VB
No puede instalar ningún software en los sitios del cliente, pero puede
Nuestra aplicación es extremadamente personalizable, pero desafortunadamente la lógica de personalización se extiende a todas las clases y archivos, desde el front-end hasta la capa de datos, incluidos los cambios personalizados realizados en la base de datos por cliente.
Prácticamente no hay comentarios en el código. No hay documentación sobre la arquitectura. No hay documentación sobre la API. Lo único que tenemos son cientos y cientos de cadenas de correo electrónico que explican un poco lo que está sucediendo. Las únicas personas que conocen el código son las que lo escribieron originalmente, pero ya no son desarrolladores por lo que no se involucran tanto.
Y antes de que lo digas ... sí, lo sé; Quiero pegarme un tiro también. No ayuda que haya un código de espagueti, cientos de advertencias del compilador y un polimorfismo roto que REALMENTE debería repararse, pero no tengo nada que decir.
Los tipos de errores más comunes con los que me encuentro son errores de referencia nula, conversiones no válidas y faltas de coincidencia de funciones / firmas de funciones. A veces tengo suerte y el visor de eventos registrará la clase, el método y el mensaje de excepción. No es lo más útil, pero sigue siendo algo. Lo peor son los errores que no tienen seguimiento, no hay pasos de repro además de una captura de pantalla, y son mensajes de error genéricos como los mencionados anteriormente. A veces no es posible descubrir por qué ocurrieron, solo rezar para que el entorno no esté configurado correctamente y que desaparezca más tarde.
Sé que esto sale como una queja, y hasta cierto punto lo es. Pero estoy desesperado por opciones. ¿Hay otros métodos / herramientas que pueda usar?
Respuestas:
El consejo de Robert Harvey es probablemente el mejor, pero dado que el consejo profesional está fuera de tema, daré qué respuesta se puede dar:
Estás al pie de una montaña muy empinada cubierta de zarzas, barro y cabras de montaña irritables. No hay forma fácil de subir. Si quieres llegar a la cima, tienes que subir un paso tremendamente doloroso a la vez.
Parece que sabes exactamente cómo deberían funcionar las cosas . Si nadie más lo ayudará (nuevamente, ignorando los consejos de carrera), su única opción es comenzar a arreglar estas cosas usted mismo.
Primero, por todo lo que es sagrado, consiga esas cosas en un sistema de control de versiones real . Prácticamente cualquier cosa menos Source Safe, que es conocida como una pila de basura apestosa.
gites gratuito y se puede configurar con bastante facilidad. No puede solucionar problemas de la falta de control de versiones en el pasado, pero al menos evite que el problema continúe en el futuro.A continuación, mire el registro. Encuentra, o en el peor de los casos, escribe un sistema de registro y comienza a usarlo. Utilice uno que también se pueda usar en los sitios del cliente, de modo que cuando las cosas se ponen de lado, tiene al menos algo.
Y comience a escribir pruebas, al menos para los nuevos cambios que realice.
No hay azúcar que lo cubra: no hay una respuesta aquí que no implique mucho trabajo, o tratar esto como una cuestión de carrera.
fuente
Eso es perfectamente normal.
Eso sí que es un problema.
El registro es la depuración de producción.
Oh querido. Sin embargo, todo en común.
Entonces no estás usando el Control de versiones.
Entonces, solo el entorno de cliente desplegado muestra los errores.
En ese caso, necesita un registro de diagnóstico incrustado en el código de la aplicación que (a) atrapa y registra [completamente] los errores [fatales] y (b) se puede "marcar" a pedido para producir diagnósticos adicionales continuos que son útiles en rastreando el problema (s).
Una vez más, simplemente no está utilizando el control de versiones para su ventaja.
Eso es bastante típico.
Las diferencias específicas del sitio se deben gestionar a través del Control de versiones "Ramificación".
De nuevo, eso es muy común, porque los desarrolladores escriben código de "autodocumentación", ¿no?
O, al menos, el código que entienden el día en que lo escriben.
Oh querido.
Oh querido, oh querido.
No; quieres dispararle a las personas que escribieron todo esto, crearon un desorden indocumentado e imposible de mantener y luego pasaron a pastos nuevos, dejando atrás el desastroso desorden.
Las referencias nulas y las conversiones no válidas son errores de tiempo de ejecución; hasta cierto punto, debe esperarlos y el hecho de que los esté recibiendo con frecuencia sugiere una falta de programación defensiva (o un exceso de optimismo) por parte de los autores originales.
Las discrepancias de firma de funciones deberían causar una compilación rota ; ¡esos deberían causar "construcciones rotas" y nunca deberían salir por la puerta!
fuente
The site-specific differences should be managed through Version Control "Branching".- No creo que esta sea la mejor manera de proceder. El uso de archivos de configuración y alternancia de funciones parece ser más común y más fácil de razonar.Comience con el registro. Esto tendrá el mayor impacto. Implemente un marco de registro en la base del código, como Log4Net o similar. Comience a registrar lo que hace el código.
La depuración debería ser posible localmente. De lo contrario, trabaje para obtener los archivos de símbolos (PDB) para que pueda depurar en archivos DLL de terceros para obtener una imagen completa de los problemas que están ocurriendo. Herramientas como WINDBG pueden señalar qué archivos DLL son problemáticos si el sistema falla. Uno puede configurar cualquier servidor para tomar un volcado de memoria cuando hay un bloqueo. Básicamente es una instantánea de lo que estaba sucediendo cuando ocurrió el problema. Uno puede examinar los vertederos localmente para encontrar pistas sobre lo que estaba sucediendo. Si la depuración no es posible, trabaje para hacerlo posible. Documente los pasos necesarios para depurar. En algún momento en sistemas complejos, hay una gran cantidad de configuración necesaria para depurar completamente.
Seguimiento de errores ... Si no está usando uno, comience a usar uno. Esto va de la mano con un sistema de control de versiones adecuado. Básicamente, comience a rastrear defectos y revisiones de su código. Comience a construir un historial del sistema.
Realizar análisis de código estático. Invierte en una herramienta como ReSharper. Señalará rápidamente todas las posibles excepciones de referencia nula y otras prácticas de codificación erróneas. Puede ayudar a que el código esté en mejor forma con solo unos pocos clics y automatizar elementos tediosos como el formato del código, el nombre variable, etc. Mida su código, descubra dónde están los puntos críticos para la refactorización a través de métricas de código.
Refactor y pruebas unitarias. Asumiré que probablemente la mayor parte del código escrito no sea muy verificable, por lo que no me molestaría en tratar de agregarle pruebas. Cualquier código nuevo, cree un proyecto de pruebas y comience a escribir pruebas, tanto de unidad como de integración. Si las pruebas unitarias fallan, falla la construcción. Entonces, a medida que refactoriza, debe haber pruebas. Una cosa con las pruebas es que se puede escribir una prueba para llamar a cualquier método y depurar en ese método sin cargar toda la aplicación o la base de código. Esto es útil para ayudar a solucionar problemas.
Documente cualquier conocimiento tribal según sea necesario. El código debe ser autodocumentado, de modo que los comentarios sean escasos, pero muchos sistemas tienen formas "inusuales" de hacer las cosas, indíquelas en un WIKI de codificación u otro tipo de repositorio informal. Además, considere elaborar estándares y prácticas de codificación. Aplique esos estándares a través de un conjunto de herramientas como Resharper. Dado que la mayoría del código probablemente no sigue ningún estándar y pautas, implemente los estándares en el nuevo código que está escrito.
Como eres nuevo, trataría esto como un viaje de servicio. 6 meses a 2 años, y luego elija quedarse o seguir adelante. Disfrute de hacer las cosas un poco mejor que el día anterior.
fuente
Primero, todo lo anterior ... lo mismo.
Algunas heurísticas:
Editar
Desarrollo de aplicaciones Brownfield en .NET
Prueba este libro. Una lectura inicial de principio a fin es probablemente la mejor. Este libro le ayudará a pensar sobre el panorama general, las posibilidades y el desarrollo de planes de ataque estratégicos y tácticos.
Sobresaliendo
Quédese, digamos, 1.5 años si puede; el tiempo suficiente para saber si estás haciendo un progreso experiencial. Sabrá si obtiene 2 años de experiencia o 6 meses de experiencia 4 veces.
Siendo "junior con 1/2 años de experiencia", me preocupa que un posible empleador lo vea como rescatar temprano porque no puede piratearlo. Una cosa es decir que aprendiste z, y, x, tomaste algunos nombres y pateaste traseros, pero no se te permitió contribuir a tus capacidades; y otro simplemente arriesgándose a ignorar el trabajo, el código, la administración, etc. a modo de explicación.
Puede que esté fuera de lugar en esto, pero mi "mejor y peor momento" fue mi primer trabajo, que resultó ser un código literalmente imposible de mantener. Tuve un gran supervisor (todos los demás eran del programa de mejoramiento de la gerencia) que me dio el espacio para volver a escribir algunos programas clave. Esa experiencia fue revelación.
fin Editar
fuente
Yo diría que (5) es el que necesita arreglar primero. Si no sabe qué código se está ejecutando en producción, no tiene una forma segura de reproducir y solucionar problemas. Esto hace que cualquier otro cambio que introduzca sea peligroso, ya que puede causar problemas que no puede prever ni reproducir.
Es posible que necesite hacer un trabajo de detective y quizás ingeniería inversa para descubrir qué versión (es) de código y qué bibliotecas se implementan. (Y necesita tener un sistema de construcción e implementación consistente para alinear todo el código implementado con el control de origen en el futuro).
Es posible que tenga que crear múltiples entornos de prueba para replicar las diversas implementaciones. (Por supuesto, la solución más simple es crear una nueva compilación limpia e implementarla de manera consistente en todas partes, pero ¿parece que esto no es posible?)
Solo cuando conozca las versiones exactas implementadas y tenga los entornos de prueba correspondientes, debe comenzar a tratar de corregir / mejorar el código.
Su próxima prioridad debería ser consolidar en una única base de código que se pueda implementar en todas partes. ¿Parece que tiene varias versiones de código implementadas debido a la personalización? Debe consolidar a una única versión y luego usar interruptores de configuración para la lógica personalizada.
Después de esto, puede comenzar a mejorar cuidadosamente la base del código para permitir una depuración más fácil. Agregar el registro es probablemente la mejora menos riesgosa.
Querrá agregar pruebas automatizadas, pero las pruebas unitarias a menudo son difíciles de agregar a un proyecto que inicialmente no está diseñado para pruebas. En cambio, recomiendo comenzar con pruebas de integración automatizadas de extremo a extremo. Estos son más difíciles de configurar, pero no requieren que rediseñe la solución, por lo que son menos riesgosos.
fuente
Ignorando los problemas que tiene en su equipo, parece que el primero en abordar es depurar el código que coincide con lo que está en producción. De lo contrario, podría estar persiguiendo un error que ya se corrigió en el código que tiene en su "Control de fuente". Como se trata de .NET, puede "descompilar" fácilmente los archivos binarios de producción para comparar el código con lo que tiene. No es una tarea fácil, pero si tiene éxito, este es un argumento sólido para una mejor herramienta de control de código fuente que puede etiquetar las versiones lanzadas.
fuente