¿Qué tan detallado debe ser el resultado de validación?[cerrado]

Question

Tengo una aplicación que lee una base de datos y genera alertas sobre cualquier dependencia que no se cumpla.Mi pensamiento en este problema es "dar la información mínima que apunta al usuario al problema". Un compañero de trabajo me ha dicho que debería ser lo más detallado posible, imprimiendo los valores de los campos de la base de datos para cada campo. Menciono versos que dan el mensaje mínimo de que "el campo uno debe ser menos que el campo dos".

Sé que debe haber alguna convención o estándar para este tema, ya que me recuerda los errores y advertencias del compilador.¿Alguien sabe cómo se eligen los mensajes de un compilador?

¿Qué sugerencia tiene la comunidad para este tema?

Answer 1

Al escribir, conozca a su audiencia.

Si está registrando mensajes de advertencia/error para su propio consumo, entonces es bastante fácil:qué hacer tú ¿Necesitas saber cuando algo sale mal?

Si estás registrando mensajes de advertencia/error para otra persona, entonces las cosas se complican.¿Qué saben ellos?¿Cómo es su modelo mental del sistema?¿Qué tipo de problemas poder resuelven, y ¿qué información necesitan para resolverlos?

Incluir hasta el último fragmento de datos en un mensaje es una apuesta: en el mejor de los casos, el lector tendrá que leer información irrelevante para encontrar lo que necesita;en el peor de los casos, se confundirán y terminarán tomando decisiones basadas en la equivocado datos.

La analogía del compilador es adecuada:Piense en lo molesto que sería si se desechara toda la tabla de símbolos junto con cada advertencia...

Answer 2

Creo que la clave es ser conciso.Coloque tantos detalles como sean necesarios sobre el motivo por el que se comunica la advertencia y nada más.

Answer 3

Para el funcionamiento normal del día a día, envío un mensaje de validación de datos que brinda suficiente información para que el usuario pueda solucionar el problema, de modo que los datos se validen.Por ejemplo, si tengo dos campos (campoA y campoB) y uno de ellos tiene que ser mayor que el otro, entonces lo indicaría en el resultado de validación, especificando qué campo es el campo infractor.

Por ejemplo, si A tiene que ser mayor que B y proporcionan una respuesta menor que B, entonces el mensaje sería "el campo A debe ser mayor que el campo B".

Dicho esto, también programo un modo de depuración en mis aplicaciones (especialmente las aplicaciones web) que tiene un modo detallado que dice exactamente qué está sucediendo con todo.Si está activado, verá dos mensajes, el error fácil de usar y luego "CampoA=XX y CampoB=YY:XX no es mayor que YY".

Eso está simplificado, pero es la idea general.

Answer 4

Le sugeriría que implementara ambos modos.Durante el funcionamiento normal, necesita un mensaje útil pero breve.Pero a veces las cosas pueden salir mal y en este caso un modo de "volcado" que proporciona al usuario toda la información posible es un salvavidas.

Answer 5

Creo que hay 3 niveles de detalles de un mensaje de error para los 3 grupos de usuarios típicos:

1. El usuario final.Se trata de un navegante de un sitio web o de un usuario de una aplicación de escritorio.Debería recibir un mensaje de error si el problema no se puede compensar.Debe incluir el mínimo de información.El usuario final no debería recibir ninguna información a través del sistema, como la configuración actual y las rutas de los archivos.El usuario final debe contactar al administrador.Una identificación de error continua puede resultar útil para que el administrador pueda encontrar más información.
2. El administrador necesita más información útil para resolver el problema por sí mismo.Puede incluir información como tabla xy sin fuente o error de inicio de sesión en la base de datos.
3. El desarrollador:Si el administrador no puede resolver el problema, se pondrá en contacto con el proveedor del software.En este caso, el administrador debería poder enviar un archivo de registro para que el desarrollador pueda resolverlo también si no puede reproducir el problema.

Answer 6

Se pueden discutir los detalles del contenido de un registro, pero según mi experiencia, el nivel de detalle se determinará rápidamente durante el proceso. prueba de estrés.
Si el sistema no puede funcionar correctamente es porque usted simplemente:

• ser demasiado detallado con sus registros, o
• inicié sesión con demasiada frecuencia (en realidad, creo El propio Jeff tuvo un problema similar.)

Atwood:Estábamos iniciando sesión de tal manera que el registro...durante la llamada de registro estaba provocando otra llamada de registro.Lo cual normalmente está bien, pero con la carga que tenemos, eventualmente suceden tan juntos que también hay un bloqueo.Entonces, hay dos cerraduras allí.

Spolski:[...] tienes una tendencia a querer registrar todo.Pero luego obtienes registros que son, ya sabes, cien megabytes por usuario y obtienes treinta por minuto y no es posible analizarlos o almacenarlos de ninguna manera razonable.Entonces, lo siguiente que debe hacer es comenzar a seleccionar sus registros o simplemente tener diferentes niveles de depuración, donde es como en el modo de depuración alta todo se registra y en el modo de depuración baja no se registra nada.Y...Es un poco difícil saber qué es lo que realmente quieres en un registro.

Atwood:Quiero decir que, irónicamente, para solucionar este problema, que resultó ser debido al registro, agregamos más registros.

Spolski:[risas]

Atwood:¡El chiste simplemente se escribe solo!El chiste simplemente se escribe solo, ¿verdad?

Entonces, mi punto es que cuando ejecute su sistema en un entorno similar a la producción, debería poder determinar rápidamente si el nivel de detalle que elija es sostenible.

Answer 7

Lidiar con los errores vs.advertencias primero:Un error debería ser por algo que viola el estándar.Una advertencia debe ser para algo que está permitido, pero que probablemente no sea lo que pretendía el autor.

Por ejemplo, el Validador de marcado W3C advertirá sobre el uso de la sintaxis <br /> en un documento HTML.En XHTML esto significa "Un salto de línea", pero en un documento HTML, aunque está permitido, en realidad significa "Un salto de línea seguido de un signo mayor que" (incluso si la mayoría de los navegadores no respetan esto).

En cuanto a la verbosidad, lo mejor depende de quién esté utilizando el sistema.Algunos usuarios estarían mejor con mensajes breves que puedan hojear, mientras que otros usuarios (quizás los menos avanzados) encontrarían útil la información adicional.Sin saber más sobre quiénes son, tendería a usar una bandera (-v es tradicional) para permitir al usuario seleccionar qué versión prefiere.