El diagnóstico de .NET Legado

https://stackoverflow.com/questions/2680458

30-09-2019
|

Pregunta

Supongamos que usted está tomando más de una aplicación .NET legado. escrito en C #

¿Cuáles son los 5 mejores medidas de diagnóstico, perfilado o de otra manera que usted empleará para evaluar el estado de la aplicación?

No soy sólo mirar a la parte de "qué" de diagnóstico, sino también en el "cómo". Por ejemplo, En efecto, es necesario evaluar rápidos tiempos de respuesta óptimos / de la aplicación. ... pero hay una manera de establecer / medirlo por diagnóstico técnico de la base de código en lugar de sólo conseguir la experiencia del usuario retroalimentación?

??
_{(fuente: gmu.edu )}

Y sí no están obligados a ser algunos impresionante herramientas que se utiliza con el propósito ... sería genial si les lista también.

Solución

1. Percepción de usuario

El muy Lo primero que me gustaría hacer es simplemente encuestar a los usuarios. Recuerde, ellos son los que estamos haciendo esto para. Sin embargo horrible, una aplicación puede mirar en el interior, si los usuarios les encanta (o al menos no me disgusta activamente), entonces usted no desea iniciar inmediatamente rasga aparte.

Yo querría hacer preguntas tales como:

¿Tiene que funcione sin problemas?
¿Es fácil de usar?
Cuando se usa, se siente confianza que está haciendo lo que se puede esperar?
¿Es un BMW, un Civic o un Pinto?

Las respuestas serán subjetiva. Esta bien. En este momento estamos sólo en busca de tendencias generales. Si un número abrumador de los usuarios dicen que se bloquea todo el tiempo, o que tiene miedo de realizar tareas básicas, entonces estás en problemas.

Si las razas de aplicaciones superstición , y se oye cosas como "parece de desplomarse jueves por la mañana" o "No sé lo que hace este botón, pero no funciona a menos haga clic en él primero", correr por las colinas.

2. Documentación

A falta de documentación o documentación que es terriblemente fuera de fecha, es una señal segura de una aplicación enfermo. No hay medios de documentación que el personal de desarrollo esquinas cortadas, o están tan sobrecargados de trabajo con la marcha de la muerte constante que simplemente no puede encontrar el tiempo para este tipo de trabajo "innecesario".

No estoy hablando manuales de usuario - una aplicación bien diseñada, no les debería necesitar - Me refiero a la documentación técnica, cómo la arquitectura miradas, lo que hacen los componentes, dependencias ambientales, la configuración, requisitos / historias de usuario, casos de prueba / planes de prueba, formatos de archivo, se entiende la idea. Un sistema de seguimiento de defectos es también una parte esencial de la documentación.

Los desarrolladores terminan haciendo suposiciones incorrectas) (en ausencia de la documentación apropiada. He hablado con varias personas en la industria que piensan que esto es opcional, pero todos los sistemas que he visto o trabajado en que tenía poca o ninguna documentación terminó siendo plagado de errores y defectos de diseño.

3. Las pruebas

No hay mejor manera de juzgar la salud de una aplicación que por sus propias pruebas, si están disponibles. Las pruebas unitarias, cobertura de código, pruebas de integración, incluso las pruebas manuales, nada funciona aquí. El más completo es el conjunto de pruebas, mayor será la probabilidad de que el sistema esté sano.

pruebas exitosas no Garantía mucho a todos, aparte de que la características específicas de trabajo está probando la forma en que las personas que escribieron las pruebas que esperan. Sin embargo, una gran cantidad de pruebas fallidas, o pruebas que no han sido actualizadas en años, o no hay pruebas en todos - los que son señales de alerta .

No puedo punto a herramientas específicas, ya que cada equipo utiliza diferentes herramientas para la prueba. Trabaja con lo que ya está en producción.

4. Análisis estático

Algunos de ustedes probablemente pensaron inmediatamente "FxCop." Aún no. La primera cosa que me gustaría hacer es romper NDepend .

Sólo un vistazo rápido en el árbol de dependencias de una aplicación le dará enorme cantidades de información acerca de lo bien que está diseñada la aplicación. La mayoría de los anti-patrones de diseño peor - la href="http://en.wikipedia.org/wiki/Big_ball_of_mud" rel="noreferrer"> grande de la bola de barro , Circular dependencias , Código espagueti , Dios Objetos - serán visibles casi inmediatamente de sólo una vista a vuelo de pájaro de las dependencias.

A continuación, me gustaría dirigir una generación completa, encender las "advertencias tratan como errores" ajuste. Haciendo caso omiso de las advertencias específicas a través de las directivas del compilador o banderas está bien la mayor parte del tiempo, pero literalmente haciendo caso omiso de las advertencias hechizosproblema. Una vez más, esto no le garantiza que todo está bien o que todo se rompe, pero se trata de una heurística muy útil para determinar el nivel de atención que entró en el real codificación fase.

Después Estoy satisfecho de que el diseño / arquitectura general no es completa basura, después Me gustaría ver FxCop . No tomo su salida como un evangelio, pero estoy interesado específicamente en Advertencias Diseño y Uso advertencias (advertencias de seguridad son también una señal de alerta, pero muy rara vez).

5. Análisis de tiempo de ejecución

En este punto ya estoy convencido de que la aplicación, a un alto nivel, no es un enorme montículo de chupar. Esta fase podría variar un poco con respecto a la aplicación específica bajo el microscopio, pero algunas cosas buenas que hacer son:

Acceder todas las excepciones de primera oportunidad bajo un funcionamiento normal. Esto ayudará a evaluar la robustez de la aplicación, para ver si hay demasiadas excepciones están siendo tragadas o si excepciones están siendo utilizados como control de flujo. Si ve una gran cantidad de casos Exception de alto nivel o derivados SystemException que aparecen, tener miedo.
Ejecutar a través de un generador de perfiles tales como EQATEC . Esto debería ayudarle a identificar fácilmente cualquier bastante serios problemas de rendimiento. Si la aplicación utiliza un back-end de SQL, utilice una herramienta de perfiles de SQL para ver las consultas. (Realmente no están separados de los pasos para probar la salud de una base de datos, que es una parte crítica de probar una aplicación que se basa en una, pero no quieren ser demasiado fuera de tema).
Mira algunos usuarios - aspecto especialmente para "rituales", lo que hacen para parecer ninguna razón. Estos suelen ser el signo de la persistente errores y bombas de tiempo. También mirar para ver si se genera una gran cantidad de mensajes de error, se bloquea la interfaz de usuario durante largos períodos mientras que "el pensamiento", y así sucesivamente. Básicamente, cualquier cosa que personalmente hubiera gustado ver como un usuario.
Las pruebas de estrés. Una vez más, las herramientas específicas dependen de la aplicación, pero esto es especialmente aplicable a las aplicaciones basadas en servidor. A ver si la aplicación puede seguir funcionando en situaciones de carga. Si se inicia el tiempo de espera cerca del punto de ruptura, eso está bien; si comienza a generar mensaje de error extraño o peor, parece que los datos corruptos o estado, que es un muy mala señal.

Y eso es todo lo que se pueda imaginar por ahora. Voy a actualizar en su caso más vienen a la mente.

Otros consejos

Estos no están codificando consejos o perfiles de consejos, sino una forma general de evaluar la salud de un programa en cualquier idioma. En orden de importancia

¿Es el usuario final feliz con ella?
¿Es estable?
¿Es robusto?
¿Es rápido?
¿Es la huella de memoria estable durante largos períodos de tiempo y lo que se puede esperar?

Si la respuesta a todas las 5 preguntas es sí, entonces usted tiene una aplicación saludable. Yo diría que 1-3 son realmente los más importantes. Puede que no sea muy en el interior, y las nalgas, posiblemente, abajo a la derecha feo, pero su salud si cumple con estas especificaciones y debe permanecer siempre en el modo tradicional (es decir, pequeñas correcciones de errores)

Yo sugeriría la escritura pruebas en torno a ciertas áreas. No soy un gran fan de las pruebas de unidad - a pesar de que termino de escribir un buen número de ellos. Yo prefiero las pruebas del sistema que las piezas de prueba del sistema - por lo que desde abajo de dominio, el servicio abajo, abajo, etc presentador no neccesarily todo el sistema, sino que parte de ella. Si usted está buscando la eficiencia continuación, estas pruebas pueden correr un cronómetro en todo el código y fallar si se tarda demasiado tiempo.

Otra cosa buena que hacer es ejecutar tareas estándar a través de Hormigas de perfiles o dotTrace de JetBrains. Se le dirá lo que está tomando el tiempo y el número de veces que ha sido plazo, lo que significa que puede ver dónde se puede optimizar / caché.

Si está utilizando NHibernate continuación, NHProf es grande (o creo Ayende ahora ha lanzado el UberProf que cubre más estrategias de acceso DB). Esto le advertirá de cualquier acceso DB estúpida pasando. De no ser así simplemente utilizando el Analizador de SQL Server le puede mostrar solicitando los mismos datos una y otra vez, pero requerirá más esfuerzo filtrando la basura. Si usted termina encima de usar, que luego se puede guardar a una tabla de base de datos, que luego se puede consulta de una manera más inteligente.

Si usted está buscando robustez, una buena cosa que el uso es una estrategia de explotación forestal - capturar todas las excepciones y registrarlos. Esto es bastante fácil de configurar utilizando log4net . También registrar si se golpea ciertos puntos que usted es un poco sospechoso de. Entonces tener esta corriendo en un servidor (utilizo el servidor Kiwi Syslog que es fácil de configurar y bastante potente) que se puede escribir en una base de datos y se puede ejecutar el análisis de los resultados. Yo recomendaría contra el appender ADO.NET para log4net ya que no es asíncrono y así ralentizará su aplicación hacia abajo.

Por último, dependiendo de lo que la aplicación es si realmente estás realmente interesado en pasar algún tiempo en las pruebas de su salud puede utilizar Watin o WinForms equivalente para probar la Interfaz. Esto podría incluso ser una prueba prolongada de ver el uso de memoria / procesador de la aplicación mientras se está utilizando. Si no está preocupado de que a continuación, los ventanas de funcionamiento del analizador le permitirá fijamos en diversos aspectos de la aplicación mientras lo usa. Siempre útil pero hay que meter en realidad una vuelta para conseguir los niveles adecuados.

Espero que esto ayude.

Los primeros dos artículos grandes Me gustaría ver en serían:

Adición de manejo con el registro, así como la búsqueda de cualquier gestión de excepciones que podrían ser "tragar" excepciones, ocultando problemas con su solicitud de excepción mundial (Creo que también es un contador de rendimiento ventanas que se expondrá el número de excepciones por segundo que están siendo arrojados por la aplicación). Esta ayuda puede descubrir a los posibles problemas de consistencia de datos en la aplicación.
Añadir un poco de rendimiento monitoreo y registro a cualquier persistencia de datos y / o dependencias de servicios de redes externas que la aplicación podría estar utilizando, como las consultas de bases de datos de registro o llamadas de servicio web que tardan más de X cantidad de tiempo para completar.

Si esta interactúa con una base de datos, usted debe tener una idea de disco E / S y el grado de fragmentación de la matriz de disco duro /. Para MS SQL, analizar los procedimientos almacenados y revisar los índices y las claves principales en las mesas.

Usted realmente no necesita herramientas para esto, sólo el trabajo sucio de la revisión de contadores y hablar con el DBA.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow