2 puan yazan GN⁺ 2024-11-23 | 1 yorum | WhatsApp'ta paylaş
  • Hyrum Yasası ve Golang

    • Yakın zamanda Gocodebase'i incelerken ilginç bir yorumla karşılaştım
    • "Hyrum Yasası nedeniyle bu metin değiştirilemez" yorumunun bulunduğu bir kod örneği
    • MaxBytesError yapısının Error() metodunda "http: request body too large" hata mesajı döndürülüyor
  • Hyrum Yasası

    • Adını Google yazılım mühendisi Hyrum Wright'tan alan bir ilke
    • Çok sayıda kullanıcı bir API'yi kullandığında, sistemin gözlemlenebilir tüm davranışlarının biri tarafından bağımlılık haline getirileceğini söyler
    • Koddaki kasıtlı ya da tesadüfi tüm gözlemlenebilir davranışlar eninde sonunda biri tarafından bağımlı olunan bir şeye dönüşür
    • Hata mesajlarını değiştirmenin neden mevcut kodu bozabileceğini açıklar
  • Golang'daki örnekler

    • crypto/rsa ve internal/weak paketlerinde de Hyrum Yasası'ndan bahseden yorumlar bulundu
    • crypto/rsa/rsa.go ve crypto/rsa/pss.go içindeki yorum örnekleri
    • internal/weak paketi içindeki yorum örneği
  • Gözlemler

    • Bu durum yalnızca Golang'a özgü değil
    • JavaScript'in evrim sürecinde de benzer olgular gözlemlenebiliyor
    • Bu olguya Hyrum Yasası deniyor
  • Son düşünceler

    • Başkalarının bağımlı olabileceği kodu değiştirirken dikkatli olunması gerektiğini hatırlatıyor
    • İstenmeyen davranışların bağımlılığa dönüşmemesi için sistemleri buna göre tasarlamak önemli
    • Küçük değişikliklerin büyük etkiler yaratabileceğini akılda tutmak gerekiyor

1 yorum

 
GN⁺ 2024-11-23
Hacker News yorumu
  • Hyrum's Law faydalı bir gözlem, ancak yanlış sonuçlara varmamak için dikkatli olunmalı. Bir fonksiyonun toplam çalışma süresi de gözlemlenebilir bir özelliktir; bu nedenle bir fonksiyonu optimize edip daha hızlı hale getirmek kullanıcıların %99.99999999'u için iyi olabilir, ancak bu kırıcı bir değişiklik de olabilir. Bu yüzden "kırıcı değişiklik"in teknik bir sözleşme değil, toplumsal bir sözleşme olduğunu anlamak gerekir. Kütüphane yazarları API'nin hangi kısımlarının değişmeyeceğini belgelendirmeli ve kullanıcılara empati göstermelidir. Kütüphane kullanıcıları da belgelenmemiş arayüzleri kullanmanın riskli olabileceğini anlamalı ve yazarlara empati göstermelidir

  • Go dilinde Hyrum's Law ve geriye dönük uyumluluk çok ciddiye alınır. Örneğin, GenerateKey fonksiyonunda algoritmanın sabitlenmemesi için MaybeReadByte kullanılır. ECDSA anahtarlarıyla ilgili sorunu çözmek için çalışılıyor. Map yineleme sırası, iç yapıyı açığa çıkarmamak için rastgeleleştirilir. rand.Rand çıktısı uyumluluk sözünün bir parçası kabul edilir ve iyileştirmek için büyük çaba harcanır. Belgelerde hangi sözlerin verileceği ve hangi davranışların reddedileceği her zaman tartışılır

  • Belirli sorunlar için çözüm olarak, string tabanlı hatalar yerine sentinel hataların kullanılması önerilir. API kullanıcılarının teknik olmayan string'lere bağımlı hale gelmemesi için önceden tanımlanmış hata değerleri, tipler veya sabitler kullanılmalıdır. Hyrum's Law vardır, ancak etkisi azaltılabilir

  • Hyrum's Law'a karşı bir yöntem de rastgelelik eklemektir. QUIC protokolü, yönlendiricilerin paketleri tanımlamaya bağımlı kalmaması için kullanılmayan alanları rastgele değerlerle doldurur. Buna "greasing" denir ve "ossification"ı önler

  • Golang tasarımcıları exception istemiyordu, ancak biçimsel olmayan hatalar sorun yaratıyor. Pattern matching olmadan biçimlendirilmiş hataların nasıl ele alınacağına dair tartışmaya ihtiyaç var

  • Bir iş yerinde hata mesajındaki bir yazım hatasını fark edip düzelttim, ancak o yazım hatasına bağımlı bağımlılıklar o kadar derindi ki düzeltmeyi sürdüremeyip eski haline geri almak zorunda kaldık

  • Go'nun hataları enum tipine dönüştürülebilirdi, ancak string tip olarak kullanıldı ve kullanıcıların buna nasıl bağımlı olacağı öngörülemedi. Bu, daha iyi alternatifler olmasına rağmen geçmişten kalan bir tasarım kararı

  • Hyrum's Law, Robustness Principle/Postel's Law'un tam tersidir. Kabul edilen şeylerde esnek olunacaksa, bunun nasıl olduğunun anlaşılması ve belgelenmesi gerekir. API'nin kabul ettikleri konusunda esnek olmamasını sağlamaya çalışıyorum

  • Hyrum's Law testlerde sıkça ortaya çıkar. Garanti edilmeyen davranışlara dair varsayımlar yüzünden çeşitli test türleri bozulur. Örneğin Hashmap eleman sırasının değişmesi, hata mesajlarının değişmesi, artık yılın ele alınış biçiminin değişmesi gibi

  • Bazı paket yazarları Hyrum's Law'ı daha fazla kabullenebiliyor. json paketinin yorumlarında, bunun iç ayrıntı olmasına rağmen yaygın kullanılan bazı paketlerin buna linkname üzerinden eriştiğinin fark edildiği belirtiliyor