Seien Sie liberal in dem, was Sie akzeptieren ... oder nicht?

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/12401

  •  16-10-2019
  •  | 
  •  

Frage

Haftungsausschluss: Diese Frage ist subjektiv, aber ich würde es vorziehen, Antworten durch Fakten und/oder Reflexionen zu erhalten

Ich denke, jeder weiß über das Robustheitsprinzip, normalerweise nach Postels Gesetz zusammengefasst:

Seien Sie konservativ in dem, was Sie senden; Sei liberal in dem, was du akzeptierst.

Ich würde zustimmen, dass für die Gestaltung eines weit verbreiteten Kommunikationsprotokolls dies sinnvoll sein kann (mit dem Ziel, eine einfache Erweiterung zu ermöglichen), aber ich habe immer gedacht, dass seine Anwendung auf HTML / CSS ein totaler Fehler war, wobei jeder Browser seinen eigenen stillen Tweak implementiert Erkennung / Verhalten, was es nahezu unmöglich macht, ein konsistentes Rendering über mehrere Browser hinweg zu erhalten.

Ich bemerke jedoch, dass dort das RFC des TCP -Protokolls als "stilles Versagen" für akzeptabel hält, sofern nicht anders angegeben ... was ein interessantes Verhalten ist, um es gelinde auszudrücken.

Es gibt andere Beispiele für die Anwendung dieses Prinzips während des gesamten Softwarehandels, die regelmäßig auftauchen, weil sie Entwickler von der Spitze von meinem Kopf gebissen haben:

  • JavaScript-Halbkoloninsertion
  • C (stille) gebaute Konvertierungen (was nicht so schlimm wäre, wenn es nicht abgeschnitten würde ...)

Und es gibt Tools, mit denen das "intelligente" Verhalten implementiert werden kann:

Ich stelle jedoch fest, dass dieser Ansatz, obwohl er bei der Behandlung nicht-technischer Benutzer hilfreich sein kann oder um Benutzern bei der Wiederherstellung der Fehler zu helfen, einige Nachteile aufweist, wenn sie auf die Gestaltung der Schnittstelle zwischen Bibliothek/Klassen angewendet werden:

  • Es ist etwas subjektiv, ob der Algorithmus "richtig" vermutet, und daher kann er gegen die verstoßen Prinzip der geringsten Erstaunen
  • Dies erschwert die Implementierung und somit mehr Chancen, Fehler einzuführen (Verletzung von Yagni ?)
  • Es macht das Verhalten anfälliger für Veränderungen, da jede Änderung der "Raten" -Routine alte Programme brechen kann, was von Anfang an die Wiederaufbau -Möglichkeiten ausschließt!

Und das hat mich zu der folgenden Frage geführt:

Wenn Sie sich beim Entwerfen einer Schnittstelle (Bibliothek, Klasse, Nachricht) zum Robustheitsprinzip neigen oder nicht?

Ich selbst neige dazu, ziemlich streng zu sein, verwende eine umfassende Eingabevalidierung an meinen Schnittstellen, und ich habe mich gefragt, ob ich vielleicht zu streng war.

War es hilfreich?

Lösung

ich würde sagen Robustheit, wenn es keine Mehrdeutigkeiten einführt.

Zum Beispiel: Beim Parsen einer von Kommas getrennten Liste ändert sich ein Platz vor/nach dem Komma nicht die semantische Bedeutung.

Bei der Analyse eines String -GUID sollte eine Anzahl der gemeinsamen Formate (mit oder ohne Striche, mit oder ohne umgebende lockige Klammern) akzeptiert werden.

Die meisten Programmiersprachen sind robust mit der Nutzung von Weißraum. Insbesondere überall, wo es die Bedeutung von Code nicht beeinflusst. Selbst in Python, wo Whitespace relevant ist, ist es immer noch flexibel, wenn Sie sich in einer Liste oder einer Wörterbucherklärung befinden.

Ich stimme definitiv zu, dass, wenn etwas auf verschiedene Arten interpretiert werden kann oder nicht 100% klar ist, was gemeint war, zu viel Robustheit sein kann, aber es gibt viel Raum für Robustheit, ohne mehrdeutig zu sein.

Andere Tipps

Definitiv nicht. Techniken wie Defensivprogrammierung verdeckt Bugs, das ihr Aussehen weniger wahrscheinlich und zufälliger, was ihre Erkennung schwieriger macht, was die Isolierung erschwert.

Die weit unterbewerteten Solide Code schreiben war enorm darin, die Bedürfnisse und Techniken wiederholt zu betonen, Fehler als schwer einzuführen oder zu verbergen. Durch Anwendung seiner Prinzipien wie "beseitigen zufällige Verhalten. Erzwingen Sie, dass Fehler reproduzierbar sind". Und "Suchen Sie immer nach und eliminieren Sie Fehler in Ihren Schnittstellen." Entwickler werden die Qualität ihrer Software erheblich verbessern, indem sie die Mehrdeutigkeit und unkontrollierte Nebenwirkungen eliminieren, die für eine große Anzahl von Fehlern verantwortlich sind.

Überanwendung von Robustheit führt dazu, dass Sie erraten, was der Benutzer wollte, was in Ordnung ist, bis Sie es falsch verstehen. Es erfordert auch den völlig fehlgeleiteten Vertrauen, dass Ihre Kunden Ihr Vertrauen nicht missbrauchen und zufällige Kauderschaftsschulen erstellen, die zufällig funktioniert, aber dass Sie in Version 2 nicht unterstützen können.

Überanwendung der Korrektheit führt dazu, dass Sie Ihren Kunden das Recht verweigern, geringfügige Fehler zu machen. Dies ist in Ordnung, bis sie sich beschweren, dass ihre Sachen für das Produkt Ihres Konkurrenten einwandfrei funktionieren, und Ihnen mitzuteilen, was Sie mit Ihrem 5.000 -Seiten -Standard tun können, das das Wort hat "Entwurf" wurde in Crayon immer noch auf das Cover gekreuzt, und mindestens 3 Experten behaupten, es sei grundsätzlich fehlerhaft, und 200er ehrlicherer Experten sagen, dass sie nicht vollständig verstehen.

Meine persönliche Lösung war schon immer Abschaltung. Sie unterstützen sie, sagen ihnen aber ihnen, dass sie falsch machen, und (wenn möglich) der einfachste Weg zur Korrektheit. Auf diese Weise haben Sie, wenn Sie die Fehlerfunktion 10 Jahre hinunter ausschalten, zumindest die Papierspur, um zu sagen, dass "wir Sie gewarnt haben, dass dies passieren könnte."

Leider führt das sogenannte "Robustheitsprinzip" nicht zu Robustheit. Nehmen Sie HTML als Beispiel. Viel Mühe, Tränen, Zeit- und Energieverschwendung hätten vermieden werden können, wenn Browser von Anfang an HTML HTML streng analysiert hätten, anstatt zu versuchen, die Bedeutung von missgebildeten Inhalten zu erraten.

Der Browser hätte einfach eine Fehlermeldung angezeigt haben, anstatt zu versuchen, sie unter den Cover zu beheben. Das hätte alle Bungler gezwungen, ihr Chaos zu beheben.

Ich teilen Schnittstellen in mehrere Gruppen auf (fügen Sie mehr hinzu, wenn Sie möchten):

  1. Diejenigen, die unter Ihrer Kontrolle stehen, sollten streng sein (Klassen normalerweise)
  2. Bibliotheks -APIs, das auch streng sein sollte, aber zusätzliche Validierung wird empfohlen
  3. Öffentliche Schnittstellen, die jede Art von Missbrauch verarbeiten müssen (normalerweise Protokolle, Benutzereingaben usw.). Hier zahlt sich die Robustheit für Input wirklich aus, Sie können nicht erwarten, dass jeder ihre Sachen reparieren wird. Und denken Sie daran, dass der Benutzer Ihre Schuld sein wird, wenn die Anwendung nicht funktioniert, nicht die Partei, die einen schlecht formatierten Mist gesendet hat.

Die Ausgabe muss immer streng sein.

Ich denke, dass HTML und das World Wide Web einen umfassenden praktischen Test des Robustheitsprinzips erbracht haben und gezeigt haben, dass es ein massives Versagen ist. Es ist direkt verantwortlich für das verwirrende Durcheinander der konkurrierenden HTML-Fast-Standards, das das Leben für Webentwickler (und deren Benutzer) das Leben unglücklich macht, und verschlechtert sich mit jeder neuen Internet-Explorer-Version.

Wir wissen seit den 1950er Jahren, wie Code ordnungsgemäß validiert werden kann. Führen Sie es durch einen strengen Parser und wenn etwas nicht syntaktisch korrekt ist, werfen Sie einen Fehler und lassen Sie ab. Gehen Sie nicht los, sammeln Sie nicht 200 US -Dollar und aus Liebe zu allem, was binär ist Lassen Sie nicht zu, dass ein Computerprogramm versucht, den Codierer zu lesen, wenn er einen Fehler gemacht hat!

HTML und JavaScript haben uns genau gezeigt, was passiert, wenn diese Prinzipien ignoriert werden. Die beste Vorgehensweise ist, aus ihren Fehlern zu lernen und sie nicht zu wiederholen.

Als Kontrapunkt zu Masons Beispiel meine Erfahrung mit dem Gesprächs Protokoll war, dass während unterschiedliche Stapel die relevanten RFCs unterschiedlich interpretieren würden (und ich vermute, dass dies mit jeder Standard, jemals geschrieben), ist (mäßig) liberal in dem, was Sie akzeptieren, dass Sie tatsächlich Anrufe zwischen zwei Geräten tätigen können. Da diese Geräte im Gegensatz zu Software -Teilen auf einem Desktop üblich sind, müssen Sie einfach liberal in dem sein, was Sie akzeptieren, oder Ihr Telefon kann nicht ein anderes Telefon eines bestimmten Make anrufen. Das lässt Ihr Telefon nicht gut aussehen!

Wenn Sie jedoch eine Bibliothek schreiben, haben Sie wahrscheinlich nicht das Problem mehrerer Parteien, einen gemeinsamen Standard auf für beide Seiten inkompatible Weise zu interpretieren. In diesem Fall würde ich sagen, dass Sie streng in dem, was Sie akzeptieren,, weil es Unklarheiten beseitigt.

Die Jargon -Datei hat auch eine Horror Geschichte Bei der Absicht eines Benutzers.

Sie haben Recht, die Regel gilt für Protokolle und nicht für die Programmierung. Wenn Sie beim Programmieren einen Tippfehler erstellen, erhalten Sie einen Fehler, sobald Sie kompilieren (oder ausführen, wenn Sie einer dieser dynamischen Typen sind). Es gibt nichts zu gewinnen, indem der Computer für Sie erraten wird. Im Gegensatz zu den gewöhnlichen Menschen sind wir Ingenieure und in der Lage, genau zu sagen, was ich meine. ;))

Also würde ich beim Entwerfen einer API sagen nicht Folgen Sie dem Robustheitsprinzip. Wenn der Entwickler einen Fehler macht, sollten er sofort davon erfahren. Wenn Ihre API wie eine Datei Daten von einer externen Quelle verwendet, sollten Sie natürlich nachsichtig sein. Der Benutzer Ihrer Bibliothek sollte sich über seine eigenen Fehler informieren, aber nicht von jemand anderem.

Abgesehen davon würde ich vermuten, dass im TCP -Protokoll "stille Misserfolg" erlaubt ist, da Sie sonst, wenn Menschen missgebildete Pakete auf Sie werfen würden, mit Fehlermeldungen bombardiert würden. Das ist ein einfacher DOS -Schutz genau dort.

IMO, Robustheit ist eine Seite eines Design-Kompromisses, kein "Vorzug" -Prinzip. Wie viele betont haben, stinkt nichts wie vier Stunden, um herauszufinden, wo Ihr JS schief gelaufen ist, nur um festzustellen, dass das eigentliche Problem nur ein Browser mit XHTML streng das Richtige gemacht hat. Es ließ die Seite in Stücke gehen, wenn ein Teil des servierten HTML eine vollständige Katastrophe war.

Auf der anderen Seite, wer möchte die Dokumentation nach einer Methode nachsehen, die 20 Argumente einnimmt und darauf besteht, dass sie genau in der gleichen Reihenfolge mit leeren oder null -Wert -Platzinhabern für diejenigen sind, die Sie überspringen möchten? Die ebenso schreckliche, robuste Art, mit dieser Methode umzugehen, wäre, jeden Arg zu überprüfen und zu versuchen, zu erraten, welche auf relativen Positionen und Typen basiert, und dann stillschweigend zu scheitern oder mit bedeutungslosen Argumenten zu "machen".

Oder Sie können die Flexibilität in den Prozess einbacken, indem Sie ein Objektlistenlistenliste für die Literal-/Wörterbuch-/Schlüsselwerbung übergeben und die Existenz jedes Args so verarbeiten, wie Sie es erreichen. Für den sehr kleinen Perf -Kompromiss ist das ein Kuchen und essen Sie es zu Szenario.

Das Überladen von Argumenten auf intelligente und interface-konsistente Weise ist eine kluge Möglichkeit, um die Dinge robust zu machen. Das Backen von Redundanz in ein System, in dem angenommen wird, dass die Paket -Lieferung regelmäßig in einem massiv komplizierten Netzwerk geliefert wird, das von allen in einem aufstrebenden Technologiebereich mit einer Vielzahl potenzieller Mittel zur Übertragung gehalten wird.

Das Tolerieren von bitterem Ausfall, insbesondere innerhalb eines von Ihnen kontrollierten Systems, ist niemals ein guter Kompromiss. Zum Beispiel musste ich eine Verschnaufpause einlegen, um zu vermeiden, dass ein zischvoller Punkt in eine weitere Frage zum Einstellen von JS oben oder unten auf der Seite steckt. Mehrere Personen bestanden darauf, dass es besser war, JS an die Spitze zu bringen, denn wenn die Seite dann nicht vollständig geladen worden wäre, hätten Sie möglicherweise immer noch eine Funktionalität. Halbbearbeitungsseiten sind schlechter als vollständige Büsten. Bestenfalls führen sie dazu, dass mehr Besucher auf Ihrer Website zu Recht angenommen werden, dass Sie inkompetent sind, bevor Sie es erfahren, als wenn die kaputte Seite einfach auf eine Fehlerseite abprallt wird Jemand, der etwas dagegen tun kann. Würden Sie sich wohl fühlen, wenn Sie Ihre Kreditkarteninformationen an eine Website übergeben, die die ganze Zeit halb geändert wurde?

Der Versuch, 2010 Funktionen für einen Browser von 1999 zu liefern, wenn Sie nur eine Seite mit niedrigerer Tech liefern können, ist ein weiteres Beispiel für einen törbaren Kompromiss für Design. Die Chancen, die ich für die Entwicklerzeit geblasen habe, die ich für mit Bug-geschnittene Problemumgehungen aufgewendet habe, nur um abgerundete Ecken an einem Element zu bekommen, das zum Beispiel über einem! Und wofür? Bereitstellung höherer Tech -Seiten, die schlecht für bewährte Technphoben abschneiden und gleichzeitig Ihre Auswahl an Hochzeitsbrowsern einschränken.

Damit es die richtige Wahl ist, sollte die Wahl, die Eingaben auf eine robuste Weise zu verarbeiten, das Leben auf beiden Seiten des Problems immer einfacher erleichtern, kurzfristig und langfristig IMO.

Scheitern Sie nie schweigend. Abgesehen davon klingt der Versuch, über das zu erraten, was der Benutzer einer API/Bibliothek wollte, nicht nach einer schlechten Idee. Ich würde es aber nicht folgen; Eine strikte Anforderung kann Fehler im Anrufcode und/oder Fehlinterpretationen über Ihre API/Bibliothek aufdecken.

Darüber hinaus hängt es, wie bereits erwähnt, davon ab, wie schwierig es ist, tatsächlich zu erraten, was der Benutzer erwartet hat. Wenn es sehr einfach ist, haben Sie zwei Fälle:

  1. Ihre Bibliothek sollte etwas anders gestaltet werden (benennen Sie eine Funktion um oder teilen Sie sie in zwei Teile auf), damit der Benutzer erwarten kann, was Sie tatsächlich bereitstellen.
  2. Wenn Sie der Meinung sind, dass Ihre Bibliothek ordnungsgemäß gestaltet ist, was ein klares / unkompliziertes Namen bedeutet, können Sie versuchen, zu schließen, was der Benutzer beabsichtigt hat.

In jedem Fall, dass es nicht 100% offensichtlich und deterministisch ist, sollte ein Eingang in einen anderen konvertiert werden, sollten Sie die Konvertierungen aus einer Reihe bereits genannter Gründe nicht durchführen (die Kompatibilität beim Wiederaufbau, am wenigsten erstaunt).

Wenn Sie sich mit einem Endbenutzer befassen, ist es sehr willkommen, der Versuch, seine Eingabe/Vermutung zu beheben. Er ist erwartet Ungültige Informationen eingeben; Dieser Fall ist völlig nicht außergewöhnlich. Ein anderer Entwickler ist jedoch kein einfacher nicht technischer Benutzer. Er hat das Know -how, um einen Fehler zu verstehen, und der Fehler kann für ihn eine Bedeutung haben/von Vorteil sein. Daher stimme ich Ihnen bei der Gestaltung strenger APIs zu, während die Strenge von Klarheit und Einfachheit begleitet wird.

Ich würde empfehlen, dass Sie lesen Diese Frage von mir, von einem ähnlichen Fall.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top