-
Hyrum's Law dan Golang
- Saat baru-baru ini menjelajahi Gocodebase, ditemukan komentar yang menarik
- Contoh kode dengan komentar "teks ini tidak bisa diubah karena Hyrum's Law"
- Metode
Error() pada struct MaxBytesError mengembalikan pesan error "http: request body too large"
-
Hyrum's Law
- Prinsip yang dinamai dari Hyrum Wright, seorang software engineer Google
- Jika banyak pengguna memakai sebuah API, semua perilaku sistem yang dapat diamati akan diandalkan oleh seseorang
- Semua perilaku yang dapat diamati dalam kode, baik disengaja maupun tidak sengaja, pada akhirnya akan diandalkan oleh seseorang
- Menjelaskan mengapa mengubah pesan error dapat merusak kode yang sudah ada
-
Contoh di Golang
- Komentar yang menyebut Hyrum's Law juga ditemukan di paket
crypto/rsa dan internal/weak
- Contoh komentar di
crypto/rsa/rsa.go dan crypto/rsa/pss.go
- Contoh komentar di paket
internal/weak
-
Pengamatan
- Ini tidak terbatas hanya pada Golang
- Fenomena serupa juga dapat diamati dalam proses evolusi JavaScript
- Fenomena ini disebut Hyrum's Law
-
Pemikiran akhir
- Mengingatkan bahwa kita harus berhati-hati saat mengubah kode yang bisa diandalkan orang lain
- Penting untuk merancang sistem agar perilaku yang tidak disengaja tidak menjadi sesuatu yang diandalkan
- Perlu diingat bahwa perubahan kecil bisa berdampak besar
1 komentar
Komentar Hacker News
Hyrum's Law adalah observasi yang berguna, tetapi kita perlu berhati-hati agar tidak menarik kesimpulan yang keliru. Total waktu eksekusi sebuah fungsi juga merupakan properti yang dapat diamati, jadi mengoptimalkan fungsi agar lebih cepat mungkin baik bagi 99.99999999% pengguna, tetapi itu juga bisa menjadi perubahan yang merusak. Karena itu, penting untuk memahami bahwa "perubahan yang merusak" adalah kontrak sosial, bukan kontrak teknis. Penulis library harus mendokumentasikan bagian API mana yang tidak akan berubah dan berempati kepada pengguna. Pengguna library juga harus memahami bahwa memakai antarmuka yang tidak didokumentasikan bisa berisiko, dan perlu berempati kepada pembuatnya
Dalam bahasa Go, Hyrum's Law dan kompatibilitas mundur dipandang sangat penting. Misalnya, fungsi GenerateKey menggunakan MaybeReadByte agar algoritmenya tidak terkunci. Mereka juga berupaya mengatasi masalah pada kunci ECDSA. Urutan iterasi map dibuat acak agar detail internal tidak terekspos. Output dari rand.Rand dianggap sebagai bagian dari janji kompatibilitas, sehingga banyak upaya dilakukan untuk memperbaikinya. Selalu ada diskusi tentang janji apa yang sebaiknya dinyatakan dalam dokumentasi, dan perilaku apa yang sebaiknya disangkal
Sebagai solusi untuk masalah tertentu, disarankan memakai sentinel error alih-alih error berbasis string. Gunakan nilai error, tipe, atau konstanta yang telah ditentukan sebelumnya agar pengguna API tidak bergantung pada string nonteknis. Hyrum's Law tetap ada, tetapi dampaknya bisa dikurangi
Salah satu cara melawan Hyrum's Law adalah menambahkan unsur acak. Protokol QUIC menetapkan field yang tidak digunakan ke nilai acak agar router tidak bergantung padanya untuk mengidentifikasi paket. Ini disebut "greasing" dan bertujuan mencegah "ossification"
Perancang Golang tidak menginginkan exception, tetapi error yang tidak formal juga bermasalah. Perlu ada diskusi tentang cara menangani error yang terstruktur tanpa pattern matching
Seseorang pernah menemukan dan memperbaiki salah ketik pada pesan error di tempat kerjanya, tetapi karena ada dependensi yang terlalu dalam bergantung pada salah ketik tersebut, perbaikannya tidak bisa dipertahankan dan akhirnya harus dikembalikan seperti semula
Error di Go sebenarnya bisa saja diubah menjadi tipe enum, tetapi karena string dipakai sebagai tipe, kita tidak tahu bagaimana pengguna akan bergantung padanya. Ini adalah keputusan desain lama meskipun ada alternatif yang lebih baik
Hyrum's Law adalah kebalikan total dari Robustness Principle/Postel's Law. Jika kita longgar terhadap apa yang diterima, kita harus memahami caranya dan mendokumentasikannya. Karena itu, API sebaiknya dirancang agar tidak terlalu longgar terhadap apa yang diterima
Hyrum's Law sering muncul dalam pengujian. Berbagai jenis test rusak karena asumsi terhadap perilaku yang tidak dijamin. Contohnya termasuk perubahan urutan elemen pada Hashmap, perubahan pesan error, atau perubahan cara menangani tahun kabisat
Beberapa penulis package mungkin lebih menerima Hyrum's Law. Dalam komentar pada package
json, ditemukan bahwa meskipun itu detail internal, package yang digunakan secara luas tetap mengaksesnya melalui linkname