Métodos de depuración de código (situación de pesadilla)


16

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:

  1. 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).

  2. Prácticamente no hay registro realizado en nuestras aplicaciones. No hay pruebas unitarias.

  3. 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).

  4. 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).

  5. 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.

  6. Esta es una solución .net VB

  7. No puede instalar ningún software en los sitios del cliente, pero puede

  8. 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.

  9. 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?


43
¿Tienes un currículum vitae?
Robert Harvey

55
+1 para "Quiero dispararme también". Fuente segura 2005, ouch. Bueno, al menos deberías "concentrarte" en la maravillosa lección de historia: ¡básicamente eres un viajero del tiempo! Aprenderá las lecciones de una década de conocimiento cuidadosamente desarrollado de "así que es por eso que ya no hacemos eso". Buena suerte, saltamontes.
BrianH

77
Dado el requisito n. ° 1, la única forma de ser eficaz en la depuración de este desastre es ser clarividente. En serio, no hay una bala mágica que pueda hacer que esto sea más que una trampa. De alguna manera, esto debería quitarle algo de presión, ya que la depuración es necesariamente una cuestión de suerte. ¿O su gerencia le ordenará que tenga suerte? Claramente, esto no es sostenible, por lo que debería buscar otras oportunidades.
Charles E. Grant

14
Aquí hay algunos consejos profesionales reales: pase demasiado tiempo en una casa que tenga prácticas de ingeniería de software horribles y es probable que la administración lo culpe por ser un mal desarrollador por los problemas que inevitablemente se producen. He estado allí, y estoy seguro de que otros también. En el mejor de los casos, conduce a malos hábitos de desarrollo.
Gort the Robot

2
cómo manejo estas situaciones: si no me pagan muy por encima del mercado, busco algo más que hacer.
Kevin Cline

Respuestas:


22

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.


Créame, no quisiera nada más que agregar afirmaciones, protecciones y registros, probablemente también reescribir la capa de datos (estoy escribiendo un validador de configuración para diagnosticar problemas de configuración típicos). Lamentablemente no depende de mí. Puedo hacer una solicitud para que algo se inserte en la fuente segura, pero la respuesta típica es "sus intenciones son buenas, pero esto no es algo en lo que debamos centrarnos". Por desgracia, no soy más que un junior con 1/2 años de experiencia. Escalaré esta montaña por un tiempo.
Igneous01

9
@ Igneous01 Honestamente, trata de encontrar una montaña diferente para escalar. Las condiciones de trabajo en otros lugares pueden no ser perfectas, pero supongo que al menos la mayoría son significativamente mejores de lo que está experimentando. Si sus guardianes rechazan sus mejoras con "esto no es algo en lo que debamos centrarnos", es su decisión tomar y cosecharán los resultados de esa política fallida (ya están perdiendo toneladas de dinero en términos de tiempo de desarrollo perdido) . La pregunta es, ¿quieres quedarte con ellos hasta que lo hagan?
cmaster - reinstalar a monica el

66
Y tenga en cuenta que cuando las malas políticas fallan, todos los involucrados se ven mal, incluso aquellos que no están de acuerdo.
Gort the Robot

1
Sí, comience a registrar y rastrear. También comience a documentar y agregar comentarios. Poco a poco, todo se irá acumulando. Además, usted dice que tiene la suerte de tener algunos de los codificadores originales de la compañía, si no el equipo. Empuje a la gerencia para que acceda a ellos. Si es posible, persuádalos de que preferirían producir algunos documentos antes que ser constantemente abordados con preguntas.
Mawg dice que reinstale a Mónica el

44
@ Igneous01: Corre, no camines. Este lugar está enfermo y te enfermará.
Restablece a Monica - M. Schröder el

8

1) El depurador no se puede usar en el sitio del cliente ...

Eso es perfectamente normal.

... o localmente

Eso sí que es un problema.

2) Prácticamente no hay registro en nuestras aplicaciones.

El registro es la depuración de producción.

No hay pruebas unitarias.

Oh querido. Sin embargo, todo en común.

3) El control de versiones solo tiene 1 versión de la solución completa

Entonces no estás usando el Control de versiones.

4) No se puede reproducir localmente, muchas veces 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).

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).

5) Existe una gran posibilidad de que la versión que utiliza el cliente sea diferente de la que está en la fuente segura.

Una vez más, simplemente no está utilizando el control de versiones para su ventaja.

8) Nuestra aplicación es extremadamente personalizable

Eso es bastante típico.

Las diferencias específicas del sitio se deben gestionar a través del Control de versiones "Ramificación".

9) Prácticamente no hay comentarios en el código.

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.

No hay documentación sobre la arquitectura.

Oh querido.

No hay documentación sobre la API.

Oh querido, oh querido.

Y antes de que lo digas ... sí, lo sé; Quiero pegarme un tiro también.

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.

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.

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!


2
"Siempre codifique como si la persona que termina manteniendo su código sea un psicópata violento que sabe dónde vive"
PerryC

Los errores de tiempo de ejecución se deben más a una falta de comprensión que a una falta de programación defensiva. La programación defensiva es solo una forma de ocultar el hecho de que el código no funciona.
user253751

1
"Sin documentación sobre la arquitectura" generalmente significa "sin arquitectura" ...
gnasher729

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.
sixtyfootersdude

5

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.


4

Primero, todo lo anterior ... lo mismo.

Algunas heurísticas:

  • Utilice el control de fuente en su computadora de desarrollo. Es lo mejor que he hecho. No es un sustituto del control de versiones del proyecto, que tenemos. Es una herramienta que brinda una increíble libertad para experimentar, piratear, trabajar problemas sin miedo de manera simultánea pero independiente, etc. Soy mejor en el uso del control de versiones porque tengo la libertad de ser audaz, fastidiar y aprender.
  • En la medida en que agregue comentarios, priorice los elementos de la interfaz pública para aprovechar intellisense. Haz esto mientras descifras durante tus aventuras de depuración.
  • Sea persistente con refactorizaciones menores. Tarde o temprano, para un trozo de código dado, llegará a una masa crítica que permite grandes refactorizaciones como SECAR código redundante en todas las clases.
  • No mezcle el reformateo de código y los cambios reales en las mismas confirmaciones de control de versión.
  • Principios sólidos
    • Nunca ignore la responsabilidad individual. Bien hecho, este es el camino hacia la promesa de la orientación a objetos; EN MI HUMILDE OPINIÓN.
    • Siempre ignore Abierto / Cerrado.
    • No estamos hablando de nuevo código aquí.
    • Hacer interfaces sin un diseño intencionado dificulta el mantenimiento.
  • Refactorización
  • Algunos archivos de código necesitan un reformateo completo, cambio de nombre variable, etc., incluso antes de intentar la depuración. No tenga miedo de usar el menú refactor de Visual Studio sin pruebas unitarias.
  • La única documentación que no puede extraviarse está en los archivos de código.
  • Cuando obtenga el control de versiones, piense en el plan de VC. Y documentarlo! Y cree una convención de nomenclatura para sucursales, etiquetas que resalten las principales versiones de software e hitos.
  • Use buen equipo
  • Practique la depuración de Ducky de goma
  • A veces lo peor que puede pasar es que no te despidan.

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


+1 para No mezclar el reformateo de código y los cambios reales en las mismas confirmaciones de control de versión. Gran consejo
kiwiron

0

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.


0

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.


Cuando te refieres a descompilar, ¿te refieres a usar algo como IDA Pro para ver el código de la máquina? Probablemente sería el único que lo usaría porque aquí nadie conoce el ensamblaje (y yo sé lo básico).
Igneous01

Bueno, como esto es .NET, los binarios no son código de máquina, están en CIL ( en.wikipedia.org/wiki/Common_Intermediate_Language ). Esto se puede convertir con bastante facilidad y precisión a código C # o VB, especialmente si no se ofuscó. Puede probarlo con ILSpy, por ejemplo ( ilspy.net ), pero probablemente haya otras herramientas que podría usar.
20c
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.