Thời đại mà mã kiểm thử trở thành hào lũy (Moat) mới
(saewitz.com)-
Nghịch lý của thành công: dự án càng phát triển thì càng phải gánh nặng tương thích ngược và một codebase khổng lồ (The Ship of Theseus). Trong khi đó, đối thủ có thể cho AI học đặc tả API, tài liệu và mã kiểm thử của dự án hiện có, rồi gần như ngay lập tức tạo ra một “phiên bản nhẹ hơn và hiện đại hơn” chỉ giữ lại giá trị cốt lõi.
-
Trường hợp Cloudflare vs Vercel: Cloudflare đã tận dụng bộ tài liệu đồ sộ và test suite của Next.js mà Vercel tích lũy suốt nhiều năm để xây dựng một runtime tương thích Next.js mảnh gọn dựa trên Vite chỉ trong đúng một tuần. (Hiện cũng đã được áp dụng trên trang web chính phủ Mỹ cio.gov)
-
Mã kiểm thử chính là tài sản: trước đây bản thân mã nguồn là thứ quan trọng, nhưng giờ đây “hợp đồng phần mềm (Contract)” và “test case” mới là tài sản đắt giá nhất. Công khai chúng chẳng khác nào cung cấp cho đối thủ bản thiết kế chính xác để sao chép nguyên xi dịch vụ của tôi.
-
Tầm nhìn xa của SQLite: SQLite công khai mã nguồn nhưng giữ kín bộ test suite khổng lồ gấp 590 lần mã nguồn (92 triệu dòng). Đây đã trở thành “hào lũy” giúp họ vừa duy trì hệ sinh thái mã nguồn mở vừa có năng lực phòng thủ thương mại.
-
Kết luận: trong thời đại AI, các công ty mã nguồn mở mang tính thương mại đang đối mặt với thời điểm phải đưa ra quyết định giữa “chủ nghĩa vị tha hoàn toàn (mã nguồn mở)” và “sự sống còn của doanh nghiệp”. Có vẻ trong tương lai, nhiều dự án sẽ giống SQLite, chuyển mã kiểm thử sang trạng thái không công khai để xây dựng rào cản kỹ thuật riêng.
19 bình luận
Theo góc nhìn này, có lẽ những tài liệu như ADR(Architecture Decision Records) hay CIR(Change Intent Records) thậm chí sẽ được coi trọng hơn cả chính mã nguồn.
Khá ấn tượng. Dù là một bài viết ngắn nhưng vẫn khiến người đọc hiểu ngay. Có lẽ bảo mật của mã kiểm thử thậm chí còn có thể quan trọng hơn cả mã nguồn.
Với tôi thì nghe như đang nói rằng đừng bỏ qua bài kiểm thử e2e, không biết mọi người khác nghĩ thế nào?
Tôi hoàn toàn không phải dân phát triển... chỉ vì thấy thú vị khi vọc AI nên thử bắt nó code chút chút, vậy mà nó cứ tự tạo ra một đống test code dù tôi không hề yêu cầu rồi còn lưu lại, hóa ra là vì lý do này. Tôi hỏi rốt cuộc cái này cần để làm gì thì nó bảo là cần khi tự viết code, nên đừng xóa đi.
Ồ... có vẻ đúng thật.
Cách tiếp cận của SQLite thực sự rất ấn tượng. Việc giữ kín bộ test có quy mô gấp 590 lần mã nguồn cuối cùng cho thấy rằng “giá trị thực sự của phần mềm nằm ở đặc tả hành vi”.
Thực tế, dạo gần đây khi thử xây dựng dự án bằng các công cụ AI coding, chỉ cần có README + tài liệu API + mã test của một dự án hiện có là đã có thể sao chép các tính năng cốt lõi với tốc độ đáng kinh ngạc. Đây là điều tôi cảm nhận được khi trực tiếp vận hành 7 dự án; trớ trêu thay, những dự án có test càng tốt thì lại càng dễ bị sao chép.
Tuy nhiên, có một điểm bị bỏ qua trong trường hợp Cloudflare vs Vercel, đó là “sao chép” và “vận hành” là hai vấn đề hoàn toàn khác nhau. Để tái hiện được cả các edge case của Next.js, hệ sinh thái plugin, lẫn mức độ phụ thuộc vào cộng đồng thì chỉ mã test thôi là không đủ. Cuối cùng, có lẽ hào lũy thực sự là sự kết hợp giữa mã test + cộng đồng + kinh nghiệm vận hành.
Là một lập trình viên solo đang vận hành 7 dự án, tôi thấy bài viết này thực sự chạm đúng nỗi đau.
Nhờ các công cụ AI coding, tốc độ phát triển ban đầu đã tăng nhanh đến mức điên rồ, nhưng rồi đống mã được chồng lên quá nhanh mà không có test cuối cùng lại biến thành địa ngục refactor. Đặc biệt, khi phải vận hành nhiều dịch vụ cùng lúc, với những dự án không có test, mỗi lần chạm vào một tính năng là lại sợ chỗ khác phát nổ, đến mức ngại không dám động vào.
Phép so sánh "test = hào lũy" thực sự rất chính xác. Đối thủ có thể sao chép code, nhưng rất khó để sao chép cả một test suite bao phủ hàng nghìn edge case. Nhất là khi AI làm rất tốt việc sinh code, nhưng để tạo ra các kịch bản test thực sự có ý nghĩa thì đó vẫn là lĩnh vực đòi hỏi kiến thức miền từ con người.
Nhưng tùy lĩnh vực mà cũng có trường hợp mã kiểm thử gần như không có độ bao phủ, nên đúng là cũng khá phải cân nhắc. Có lẽ bên đó vẫn chưa làm ra được mã tốt bằng các lĩnh vực khác.
Bạn có thể cho biết đó là lĩnh vực nào không? (Không phải để tranh cãi đâu, tôi thực sự chỉ tò mò thôi.)
Lĩnh vực tôi làm cũng không đến mức cực đoan như vậy, nhưng tôi đang nghiên cứu và phát triển trong lĩnh vực AI.
Ngoài các framework thường được dùng phổ biến, cũng có những trường hợp môi trường đích để triển khai mô hình thực tế khác với môi trường đã dùng khi huấn luyện.
Cũng có khi một số operation nhất định không được hỗ trợ, nên phải tạo custom operation theo từng nền tảng. Trong trường hợp này, nhiều khi cũng không thể kiểm thử ngay trên môi trường đã phát triển.
Đôi khi cũng có trường hợp tự thiết kế mô hình trực tiếp; tuy có thể viết mã kiểm thử bằng một số dữ liệu nhất định, nhưng tùy theo dataset mà các giá trị thay đổi theo xác suất, hoặc xuất hiện hiện tượng giá trị bùng nổ tại một thời điểm nào đó, nên rất khó bao quát bằng mã kiểm thử.
Có lẽ còn khá nhiều môi trường mà việc kiểm thử còn khó hơn cả trường hợp của tôi.
Đây chỉ đơn giản là suy nghĩ của tôi thôi, nhưng có lẽ đó sẽ là những lĩnh vực như dùng Notebook rất nhiều, hoặc lĩnh vực AI nơi câu trả lời mang tính xác suất... hay mảng client game chẳng hạn.
Điều này tôi cũng hay nói với mọi người xung quanh, nhưng rốt cuộc về sau sẽ rất khó để xem xét toàn bộ mã nguồn, nên tôi nghĩ rằng nếu không kiểm thử những logic thực sự quan trọng thì chắc chắn sẽ xảy ra vấn đề lớn.
Phần cuối bài cũng có bổ sung, rằng đã có nhắc đến việc tldraw cũng chạy test ở chế độ không công khai (hóa ra là đùa thôi).
https://github.com/tldraw/tldraw/issues/8082
Nếu xem SQLite được kiểm thử như thế nào thì
SQLite hoàn toàn công khai, nhưng có lượng mã kiểm thử nhiều gấp 590 lần mã nguồn, và phần này hoàn toàn không công khai.
Có 100% độ bao phủ nhánh, hàng triệu test case, và thực hiện hơn 1 tỷ bài kiểm thử đột biến.
Vào đọc trong phần thảo luận thì hóa ra họ bảo là "đùa thôi".
Có vẻ đó là một bài test mang tính đùa cợt.
Ồ, ra là vậy. Tôi chỉ nhìn phần phía trên thôi haha
Cốt lõi là “test quan trọng hơn source” quả thực nghe rất đúng. Tuy vậy, tôi không chắc chiến lược chỉ open source mà không open test có còn hiệu quả hay không. Có vẻ việc rút ra các hạng mục kiểm thử từ source cũng là thứ họ sẽ làm khá tốt..
Họ làm sai mà.
Cloudflare, AI로 Next.js를 1주일 만에 Vite로 재구현한 vinext 공개
Có vẻ như điều này có liên quan đến bài viết kia. Khi làm mã nguồn mở, có lẽ giờ đây chúng ta cũng sẽ cần thận trọng hơn trong việc công khai mã kiểm thử.