Khi release v1.0.0-preview, phản ứng tự nhiên của tôi là muốn ăn mừng. Hơn 300 tests đều báo xanh. Trình biên dịch chạy native nhanh hơn nhiều so với bản JS. Mọi kịch bản demo đều trơn tru.
But kỷ luật của systems programming khuyên tôi nên nghi ngờ chính niềm vui đó. Một test suite do chính người viết compiler thiết kế luôn mang theo thiên kiến của họ: nó chỉ kiểm tra những kịch bản mà họ nghĩ là đúng, hoặc những lối sai mà họ đã biết cách sửa.
Sprint 107 bắt đầu Phase Q (Compiler Hardening). Việc đầu tiên chúng tôi làm là thiết lập một Blocker / Known-issues Database theo từng stage biên dịch. Thay vì giấu đi những hạt sỏi dưới thảm để làm đẹp slide thuyết trình, chúng tôi rà soát và ghi nhận mọi hành vi bất thường, mọi diagnostic span bị lệch chỉ số dòng, và mọi trường hợp compiler crash khi gặp code dị dạng của người dùng.
Tôi học được rằng: một test suite xanh chỉ chứng minh compiler chạy đúng trên những gì ta thiết lập để kiểm tra. Nó không chứng minh compiler sẽ không crash khi người dùng ngoài nhập sai cú pháp, hoặc cố tình viết các biểu thức cực đoan để khai thác lỗ hổng. Hardening không phải là viết thêm happy path; nó là quá trình đi tìm xem compiler sẽ vỡ ở đâu khi bị đánh phá dồn dập.
Mọi lỗi tìm thấy được phân loại rõ ràng: lỗi nào có owner để sửa ngay, lỗi nào được phép hoãn (defer) kèm lý do kỹ thuật chi tiết. Sự thành thật này bảo vệ dự án khỏi sự tự mãn nguy hiểm của một phiên bản preview, giữ cho đôi chân của chúng tôi luôn chạm mặt đất cứng.
Bình luận (0)
Đang tải bình luận...