Prácticas de registro de depuración general

Question

Debido a los eventos recientes, estoy tratando de averiguar cuántos registros de depuración debo usar para el código en general.

Lo que he estado haciendo es usar registros de depuración con bastante moderación, y solo en casos en los que quería información adicional o lo que sea. Esto tiene sentido para mí, ya que parece que no debe registrar cada pequeña cosa que hace su código, ya que eso podría inundarlo con tanta información que sería más fácil perderse algo que realmente era importante (o volverse loco al cavar). a través de y verificando los registros).

Por otro lado, presento un ejemplo: recién comencé a usar logback/slf4j para mi proyecto java, y para probar que tenía el archivo .xlm configurado correctamente agregué una declaración de registro de depuración al final de un método que inicializa los componentes de GUI. Normalmente, nunca habría puesto una declaración de registro allí, porque es bastante obvio si los componentes de tu GUI no se inicializan correctamente cuando ejecutas el programa. Sin embargo, esta vez ejecuté el programa, y ​​bajo y he aquí los registros mostraron que los componentes de la interfaz gráfica de usuario se estaban inicializando dos veces, a pesar de que solo se mostraba un conjunto de ellos. Un error de un tamaño decente, pero algo que probablemente no habría capturado sin esas declaraciones de depuración.

Así que mi pregunta: ¿Hay alguna "mejores prácticas" disponibles cuando se trata de registros de depuración? He visto muchas preguntas de mejores prácticas cuando se trata de registros de información, excepciones, errores, etc., pero no he encontrado mucho por ahí en lo que respecta a los registros de depuración.

Gracias :)

Answer 1

algunas reflexiones:

1. No se limite registro de lo que está pasando, pero tenga cuidado de registrar los parámetros disponibles/método argumentos etc. Es fácil pasar por alto este.
2. Es fácil desactivar el registro de depuración a través de la configuración en lugar de iniciar sesión después de los hechos.
3. No se preocupe por la tala de inicio de sesión hasta que realmente se convierta en un problema.
4. Puede automatizar algunas de registro (entrada/salida de los métodos) mediante el uso de un marco de AOP (primavera/AspectJ etc.)

Answer 2

No creo que hay alguna "mejores prácticas" para decidir qué/cómo mucho para iniciar sesión Es una de esas situaciones de catch-22. Si necesita ver los registros, "nunca" hay suficiente información allí, pero si no lo hace, entonces "todo" el registro es solo un desorden de código y una sobrecarga de tiempo de ejecución innecesaria. Debe hacer un juicio por separado sobre dónde trazar la línea para cada aplicación.

Sin embargo, un punto a tener en cuenta. Si usted y sus clientes pueden hackear el código para agregar declaraciones de depuración temporales, entonces no necesita tanto código de registro permanente en su lugar. Pero si no tiene la opción de piratear el código de producción (casi) para depurar cosas, entonces necesita un cierto nivel de código de registro en su lugar, por si acaso ...