Có những trường hợp chỉ thay đổi đôi chút thứ tự các giá trị trả về của một hàm thư viện hoặc câu chữ trong thông báo lỗi mà đã nhận được báo cáo rằng một dịch vụ ở rất xa đột nhiên gặp trục trặc. Dù tài liệu chưa từng cam kết những chi tiết ấy, vẫn có người đang dựa vào hành vi đó. Nhận xét tóm gọn thực tế này trong một câu chính là “Định luật Hyrum (Hyrum's Law)”.
Nói đơn giản, Định luật Hyrum là một quy luật kinh nghiệm trong kỹ nghệ phần mềm: “Khi có đủ nhiều người sử dụng một giao diện, những gì được cam kết trong tài liệu không còn quan trọng; mọi hành vi có thể quan sát được của hệ thống đều sẽ có người phụ thuộc vào”. Titus Winters đã đặt tên và phổ biến những quan sát của đồng nghiệp Hyrum Wright, người từng phụ trách các thay đổi mã nguồn quy mô lớn tại Google, dưới tên gọi “Định luật Hyrum”.
Tài liệu này sẽ lần lượt tìm hiểu ý nghĩa chính xác và nguồn gốc của Định luật Hyrum, cơ chế hình thành giao diện ngầm định, các ví dụ thường gặp trong thực tiễn phát triển, cùng những cách ứng phó và giới hạn của chúng.
Định luật Hyrum: Một hợp đồng vượt xa những gì ghi trong tài liệu
Định luật Hyrum là gì?
Định luật này thường được phát biểu như sau: nếu một giao diện lập trình ứng dụng (API) có đủ nhiều người dùng, thì bất kể hợp đồng ghi những gì, mọi hành vi có thể quan sát được mà hệ thống thể hiện đều sẽ có người phụ thuộc vào. Trong bài viết của mình, Wright ghi nhận công lao của Winters trong việc đặt tên cho nhận xét này là “Định luật Hyrum” và phổ biến nó rộng rãi.
Cùng với ý nghĩa đó, còn có cách gọi “Định luật giao diện ngầm định (Law of Implicit Interfaces)”. Điều này có nghĩa là khi số người dùng tăng lên, ngay cả những chi tiết triển khai được cho là nội bộ cũng trở thành hợp đồng trên thực tế; cuối cùng, chỉ cần thay đổi cách triển khai đôi chút cũng có thể bị yêu cầu bảo đảm “tính tương thích đến từng lỗi (bug-for-bug compatibility)”.
- Hợp đồng tường minh (Explicit Contract): Các điều kiện về đầu vào, đầu ra và lỗi được ghi trong tài liệu và đặc tả.
- Giao diện ngầm định (Implicit Interface): Những hành vi mà mọi người liên tục quan sát rồi dần kỳ vọng, dù không được ghi trong tài liệu.
- Hành vi có thể quan sát được (Observable Behavior): Mọi kết quả có thể kiểm chứng từ bên ngoài, như thứ tự phản hồi, độ trễ, câu chữ thông báo lỗi và định dạng nhật ký.
Cơ chế hình thành giao diện ngầm định
Định luật Hyrum mô tả một hiện tượng gần như tất yếu khi quy mô tăng lên, chứ không phải hệ quả của việc lập trình viên lười biếng. Bởi dù tin rằng đã dùng sự trừu tượng hóa để che giấu bên trong, từ bên ngoài vẫn có thể đọc được nhiều tín hiệu.
(1) Người dùng nhìn vào hành vi hơn là tài liệu
Trong lịch trình gấp gáp, người ta thường kiểm tra xem hệ thống có hoạt động như hôm qua hay không trước, thay vì đối chiếu từng dòng đặc tả. Vì thế, những chi tiết tình cờ có vẻ ổn định dần trở thành một “cam kết đương nhiên”.
(2) Mỗi bên phụ thuộc một kiểu, nhưng gộp lại là toàn bộ cách triển khai
Có nhóm dựa vào thứ tự sắp xếp, nhóm khác dựa vào chuỗi mã lỗi, còn nhóm khác nữa dựa vào thời gian phản hồi trung bình. Khi số người dùng tăng lên, tổng hợp các phụ thuộc ấy sẽ bao phủ gần như mọi khía cạnh của cách triển khai.
(3) Có liên hệ với sự trừu tượng hóa rò rỉ của Joel Spolsky
“Định luật về sự trừu tượng hóa rò rỉ (Law of Leaky Abstractions)” của Joel Spolsky cho rằng sự trừu tượng hóa không thể che giấu hoàn toàn những gì diễn ra bên trong. Định luật Hyrum bổ sung rằng khi có nhiều người dùng, ngay cả những dấu hiệu rò rỉ ấy cũng sẽ dần trở nên cố định như một hợp đồng.
Các ví dụ gặp trong thực tiễn phát triển
Nghe có vẻ lý thuyết, nhưng cùng một kiểu tình huống vẫn lặp lại trong công việc hằng ngày với thư viện và dịch vụ. Những thay đổi được cho là “nằm ngoài đặc tả” thường làm chao đảo cả những hệ thống ở xa nhất.
(1) Thứ tự của danh sách trả về
Dù tài liệu ghi rằng “không bảo đảm thứ tự”, nếu kết quả trước nay luôn xuất hiện theo cùng một thứ tự, mã nguồn dựa vào thứ tự ấy sẽ dần tích tụ. Một ngày nào đó, khi đưa xử lý song song vào khiến thứ tự thay đổi, những giả định chưa được kiểm thử sẽ đồng loạt lộ ra.
(2) Câu chữ trong thông báo lỗi và nhật ký
Có trường hợp một chương trình khác phân tích những câu vốn được viết cho con người đọc dưới dạng chuỗi ký tự để quyết định nhánh xử lý. Việc chỉ sửa câu chữ cho dễ hiểu hơn mà khiến quy trình tự động hóa dừng lại chính là tình huống thuộc loại này.
(3) Hiệu năng và thời gian xử lý
Dù đặc tả không cam kết độ trễ, tốc độ gần như không đổi suốt nhiều năm vẫn trở thành mức kỳ vọng trên thực tế. Nếu bỏ bộ nhớ đệm hoặc tăng các bước kiểm tra khiến hệ thống chậm đi đôi chút, các báo cáo kiểu “chức năng vẫn như cũ nhưng phía chúng tôi lại bị hết thời gian chờ” sẽ liên tiếp xuất hiện.
Cách ứng phó với Định luật Hyrum và những giới hạn
Định luật này không có nghĩa là phải từ bỏ thay đổi. Đúng hơn, nó là lời cảnh báo rằng cần chủ động chừa chỗ cho việc thay đổi, với tiền đề rằng bất kỳ khía cạnh nào có thể quan sát được cũng có thể trở thành hợp đồng.
- Làm rõ hợp đồng (Clear Contract): Dùng tài liệu và kiểm thử để phân định rõ những gì được bảo đảm và những gì không được bảo đảm.
- Chủ động tạo dao động (Intentional Jitter): Ngay từ đầu, xáo trộn thứ tự hoặc làm độ trễ dao động đôi chút để ngăn những giả định ngẫu nhiên hình thành và phát triển.
- Kiểm thử tính tương thích (Compatibility Testing): Trước những thay đổi quy mô lớn, chạy trên phạm vi rộng các mẫu gọi thực tế để tìm trước những điểm sẽ gặp trục trặc.
Tuy nhiên, khi có quá nhiều người dùng, bất kỳ chỉnh sửa nhỏ nào cũng có thể làm hỏng hoạt động của một bên nào đó. Cuốn Software Engineering at Google cũng xem định luật này như entropy: một ràng buộc không thể loại bỏ nhưng luôn phải tính đến trong thiết kế và bảo trì. Ngược lại, cũng cần cảnh giác với thái độ viện cớ định luật này để trì hoãn vô thời hạn những cải tiến cần thiết.
Định luật Hyrum nhắc chúng ta về thực tế rằng giao diện thực sự của một hệ thống phổ biến sâu rộng hơn rất nhiều so với những gì ghi trong tài liệu. Nhận xét ra đời từ kinh nghiệm thay đổi thư viện quy mô lớn của Google ngày nay đã trở thành ngôn ngữ chung của các nhóm muốn duy trì API và nền tảng lâu dài.
Trước khi sửa một hành vi nhỏ, hãy nghĩ thêm một lần rằng “dù không có trong tài liệu, liệu đã có ai đang quan sát nó hay chưa”. Đó là bước đầu tiên để vận dụng Định luật Hyrum vào việc thiết kế những thay đổi không gây hỏng hóc.
