À quel point la sortie de validation doit-elle être commentée? [fermé]

Question

J'ai une application qui lit une base de données et génère des alertes pour toutes les dépendances non remplies. Mon opinion sur ce problème est la suivante: & Quot; Indiquez le minimum d’informations permettant à l’utilisateur de connaître le problème. & Quot; Un collègue m'a dit que je devrais être aussi verbeux que possible, en imprimant les valeurs des champs de la base de données pour chaque champ. deux ".

Je sais qu'il doit exister une convention ou une norme pour ce problème, car cela me rappelle les erreurs et les avertissements du compilateur. Est-ce que quelqu'un sait comment les messages du compilateur sont choisis?

Quelle suggestion la communauté a-t-elle sur ce problème?

Answer 1

Lorsque vous écrivez, connaissez votre public.

Si vous enregistrez des messages d’avertissement / d’erreur pour votre propre consommation, c’est assez simple: que faut-il vous pour savoir quand un problème se produit?

Si vous enregistrez des messages d'avertissement / d'erreur pour quelqu'un d'autre, la situation devient compliquée. Que savent-ils? À quoi ressemble leur modèle mental du système? Quels types de problèmes peuvent peuvent-ils résoudre et de quelles informations ont-ils besoin pour les résoudre?

Transférer chaque message dans un message est un casse-tête - au mieux, le lecteur devra parcourir des informations non pertinentes pour trouver ce dont il a besoin; au pire, ils seront confus et finiront par prendre des décisions en se basant sur les données erronées .

L'analogie avec le compilateur est pertinente: imaginez à quel point ce serait ennuyeux si toute la table des symboles était vidée avec chaque avertissement ...

Answer 2

Je pense que la clé est d'être concis. Mettez autant de détails que nécessaire pour que la raison de l'avertissement soit communiquée et rien de plus.

Answer 3

Pour les opérations quotidiennes normales, je donne un message de validation des données qui donne suffisamment d'informations pour que l'utilisateur puisse résoudre le problème, afin que les données soient validées. Par exemple, si j’ai deux champs (fieldA et fieldB) et que l’un d’eux doit être supérieur à l’autre, j’énoncerai cela dans la sortie de validation, en spécifiant quel champ est le champ incriminé.

Par exemple, si A doit être supérieur à B et qu’ils fournissent une réponse inférieure à B, le message sera & "; fieldA doit être supérieur à fieldB &";

.

Cela étant dit, je programme également un mode débogage dans mes applications (notamment les applications Web), qui dispose d'un mode commenté, indiquant exactement ce qui se passe avec tout. Si cette option est activée, deux messages s'affichent, l'erreur conviviale, puis & Quot; FieldA = XX et FieldB = YY: XX n'est pas supérieur à YY & Quot;.

C'est simplifié, mais c'est l'idée générale.

Answer 4

Je suggérerais que vous utilisiez les deux modes. Pendant le fonctionnement normal, vous avez besoin d’un message utile mais bref. Mais parfois, les choses peuvent mal se passer et dans ce cas, un mode "vidage" donnant à l'utilisateur toutes les informations possibles est un gage de survie.

Answer 5

Je pense qu'il y a 3 niveaux de détails d'un message d'erreur pour les 3 groupes d'utilisateurs typiques:

1. l'utilisateur final. C'est un internaute sur un site Web ou un utilisateur d'une application de bureau. Il devrait recevoir un message d'erreur si le problème ne peut pas être compensé. Il devrait inclure le minimum d'informations. L'utilisateur final ne doit recevoir aucune information sur le système, telle que la configuration actuelle et les chemins d'accès aux fichiers. L'utilisateur final doit contacter l'administrateur. Un identifiant d'erreur continu peut être utile pour que l'administrateur puisse trouver plus d'informations.
2. L'administrateur a besoin d'informations supplémentaires utiles pour résoudre le problème lui-même. Il peut inclure des informations telles que table xy not fount ou que la connexion à la base de données a échoué.
3. Le développeur: si l'administrateur ne peut pas résoudre le problème, il contactera le fournisseur du logiciel. Dans ce cas, l'administrateur doit pouvoir envoyer un fichier journal que le développeur peut résoudre, même s'il ne peut pas reproduire le problème.

Answer 6

Les détails du contenu d’un journal peuvent être discutés, mais j’ai appris que le niveau de verbosité sera rapidement déterminé au cours de test de résistance .

Si le système ne peut pas fonctionner correctement, c’est parce que vous venez:

• soit trop bavard avec vos journaux, ou
• s'est connecté trop souvent (en fait, je pense que Jeff lui-même a eu un problème similaire )

  

Atwood : nous nous sommes connectés de manière à ce que le journal ... lors de l'appel du journal déclenche un autre appel au journal. Ce qui est normalement acceptable, mais avec la charge que nous avons, ils finiraient par arriver si près l'un de l'autre qu'il y aurait aussi un verrou. Donc, il y a deux serrures qui se passent là-bas.

     

Spolsky : [...] vous avez tendance à tout enregistrer. Mais alors vous obtenez juste des journaux qui sont, vous savez, une centaine de mégaoctets par utilisateur et vous en obtenez trente par minute et il ne peut pas être analysé ou stocké de manière raisonnable. La prochaine chose que vous devez faire est donc de commencer à supprimer vos journaux ou de simplement avoir différents niveaux de débogage, comme si en mode de débogage élevé tout était consigné et en mode de débogage faible, rien ne fut consigné. Et ... c'est un peu difficile de comprendre ce que vous voulez vraiment dans un journal.

     

Atwood : je veux dire que, paradoxalement, pour résoudre ce blocage, qui s'est avéré être dû à la journalisation, nous avons ajouté davantage de journalisation.

     

Spolsky : [rires]

     

Atwood : La blague vient de s'écrire! La blague vient de s'écrire, n'est-ce pas ...

Donc, si vous exécutez votre système dans un environnement de production, vous devriez pouvoir rapidement déterminer si le niveau de verbosité que vous choisissez est durable.

Answer 7

Traitement des erreurs contre Vs. warnings first: Une erreur devrait concerner quelque chose qui ne respecte pas la norme. Un avertissement doit concerner quelque chose qui est autorisé, mais qui n’est sans doute pas ce que l’auteur a voulu.

Par exemple, le validateur de balisage du W3C avertira de l'utilisation de la syntaxe < br / > dans un document HTML. En XHTML, cela signifie & "Un saut de ligne &", Mais dans un document HTML, tout en étant autorisé, signifie en réalité & "Un saut de ligne suivi d'un signe supérieur à &"; (même si la plupart des navigateurs ne respectent pas cela).

En ce qui concerne la verbosité, le meilleur dépend de la personne qui utilise le système. Certains utilisateurs seraient mieux avec des messages brefs qu'ils pourraient parcourir rapidement, alors que d'autres utilisateurs (peut-être ceux moins avancés) trouveraient les informations supplémentaires utiles. Sans en savoir plus sur qui ils sont, j’ai tendance à utiliser un drapeau (-v est traditionnel) pour permettre à l’utilisateur de choisir la version qu’il préfère.