¿Para iniciar sesión o no iniciar sesión?

Question

Ahora estoy construyendo un programa que es un administrador de libros electrónicos, lector, organizador y editor, que también es una transferencia de libros electrónicos (para eReaders como Kindle), pero lo estaba desarrollando y una pregunta me vino a la mente: "¿Iniciar sesión o no?"

Entonces comencé a pensar en el registro. Como muchos programas de registro de acciones, empecé a buscar para ellos y ver cómo se registran las cosas, entonces yo quiero saber:

• Es bueno registrar las acciones o cosas que que sucedió en los programas (como errores)?
• En mi caso, es bueno registrar cosas?
  • ¿Qué necesito para registrarme?
• ¿Cuál es la mejor manera de registrar cosas (archivos de texto, bases de datos ...)?
• ¿Hay alguna herramienta para iniciar sesión en Lazarus?

Answer 1

Es esencial. Registro

1. todos los errores con datos relacionados (método args, etc.). De lo contrario, vas a tener una variedad de comportamientos relacionados con errores que no puedes analizar.
2. puntos clave de entrada y salida (¿qué está haciendo su programa? ¿Debería llamar a estos métodos en este momento?)
3. posibles métodos y operaciones lentos (entrada y salida), para que pueda medir lo que está pasando y saber qué su programa está haciendo/dónde está.
4. donde está cargando las configuraciones, si corresponde. Esto significa que puede ver cómo se está configurando su programa (¿qué configuración utiliza?)

Si lo hace bien, es posible que pierda cada vez menos tiempo en el depurador.

Me gustaría equivocarme al iniciar sesión más bien que poco, y eliminar o filtrar si/cuando esto se convierte en un problema (como se señala a continuación, registrar Gbs por día es probablemente contraproducente). He trabajado en numerosos sistemas donde se ha decretado que el registro se rechazará o se eliminará después del desarrollo, y esto nunca ocurre, ya que es muy útil. Algunas personas se oponen al inicio de sesión sobre la base de que afecta el rendimiento. Si este es el caso, elimínelo cuando se sabe que es un problema, no antes.

Debería poder encontrar marcos de trabajo adecuados para el registro (por ejemplo, log4c para C, log4j para Java) para su plataforma en particular que permitan el filtrado adecuado y la selección de destino. Eso significa que puede iniciar sesión en archivos (y restringir tamaños de registro), bases de datos, monitores remotos, etc. y cambiar esta decisión sobre la marcha (mediante un archivo de configuración o argumentos de línea de comandos).El marco correcto debería requerir muy poco inicialmente además de la inserción de las declaraciones de registro apropiadas. No debería tener que escribir mucho sobre la administración de archivos u otro código de administración de registros.

Aquí hay un useful blog entry sobre este tema, con más instrucciones.

Answer 2

En las primeras fases del desarrollo de componentes, registre todo. Por lo general, hago todo mi desarrollo en la consola de esa manera, y puedo ver que toda mi lógica se muestre línea por línea, si es necesario. A medida que avance, los errores de registro siempre son obligatorios y los valores de registro después de la manipulación de datos complejos también pueden ser útiles. Piense en desastres militares debido al redondeo de flotadores a corto plazo.

Recomiendo iniciar sesión en un archivo plano sobre la base de datos.

Answer 3

Definitivamente, registre los errores en archivos planos formateados consistentemente para que pueda recuperarlos de su cliente y leerlos en Excel o en un DB para su análisis si es necesario.

Answer 4

El registro es esencial y útil. ¿Por qué? Para fines de seguimiento. Mientras desarrolle en una máquina local, puede depurar rápidamente, establecer puntos de interrupción y descubrir dónde van las cosas mal. Una vez que implemente la producción, su cliente lo llamará por teléfono, diciéndole que no vio lo que esperaba (apareció un mensaje de error en algún lugar). Créeme, tendrás dificultades para descubrir qué pasó si no tienes registros.

Hmm ... La respuesta de Brian acaba de hacer estallar al decir básicamente donde quería continuar :)

De todos modos, puede considerar también algunas técnicas orientada a aspectos. Son muy adecuados para fines de registro y mantiene su código limpio. Puede ser una opción para su proyecto.

Respecto al tipo de registro: generalmente trabajo muy bien con archivos de texto sin formato (con un tamaño máximo), a menos que deba realizar un seguimiento de todas las actividades de los usuarios (motivos legales, lo que sea). En tal caso, un registro de DB probablemente sería más apropiado.

Answer 5

El registro es siempre esencial, ya que pueden producirse errores en la producción y se debe generar información sobre lo sucedido.

Sin embargo, aparte de los errores, si registra los puntos clave de entrada y salida, los posibles métodos/operaciones que consumen tiempo, etc., dependen de la aplicación y el entorno. Si no tiene un análisis de rendimiento integrado en su sistema, entonces necesita iniciar sesión o ser capaz de activar el registro detallado para poder rastrear los problemas de rendimiento.

Del mismo modo, si no tiene herramientas de depuración en tiempo real, necesita iniciar sesión o poder iniciar sesión para los puntos de entrada/salida de claves.

Si el sistema maneja millones de transacciones, cada una con millones de operaciones, entonces no desea tener este nivel de inicio de sesión todo el tiempo en cada subsistema/proceso; de lo contrario, su aplicación llena rápidamente todo el espacio de disco disponible - Eso es un problema.

Para sistemas pequeños y simples, es probable que sea suficiente tener un nivel predeterminado general de registro para producción, y un nivel de depuración para rastrear problemas.

Answer 6

Esta es una pregunta muy general ... Para empezar, diría que debería tener varios niveles de registro. En el nivel de rastreo, registre todo lo que tenga en mente. En el nivel de errores, solo se han registrado errores de servidor. Permiten elegir el nivel de registro en el tiempo de ejecución, aunque la selección no debería estar disponible para los usuarios finales. Además, tenga en cuenta que si pone sus registros a disposición de otras personas que no sean usted (su equipo de soporte, por ejemplo), asegúrese de que sus mensajes sean legibles por el ser humano y no algo que usted solo pueda entender.

Hay una gran cantidad de infraestructuras de registro, mire a su alrededor para ver qué se adapta a su entorno de desarrollo. Puede ser más fácil usar una infraestructura bien probada que inventar algo propio.

Answer 7

• Es bueno registrar las acciones o cosas que que sucedió en los programas (como errores)?

Sí, siempre se necesita tener una manera de encontrar nuestra cuál es incorrecto. También debe clasificarlos, por lo que luego puede desactivar el registro de una determinada clase de mensajes de registro (por ejemplo, mientras desarrolla, desea tener mensajes de depuración; después de enviar su aplicación, solo se preocupan por los errores y las advertencias).

• En mi caso, es bueno para registrar las cosas?

ver arriba.

 o What I need to log? 

• Cada error (app/función no funciona)
• Cada Advertencia (app/función todavía funciona, pero vale la pena mantener un registro de la misma)
• la información (algo bueno que tiene)
• depuración (cosas que sólo un desarrollador se preocupa)

Con cada clase, también debe registrar datos relevantes.

• ¿Cuál es la mejor manera de conectarse cosas (archivos de texto, bases de datos ...)?

prefiero archivos, ya que son fáciles de leer y se pueden compartir fácilmente con otros. Pero mientras puedas acceder a los registros, el medio es el problema menor.

Recomendaría utilizar un marco de trabajo de registro, ya que el registro es una parte esencial de su aplicación y para muchas personas ya se les ocurrieron soluciones bastante buenas. De esta forma, no inventará la rueda una y otra vez y tendrá más tiempo para desarrollar su aplicación.

Answer 8

El registro durante el desarrollo en realidad no importa; hágalo si ayuda; deja de hacerlo cuando deja de ayudar.

Los buenos registros se vuelven importantes durante la producción. Enumere los tipos de problemas que encontrará y registre la información que necesita para resolver esos problemas. ¿Serás demandado por infracción de derechos de autor? Luego registre lo que necesita para defenderse. ¿Las personas informarán errores con sus lectores y pedirán ayuda? Luego, registre lo que necesita para responder las preguntas y minimizar sus costos de soporte.

Es fácil registrar demasiada información (inútil). Si no lo necesita, no lo logre. ¿Fallarán los servidores? ¿Las redes fallarán? ¿Te quedarás sin espacio de almacenamiento? Sí, y puede iniciar sesión para ayudar a diagnosticar esos problemas, pero eso es principalmente un trabajo para monitorear, no para iniciar sesión.

Syslog proporciona una administración bastante buena y un control centralizado. Hay muchos marcos de trabajo de registro que funcionan de la misma manera; es la preferencia personal la que uno usa. Utilizo un formato de registro estructurado y de búsqueda sobre syslog.Todo el registro de desarrollo ad hoc se elimina antes de entrar en funcionamiento.