Ví dụ áp dụng Định luật Hyrum trong Golang

• Định luật Hyrum và Golang

  • Gần đây, trong lúc khám phá Gocodebase, tác giả đã phát hiện một chú thích thú vị
  • Ví dụ về đoạn mã có chú thích: "Không thể thay đổi văn bản này vì Định luật Hyrum"
  • Phương thức Error() của cấu trúc MaxBytesError trả về thông báo lỗi "http: request body too large"

• Định luật Hyrum

  • Một nguyên tắc được đặt theo tên của Hyrum Wright, kỹ sư phần mềm tại Google
  • Khi có nhiều người dùng sử dụng một API, mọi hành vi có thể quan sát được của hệ thống sẽ bị ai đó phụ thuộc vào
  • Mọi hành vi có thể quan sát được trong mã, dù là có chủ ý hay vô tình, cuối cùng cũng sẽ có người phụ thuộc vào
  • Giải thích vì sao việc thay đổi thông báo lỗi có thể làm hỏng mã hiện có

• Các trường hợp trong Golang

  • Cũng tìm thấy các chú thích nhắc đến Định luật Hyrum trong các gói crypto/rsa và internal/weak
  • Ví dụ chú thích trong crypto/rsa/rsa.go và crypto/rsa/pss.go
  • Ví dụ chú thích trong gói internal/weak

• Quan sát

  • Đây không phải hiện tượng chỉ giới hạn ở Golang
  • Có thể quan sát hiện tượng tương tự trong quá trình tiến hóa của JavaScript
  • Hiện tượng này được gọi là Định luật Hyrum

• Suy nghĩ cuối cùng

  • Nhắc nhở rằng cần thận trọng khi thay đổi mã mà người khác có thể đang phụ thuộc vào
  • Điều quan trọng là thiết kế hệ thống sao cho các hành vi ngoài ý muốn không bị phụ thuộc vào
  • Cần nhớ rằng những thay đổi nhỏ cũng có thể tạo ra tác động lớn

[GN⁺]

Ý kiến trên Hacker News

• Hyrum's Law là một quan sát hữu ích, nhưng cần cẩn thận để không rút ra kết luận sai. Tổng thời gian thực thi của một hàm cũng là một thuộc tính có thể quan sát được, nên việc tối ưu hóa hàm để chạy nhanh hơn có thể tốt cho 99.99999999% người dùng, nhưng vẫn có thể trở thành một thay đổi gây vỡ tương thích. Vì vậy, cần hiểu rằng "thay đổi gây vỡ" là một khế ước xã hội chứ không phải khế ước kỹ thuật. Tác giả thư viện nên ghi rõ phần nào của API sẽ không thay đổi và cần đồng cảm với người dùng. Người dùng thư viện cũng nên hiểu rằng việc sử dụng các giao diện không được tài liệu hóa có thể tiềm ẩn rủi ro, và cần đồng cảm với tác giả

• Trong ngôn ngữ Go, Hyrum's Law và khả năng tương thích ngược được xem trọng rất cao. Ví dụ, trong hàm GenerateKey có dùng MaybeReadByte để thuật toán không bị cố định. Họ cũng đang nỗ lực giải quyết các vấn đề của khóa ECDSA. Thứ tự lặp của map được đặt ngẫu nhiên để tránh lộ chi tiết nội bộ. Đầu ra của rand.Rand được xem là một phần của cam kết tương thích nên đã phải bỏ ra rất nhiều công sức để cải thiện. Họ luôn thảo luận về việc nên hứa điều gì trong tài liệu và nên phủ nhận hành vi nào

• Một giải pháp được khuyến nghị cho một số vấn đề cụ thể là dùng sentinel error thay vì lỗi dựa trên chuỗi. Nên dùng các giá trị lỗi, kiểu hoặc hằng số được định nghĩa sẵn để người dùng API không phụ thuộc vào các chuỗi không mang tính kỹ thuật. Hyrum's Law là có thật, nhưng vẫn có thể giảm nhẹ tác động của nó

• Một cách chống lại Hyrum's Law là thêm tính ngẫu nhiên. Giao thức QUIC đặt các trường không sử dụng thành giá trị ngẫu nhiên để router không phụ thuộc vào đó để nhận diện gói tin. Cách này được gọi là "greasing" nhằm ngăn hiện tượng "ossification"

• Những người thiết kế Golang không muốn có exception, nhưng lỗi phi hình thức lại là một vấn đề. Cần có thêm thảo luận về cách xử lý lỗi có cấu trúc mà không cần pattern matching

• Có người kể rằng từng phát hiện và sửa một lỗi chính tả trong thông báo lỗi ở nơi làm việc, nhưng vì có phụ thuộc quá sâu vào chính lỗi chính tả đó nên cuối cùng không thể sửa và phải hoàn tác về trạng thái ban đầu

• Lỗi trong Go lẽ ra có thể được đổi sang kiểu enum, nhưng lại dùng chuỗi làm kiểu nên không thể biết người dùng sẽ phụ thuộc vào nó như thế nào. Đây là một quyết định thiết kế cũ dù đã có các lựa chọn tốt hơn

• Hyrum's Law hoàn toàn đối lập với Robustness Principle/Postel's Law. Nếu bạn dễ dãi trong những gì mình chấp nhận, bạn phải hiểu và tài liệu hóa cách đó. Mọi người cố thiết kế API để nó không quá dễ dãi trong những gì nó chấp nhận

• Hyrum's Law xuất hiện rất thường xuyên trong kiểm thử. Nhiều loại test bị hỏng vì giả định về những hành vi không được đảm bảo. Ví dụ như thay đổi thứ tự phần tử trong Hashmap, thay đổi thông báo lỗi, hoặc thay đổi cách xử lý năm nhuận

• Một số tác giả package có thể chấp nhận Hyrum's Law hơn. Trong chú thích của package json, có đề cập rằng đây là chi tiết nội bộ, nhưng họ phát hiện một package được dùng rộng rãi đang truy cập nó thông qua linkname