Soyez libéral dans ce que vous acceptez ... ou non?

Question

[Avertissement: cette question est subjective, mais je préférerais obtenir des réponses soutenues par des faits et / ou reflexions]

Je pense que tout le monde sait sur le Robustesse Principe , généralement résumé par la loi de Postel:

Soyez prudent dans ce que vous envoyez; être libéral dans ce que vous acceptez.

Je suis d'accord que pour la conception d'un protocole de communication très répandu cela peut donner un sens (dans le but de permettre l'extension facile), mais je l'ai toujours pensé que son application HTML / CSS a été un échec total, chaque navigateur mettre en œuvre son propre détection / comportement tweak silencieux, ce qui rend presque impossible d'obtenir un rendu cohérent sur plusieurs navigateurs.

Je constate cependant que le RFC du protocole TCP Deems « non silencieux » acceptable, sauf mention contraire ... ce qui est un comportement intéressant, pour le moins.

Il existe d'autres exemples de l'application de ce principe à travers le commerce des logiciels qui apparaissent régulièrement parce qu'ils ont mordu developpeurs, du haut de ma tête:

• Javascript insertion point-virgule
• C (silence) conversions builtin (qui ne serait pas si mal si elle n'a pas tronqué ...)

et il y a des outils pour aider à mettre en œuvre un comportement « intelligent »:

• nom correspondant à des algorithmes phonétiques ( Double Metaphone )
• distances de chaîne algorithmes ( Levenshtein )

Cependant, je trouve que cette approche, alors qu'il peut être utile pour traiter avec les utilisateurs non techniques ou pour aider les utilisateurs dans le processus de récupération d'erreur, a quelques inconvénients lorsqu'elle est appliquée à la conception de la bibliothèque / classes interface:

• il est un peu subjective si les suppositions de l'algorithme « droit », et donc il peut aller à l'encontre Principe de moins Étonnement
• il rend la mise en œuvre plus difficile, donc plus de chances d'introduire des bugs (violation des YAGNI ?)
• il rend le comportement plus sensible aux changements, comme toute modification de la « deviner » la routine peut briser les anciens programmes, presque à l'exclusion des possibilités ... refactorisation dès le départ!

Et voici ce qui m'a conduit à la question suivante:

Lors de la conception d'une interface (bibliothèque, classe, message), pensez-vous penchez vers le principe de robustesse ou non?

Je me tendance à être très stricte, en utilisant la validation étendue d'entrée sur mes interfaces, et je me demandais si j'étais peut-être trop stricte.

Answer 1

Je dirais que robustesse quand il ne présente pas les ambiguïtés .

Par exemple: Lors de l'analyse d'une liste séparée par des virgules, si oui ou non il y a un espace avant / après la virgule ne change pas le sens sémantique.

Lors de l'analyse d'une chaîne guid il devrait accepter un certain nombre de formats communs (avec ou sans tirets, avec ou sans l'entourer d'accolades).

La plupart des langages de programmation sont robustes avec l'utilisation de l'espace blanc. Plus précisément partout où elle ne touche pas le sens du code. Même en Python où les espaces est pertinent, il est toujours flexible lorsque vous êtes à l'intérieur d'une liste ou d'une déclaration dictionnaire.

Je suis certainement d'accord que si quelque chose peut être interprété de multiples façons ou si ce n'est pas 100% ce qu'il faut entendre alors trop robustesse peut finir par être une douleur bien, mais il y a beaucoup de place pour la robustesse sans ambiguïté.

Answer 2

Certainement pas. Des techniques telles que la programmation défensive obscurcit insectes, ce qui leur apparence moins probable et plus aléatoire qui rend leur détection plus difficile d'isoler ce qui les rend plus difficiles.

Le écriture Solid Code a été énorme en mettant l'accent sur la nécessité à plusieurs reprises, et des techniques, de la fabrication les bugs aussi difficiles à introduire ou à masquer. Grâce à l'application de ses principes tels que « Éliminer le comportement aléatoire. Bogues force à reproductible. » et « Cherchez toujours, et éliminer, des failles dans vos interfaces. » les développeurs amélioreront considérablement la qualité de leur logiciel en éliminant l'ambiguïté et les effets secondaires non contrôlés qui est responsable d'une grande quantité d'insectes.

Answer 3

Une application excessive de Robustesse conduit à vous deviner ce que l'utilisateur voulait, ce qui est bien jusqu'à jusqu'à ce que vous vous trompez. Elle exige également la foi tout à fait erronée que vos clients ne seront pas abuser de votre confiance et de créer charabia aléatoire qui se produit juste au travail, mais que vous ne serez pas en mesure de soutenir dans la version 2.

Une application excessive de correction conduit à vous refuser vos clients le droit de faire des erreurs mineures, ce qui est bien jusqu'à ce qu'ils se plaignent que leurs trucs fonctionne très bien sur le produit de votre concurrent, et vous dire ce que vous pouvez faire avec votre niveau de 5000 pages qui a le mot « projet » encore griffonné sur la couverture au crayon et au moins 3 experts affirment est fondamentalement viciée, et 200 experts plus honnêtes disent qu'ils ne comprennent pas bien.

Ma solution personnelle a toujours été deprecation. Vous les soutenez, mais leur dire qu'ils font mal, et (si possible) le chemin le plus facile à la décision correcte. De cette façon, lorsque vous activez le bug-fonction de 10 ans sur toute la ligne, vous avez au moins la piste de papier à l'autre que « nous vous avais prévenu que cela pourrait se produire. »

Answer 4

Malheureusement, le soi-disant « principe de robustesse » ne conduit pas à la robustesse. Prenez HTML comme exemple. Beaucoup des problèmes, des larmes, perte de temps et d'énergie aurait pu être évité si les navigateurs avaient strictement analysé HTML depuis le début au lieu d'essayer de deviner le sens du contenu malformé.

Le navigateur doit simplement avoir affiché un message d'erreur au lieu d'essayer de le réparer sous les couvertures. Cela aurait forcé tous les maladroits pour corriger leur désordre.

Answer 5

Je divise les interfaces en plusieurs groupes (ajouter d'autres si vous le souhaitez):

1. ceux qui sont sous votre contrôle doivent être strictes (classes en général)
2. API bibliothèque, qui devrait être aussi sur le côté strict, mais la validation supplémentaire est conseillé
3. interfaces publiques qui doivent gérer toutes sortes d'abus qui vient (généralement des protocoles, des entrées utilisateur, etc.). Ici, la robustesse de l'entrée est vraiment utile, vous ne pouvez pas attendre tout le monde va fixer leurs trucs. Et rappelez-vous pour l'utilisateur ce sera votre faute si l'application ne fonctionne pas, pas la partie qui a envoyé une merde mal formatée.

Sortie doit toujours être stricte.

Answer 6

Je pense que HTML et le World Wide Web ont fourni une grande échelle essai dans le monde réel du principe Robustesse et montré qu'il était un échec massif. Il est directement responsable du gâchis de confusion en concurrence HTML presque normes qui rend la vie misérable pour les développeurs Web (et leurs utilisateurs) et se aggrave avec chaque nouvelle version d'Internet Explorer.

Nous avons connu depuis les années 1950 comment le code de validation correctement. Lancez-le à travers un analyseur strict et si quelque chose n'est pas syntaxiquement correct, jeter une erreur et abort. Ne passez pas aller, ne pas recueillir 200 $, et pour l'amour de tout ce qui est binaire ne laissez pas une tentative de programme d'ordinateur pour lire l'esprit du codeur s'il a fait une erreur!

HTML et JavaScript nous ont montré exactement ce qui se passe quand ces principes sont ignorés. Le meilleur plan d'action est d'apprendre de leurs erreurs et ne pas les répéter.

Answer 7

En contrepoint à l'exemple de Mason, mon expérience avec la session Initiation Protocol était que tout autre piles interpréteraient les documents RFC différemment (et je soupçonne que cela se produit avec tous Standard jamais écrit), étant (modérément) libéral dans ce que vous acceptez signifie que vous pouvez réellement faire des appels entre deux appareils. Parce que ces appareils sont des choses physiques habituelles, par opposition à des morceaux de logiciels sur un ordinateur de bureau, il vous suffit d'être libéral dans ce que vous acceptez, ou votre téléphone ne peut pas appeler un autre téléphone d'une marque particulière. Cela ne rend pas votre téléphone bon look!

Mais si vous écrivez une bibliothèque, vous n'avez probablement pas le problème de plusieurs partis d'interprétation d'une norme commune de manière mutuellement incompatibles. Dans ce cas, je dirais être strict dans ce que vous acceptez, car il supprime les ambiguïtés.

Le fichier Jargon a également sur « deviner » l'intention d'un utilisateur.

Answer 8

Vous avez raison, la règle s'applique aux protocoles, et non la programmation. Si vous faites une faute de frappe lors de la programmation, vous obtiendrez une erreur dès que vous compilez (ou courir, si vous êtes l'un de ces types de dynamiques). Il n'y a rien à gagner en laissant deviner l'ordinateur pour vous. Contrairement à la commune populaire, nous sommes des ingénieurs et capables de dire exactement ce que veux dire moi. ;)

Ainsi, lors de la conception d'une API, je dirais ne pas suivre le principe Robustesse. Si le développeur fait une erreur, ils doivent savoir à ce sujet tout de suite. Bien sûr, si vos utilisations de l'API des données à partir d'une source externe, comme un fichier, vous devez faire preuve d'indulgence. L'utilisateur de votre bibliothèque devrait savoir au sujet de son / ses propres erreurs, mais pas quelqu'un d'autre.

En aparté, je suppose que « l'échec silencieux » est autorisé dans le protocole TCP parce que sinon, si les gens ont jeté des paquets malformés à vous, vous seriez bombardés avec des messages d'erreur. C'est la simple protection DoS là.

Answer 9

OMI, robustesse est un côté d'un compromis conception pas un principe de « préférer ». Comme beaucoup l'ont souligné, pue rien comme quatre heures soufflant à essayer de comprendre où votre JS a mal tourné pour découvrir le vrai problème était qu'un seul navigateur a fait la bonne chose avec XHTML Strict. Il a laissé le feu page en morceaux quand une partie du code HTML servi était un désastre complet.

D'autre part, qui veut consulter la documentation d'une méthode qui prend 20 arguments et insiste sur le fait qu'ils soient dans le même ordre exactement avec vides ou les détenteurs de valeur nulle place pour ceux que vous voulez sauter? La façon robuste tout aussi terrible pour faire face à cette méthode serait de vérifier tous les arg et essayer de deviner qui était pour ce en fonction des positions relatives et les types, puis échouer en mode silencieux ou essayer de « faire avec » args vides de sens.

Vous pouvez aussi cuire la flexibilité dans le processus en faisant passer un littéral d'objet / dictionnaire / valeur clé liste paire et gérer l'existence de chaque arg que vous obtenez à elle. Pour le compromis entre perf très mineur, c'est un gâteau et le manger trop scénario.

Surcharger args de manière intelligente et cohérente interface est une façon intelligente d'être robuste sur les choses. Ainsi, la redondance est la cuisson dans un système où il est supposé acheminement de paquets sera régulièrement ne parviennent pas à livrer dans un réseau compliqué massivement détenu et géré par tout le monde dans un domaine émergent de la technologie avec une grande variété de moyens potentiels de transmission.

Tolérer abject échec, cependant, en particulier dans un système que vous contrôlez, n'est jamais un bon compromis entre. Par exemple, je devais prendre une pause pour éviter de jeter un ajustement sifflants dans une autre question de mettre JS en haut ou en bas de la page. Plusieurs personnes ont insisté sur le fait qu'il était préférable de mettre JS en haut car alors si la page n'a pas pu charger complètement, vous auriez encore potentiellement avoir une certaine fonctionnalité. pages demi-travail sont pires que des bustes complets. Au mieux, ils entraînent plus de visiteurs sur votre site, vous en supposant raison êtes la incompétente avant de savoir à ce sujet que si la page Busted up est tout simplement rebondi sur une page d'erreur lors de l'échec de son propre contrôle de validation suivi d'un e-mail automatisé quelqu'un qui peut faire quelque chose à ce sujet. Vous sentiriez à l'aise remise vos informations de carte de crédit sur un site qui était demi-Busted tout le temps?

Tenter d'offrir des fonctionnalités 2010 sur un navigateur 1999, vous pouvez simplement fournir une page de faible technologie est un autre exemple d'un compromis entre design téméraires. Les possibilités soufflés et l'argent que j'ai vu perdu le temps de développement consacré à des solutions de contournement punaisés juste pour obtenir des coins arrondis sur un vol stationnaire au-dessus d'un élément! @ # $ Ing fond dégradé par exemple, me ont complètement époustouflé. Et pour quoi? Pour fournir des pages de technologie supérieure qui exécutent mal à technophobes éprouvées tout en vous limitant les choix sur les navigateurs haut de gamme.

Pour que ce soit le bon choix, le choix à l'entrée de la poignée d'une manière robuste doit toujours rendre la vie plus facile des deux côtés du problème, à court et à long terme de l'OMI.

Answer 10

Ne jamais échouer en mode silencieux . En dehors de cela, en essayant de deviner ce que l'utilisateur d'une API / bibliothèque voulait, ne semble pas être une mauvaise idée. Je ne le suivrai pas bien; ayant une exigence stricte, peut révéler des bogues dans le code d'appel et / ou une mauvaise interprétation de votre API / bibliothèque.

En outre, comme cela a déjà été souligné, cela dépend de la façon dont il est difficile de deviner ce que fait l'utilisateur prévu. S'il est très facile, alors vous avez deux cas:

1. Votre bibliothèque doit être conçu un peu différemment (renomme une fonction ou divisée en deux), de sorte que l'utilisateur peut attendre ce que vous fournissez réellement.
2. Si vous pensez que votre bibliothèque est bien conçu, ce qui signifie appellation claire / simple, vous pouvez essayer de déduire ce que l'utilisateur prévu.

Dans tous les cas, qu'il ne soit pas 100% évidente et déterministe, ce qu'une entrée doit être convertie en une autre, vous ne devriez pas faire les conversions, pour un certain nombre de raisons déjà mentionnées (compatibilité déferlant sur refactorisation, moins étonnement des utilisateurs) .

Lorsque vous traitez avec un utilisateur final, en essayant de fixer leur entrée / guess est la bienvenue. Il est devrait pour entrer des informations non valides; ce cas est tout à fait rien d'exceptionnel. Un autre développeur cependant, n'est pas un utilisateur simple non technique. Il a l'expertise nécessaire pour comprendre une erreur, et l'erreur peut avoir une signification / être bénéfique pour lui. Ainsi, je suis d'accord avec vous sur la conception d'API strictes, alors que -De est accompagnée de rigueur Cours-de clarté et de simplicité.

Je vous recommande de lire cette question de la mine , d'un cas similaire.