Anwendungsbeispiele von Hyrum’s Law in Golang

 (abenezer.org)
2 Punkte von GN⁺ 2024-11-23 | 1 Kommentare | Auf WhatsApp teilen

  • Hyrum’s Law und Golang

    • Beim Durchsehen der Gocodebase wurde kürzlich ein interessanter Kommentar entdeckt
    • Codebeispiel mit dem Kommentar: "Dieser Text kann wegen Hyrum’s Law nicht geändert werden"
    • Die Error()-Methode der Struktur MaxBytesError gibt die Fehlermeldung "http: request body too large" zurück

  • Hyrum’s Law

    • Ein nach dem Google-Softwareingenieur Hyrum Wright benanntes Prinzip
    • Wenn viele Nutzer eine API verwenden, wird sich jemand auf jedes beobachtbare Verhalten des Systems verlassen
    • Jedes im Code beobachtbare Verhalten, ob beabsichtigt oder zufällig, wird sich letztlich von irgendjemandem zunutze gemacht oder als Abhängigkeit genutzt
    • Erklärt, warum das Ändern von Fehlermeldungen bestehenden Code kaputt machen kann

  • Beispiele in Golang

    • Auch in den Paketen crypto/rsa und internal/weak wurden Kommentare gefunden, die Hyrum’s Law erwähnen
    • Kommentarbeispiele aus crypto/rsa/rsa.go und crypto/rsa/pss.go
    • Kommentarbeispiel aus dem Paket internal/weak

  • Beobachtungen

    • Das ist nicht auf Golang beschränkt
    • Ein ähnliches Phänomen lässt sich auch in der Evolution von JavaScript beobachten
    • Dieses Phänomen wird Hyrum’s Law genannt

  • Abschließende Gedanken

    • Eine Erinnerung daran, vorsichtig zu sein, wenn man Code ändert, von dem andere abhängen könnten
    • Es ist wichtig, Systeme so zu entwerfen, dass unbeabsichtigtes Verhalten nicht zu einer Abhängigkeit wird
    • Man sollte im Kopf behalten, dass kleine Änderungen große Auswirkungen haben können

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-23
Hacker-News-Kommentare

  • Hyrum's Law ist eine nützliche Beobachtung, aber man muss aufpassen, keine falschen Schlussfolgerungen daraus zu ziehen. Die gesamte Laufzeit einer Funktion ist ebenfalls eine beobachtbare Eigenschaft. Eine Funktion zu optimieren und schneller zu machen, kann für 99,99999999 % der Nutzer gut sein, aber trotzdem eine Breaking Change darstellen. Daher sollte man verstehen, dass eine "Breaking Change" kein technischer, sondern ein sozialer Vertrag ist. Bibliotheksautoren sollten dokumentieren, welche Teile der API unverändert bleiben, und Empathie für die Nutzer haben. Nutzer von Bibliotheken sollten verstehen, dass die Verwendung nicht dokumentierter Schnittstellen riskant sein kann, und Empathie für die Autoren haben

  • In der Go-Sprache werden Hyrum's Law und Abwärtskompatibilität sehr ernst genommen. Zum Beispiel verwendet die Funktion GenerateKey MaybeReadByte, damit der Algorithmus nicht festgelegt wird. Es wird daran gearbeitet, Probleme mit ECDSA-Schlüsseln zu lösen. Die Iterationsreihenfolge von Maps wird zufällig festgelegt, damit Interna nicht offengelegt werden. Die Ausgabe von rand.Rand gilt als Teil des Kompatibilitätsversprechens, weshalb viel Aufwand in Verbesserungen investiert wird. Es wird ständig darüber diskutiert, welche Zusagen in der Dokumentation gemacht und welche Verhaltensweisen ausdrücklich ausgeschlossen werden sollen

  • Als Lösung für ein bestimmtes Problem wird empfohlen, statt stringbasierter Fehler Sentinel-Fehler zu verwenden. Vordefinierte Fehlerwerte, Typen oder Konstanten sollten genutzt werden, damit API-Konsumenten nicht von nichttechnischen Zeichenketten abhängen. Hyrum's Law existiert zwar, aber seine Auswirkungen lassen sich abmildern

  • Eine Möglichkeit, Hyrum's Law entgegenzuwirken, besteht darin, Zufälligkeit hinzuzufügen. Das QUIC-Protokoll setzt ungenutzte Felder auf Zufallswerte, damit Router nicht davon abhängig werden, Pakete zu identifizieren. Das wird als "greasing" bezeichnet und verhindert "ossification"

  • Die Go-Designer wollten keine Exceptions, aber informelle Fehler sind problematisch. Es braucht eine Diskussion darüber, wie sich typisierte Fehler ohne Pattern Matching behandeln lassen

  • Jemand berichtete von einer Erfahrung im Job: Ein Tippfehler in einer Fehlermeldung wurde gefunden und korrigiert, aber weil Abhängigkeiten so tief auf genau diesem Tippfehler beruhten, ließ sich die Änderung nicht beibehalten und musste wieder rückgängig gemacht werden

  • Die Fehler in Go hätten als Enum-Typen gestaltet werden können, aber stattdessen wurden Strings als Typ verwendet, sodass unklar ist, wie Konsumenten davon abhängig werden. Das ist eine alte Designentscheidung, obwohl bessere Alternativen existieren

  • Hyrum's Law ist das genaue Gegenteil des Robustness Principle bzw. von Postel's Law. Wenn man bei dem, was man akzeptiert, großzügig ist, muss man verstehen und dokumentieren, auf welche Weise das geschieht. APIs sollten möglichst so entworfen werden, dass sie bei dem, was sie akzeptieren, nicht zu großzügig sind

  • Hyrum's Law zeigt sich oft in Tests. Unterschiedliche Arten von Tests brechen wegen Annahmen über nicht garantiertes Verhalten. Beispiele sind Änderungen an der Elementreihenfolge einer Hashmap, Änderungen an Fehlermeldungen oder Änderungen bei der Behandlung von Schaltjahren

  • Manche Paketautoren sind möglicherweise aufgeschlossener gegenüber Hyrum's Law. In den Kommentaren zum Paket json wurde festgestellt, dass zwar interne Details gemeint sind, aber weit verbreitete Pakete über linkname darauf zugreifen