Rà soát mã do AI tạo ra không nhất thiết phải bắt đầu bằng việc đọc từng dòng. Người rà soát có thể bắt đầu từ ý định, tiêu chí chấp nhận và các quyết định kỹ thuật. Sau đó, họ chỉ mở mã khi cần xác minh hành vi hoặc rủi ro cụ thể. Tác giả bài viết “review decisions, not code” trên The New Stack cho biết Aviator thiết kế khung rà soát theo nguyên tắc: tác tử xác minh, còn con người quyết định và chịu trách nhiệm.
Báo cáo của Faros AI ghi nhận mức tăng 76,3% về số yêu cầu hợp nhất mã được hợp nhất mà không qua rà soát. Con số này được so với báo cáo trước vào tháng 4. Cũng theo nguồn này, nhiều công ty dùng AI để rà soát từ 50% đến 80% số yêu cầu hợp nhất mã. AI đã nhận phần lớn việc tìm lỗi, nhưng chưa thay thế được cuộc trao đổi về nhóm đã quyết định điều gì và vì sao.
Sự thay đổi này diễn ra trong bối cảnh AI đang làm thay đổi hoạt động rà soát mã. Chuyển toàn bộ công việc sang công cụ có thể giúp nhóm tiết kiệm thời gian đọc. Tuy nhiên, nhóm cũng có thể mất đi nơi từng giúp kỹ sư xây dựng cách hiểu chung về hệ thống.
Phần AI chưa giải quyết được
AI có thể kiểm tra mã theo các quy tắc nhất quán, nhưng không tự xác định một tính năng có nên được xây dựng hay ai phải chịu trách nhiệm về kết quả. Phần còn thiếu là bối cảnh quyết định: những phương án đã được cân nhắc, rủi ro được chấp nhận và người đồng ý với lựa chọn cuối cùng.
Hai cách rà soát đều có giới hạn
Đa số nhóm phát triển đang mắc kẹt giữa hai cách làm. Đọc từng dòng khiến người rà soát trở thành nút thắt. Chấp thuận gần như tự động lại khiến nhóm dần mất dấu thay đổi đã diễn ra và lý do đằng sau nó.
AI làm tốt phần việc có tính cơ học. Công cụ không mệt, có thể đọc mọi dòng và áp dụng cùng một tiêu chuẩn cho mọi yêu cầu hợp nhất mã. Tuy nhiên, AI không chứng kiến đầy đủ quá trình ra quyết định, không thể tự kết luận rằng một tính năng không nên được xây dựng và không thể chịu trách nhiệm về kết quả.
Một mô hình mạnh hơn không tự động khắc phục điểm yếu này vì công cụ vẫn đang đọc sai loại thông tin vào sai thời điểm. Mã nguồn cho biết hệ thống được triển khai như thế nào, nhưng không luôn cho biết những phương án nào đã được cân nhắc, rủi ro nào được chấp nhận và ai đồng ý với lựa chọn cuối cùng.
Cuộc trao đổi vẫn cần con người
Trước đây, buổi rà soát mã là thời điểm được lên lịch để kỹ sư trao đổi về hệ thống. Khi giao toàn bộ bước này cho AI, nhóm cũng có thể vô tình bỏ luôn cuộc trao đổi đó. Rủi ro này tăng lên khi tác tử AI lập trình tham gia sâu hơn vào quy trình phát triển.
Rà soát quyết định thay cho đọc từng dòng mã
Rà soát quyết định chuyển sự chú ý từ phần chênh lệch mã sang các lựa chọn đã định hình thay đổi. Nhóm xem xét ý định, tiêu chí chấp nhận, phương án bị bác bỏ, rủi ro được chấp nhận và người phê duyệt. Mã nguồn vẫn được dùng làm bằng chứng khi một quyết định cần được kiểm tra chi tiết.
Một quyết định xuất hiện ở bất kỳ điểm nào mà thay đổi có thể đi theo hướng khác. Nhóm có thể chọn cơ chế thùng thẻ thay cho cửa sổ trượt. Họ cũng có thể để hệ thống tiếp tục hoạt động khi thành phần phụ gặp lỗi, hoặc dùng một giới hạn chung cho mọi khách hàng. Yêu cầu hợp nhất mã do AI viết có nhiều lựa chọn như vậy, nhưng phần chênh lệch mã hiếm khi thể hiện đầy đủ chúng.
Năm lớp của khung rà soát
Khung rà soát được trình bày trong bài của The New Stack gồm năm lớp:
- Phản biện diễn ra trước khi yêu cầu hợp nhất mã được tạo, khi một tác tử thứ hai dùng mô hình khác xem xét cách tiếp cận của tác tử lập trình. Kết quả ghi lại phương án được đề xuất, phương án bị bác bỏ, lý do và bên đã thay đổi quan điểm. Những điểm cả hai đồng ý vẫn phải được lưu vì hai tác tử cũng có thể cùng bỏ qua một vấn đề.
- Ghi nhận bao gồm ý định giải thích vì sao cần thay đổi và tiêu chí chấp nhận mô tả hệ thống phải hoạt động thế nào. Cả hai được rút ra từ phiên làm việc với tác tử và đưa vào yêu cầu hợp nhất mã. Thiếu tiêu chí thì không thể kiểm tra ý định; thiếu ý định thì khó đánh giá tiêu chí.
- Chuẩn hóa chuyển những nhận xét lặp lại thành quy tắc cố định để kiểm tra trên mọi thay đổi, chẳng hạn yêu cầu dùng kiểu dữ liệu tiền tệ thay cho số dấu phẩy động.
- Tranh luận là lúc con người thảo luận về các quyết định mà tác tử phát hiện nhưng không thể tự giải quyết. Máy tiếp tục kiểm tra từng dòng, còn nhóm tập trung vào câu hỏi liệu mình có đang xây đúng thứ cần xây hay không.
- Chịu trách nhiệm đòi hỏi một nhóm có tên cụ thể quản lý các quy tắc, duy trì cách hiểu về hệ thống và phê duyệt thay đổi. Mô hình không có uy tín nghề nghiệp và cũng không thể bị yêu cầu chịu trách nhiệm sau sự cố.
Phần việc của máy và con người
Ba lớp đầu có thể giao cho máy và hiện đã có công cụ thực hiện. Hai lớp cuối thuộc về con người. Trong đó, tranh luận là mắt xích dễ mất nhất khi nhóm chuyển thẳng từ rà soát thủ công sang rà soát bằng AI.
Nguyên tắc cốt lõi là tác tử xác minh, con người quyết định. Con người cân nhắc đánh đổi, đánh giá rủi ro và đứng tên cho quyết định. Các lựa chọn lặp lại nhiều lần có thể trở thành quy tắc để tác tử áp dụng trong những lần sau.
Vì sao chỉ rà soát đặc tả vẫn chưa đủ
Đặc tả mô tả yêu cầu trước khi triển khai, còn quyết định xuất hiện trong lúc kỹ sư và tác tử giải quyết vấn đề. Vì quá trình triển khai có thể tạo ra thông tin mới, chỉ đọc đặc tả sẽ bỏ sót các phương án, đánh đổi và rủi ro được phát hiện sau khi công việc bắt đầu.
Một phản biện đối với cách làm này là nó chỉ chuyển việc đọc từ mã nguồn sang đặc tả. Tuy nhiên, đặc tả thường được viết trước khi quá trình triển khai tạo ra thông tin mới. Đặc tả cần thời gian chuẩn bị và có thể lệch khỏi thực tế ngay khi công việc bắt đầu.
Quyết định xuất hiện trực tiếp trong quá trình làm việc. Mỗi quyết định thường ngắn và chỉ tồn tại vì thay đổi có thể được thực hiện theo một hướng khác. Vì thế, ý định cùng tiêu chí chấp nhận nên được rút ra từ phiên lập trình sau khi công việc đã làm rõ vấn đề, thay vì buộc kỹ sư viết toàn bộ từ đầu.
Cách tiếp cận này không phủ nhận giá trị của đặc tả. Nó tập trung vào phần thông tin phát sinh khi tác tử và kỹ sư thật sự giải quyết bài toán, vốn là phần dễ biến mất nhất sau khi yêu cầu hợp nhất mã được gửi đi.
Quyết định được lấy từ đâu
Các quyết định có thể được lấy từ phiên làm việc giữa kỹ sư và tác tử lập trình, sau đó bổ sung bằng một lượt phản biện trước khi gửi yêu cầu hợp nhất mã. Hồ sơ cần giữ lại ý định, tiêu chí chấp nhận, lựa chọn của kỹ sư, điểm bất đồng giữa các tác tử và những vấn đề chưa được giải quyết.
Phần lớn quyết định đã diễn ra trên máy của người viết mã nhưng thường không được lưu lại. Hai cơ chế có thể giữ chúng trong hồ sơ rà soát:
- Một kỹ năng ghi nhận rút ra ý định, tiêu chí chấp nhận và quyết định từ phiên làm việc với tác tử lập trình. Mỗi lần tác tử dừng để hỏi và kỹ sư đưa ra lựa chọn, hệ thống lưu lựa chọn đó.
- Một kỹ năng rà soát chạy tác tử phản biện trước khi yêu cầu hợp nhất mã được gửi. Nó ghi lại điểm bất đồng, cách hai bên giải quyết và những vấn đề chưa thể thống nhất để nhóm tiếp tục tranh luận.
Hồ sơ này bổ sung lớp bối cảnh mà phần chênh lệch mã không thể hiện. Nó cũng hỗ trợ cách làm đặt xác minh làm trọng tâm, tương tự vấn đề được nêu trong bài xác minh 2.000 yêu cầu hợp nhất mã mỗi tháng.
Nội dung của một quyết định trong thực tế
Một quyết định có thể ghi rõ mục tiêu, phương án đã chọn, phương án bị bác bỏ, bằng chứng thử nghiệm, rủi ro được chấp nhận và việc cần làm tiếp theo. Ví dụ của Aviator cho thấy sáu quyết định có thể đi cùng một thay đổi giới hạn tốc độ, thay vì bị ẩn trong phần chênh lệch mã.
Ví dụ của Aviator là một yêu cầu hợp nhất mã bổ sung giới hạn tốc độ theo từng bản cài đặt cho luồng tiếp nhận webhook. Ý định được viết trong một câu: hạn chế các đợt webhook tăng vọt theo từng bản cài đặt GitHub để một khách hàng tạo nhiều lưu lượng không làm nghẽn bộ môi giới, đồng thời không làm mất sự kiện hoặc phá vỡ thứ tự của chúng.
Sáu quyết định đi cùng thay đổi
Yêu cầu hợp nhất mã này mang theo sáu quyết định. Một quyết định còn mở thuộc về sản phẩm: giới hạn lưu lượng đột biến sẽ dùng cùng một giá trị cho mọi khách hàng. Hai rủi ro đã được chấp nhận. Hệ thống vẫn tiếp tục khi Redis ngừng hoạt động, còn các sự kiện bị hoãn vẫn giữ nội dung trong bộ môi giới. Việc hiển thị chỉ số của bộ giới hạn trên bảng Grafana triển khai tại chỗ được chuyển thành công việc tiếp theo có phiếu liên kết. Hai quyết định còn lại đã được tác giả, người rà soát và các tác tử tranh luận rồi thống nhất.
Một lựa chọn đã chốt là dùng cơ chế thùng thẻ thay cho cửa sổ trượt. Tác tử của tác giả giải thích rằng phương án này cần một lần gọi Lua cho mỗi sự kiện thay vì quét tập hợp có thứ tự. Lựa chọn được đưa ra sau khi chạy thử lại một đợt webhook tăng mạnh. Người rà soát có thể phản biện ngay trong luồng thảo luận hoặc hỏi trực tiếp tác tử.
Những thông tin đó không xuất hiện trong phần chênh lệch mã. Chúng chỉ tồn tại nếu quy trình chủ động ghi lại lý do đằng sau cách triển khai.
Người rà soát cần làm gì
Người rà soát cần đọc ý định và mô tả thay đổi, kiểm tra từng quyết định, rồi xem các mục chưa đạt trước khi phê duyệt. Nếu bối cảnh không đủ hoặc một lựa chọn dẫn đến rủi ro cụ thể, người rà soát mở mã nguồn để xác minh thay vì mặc định đọc toàn bộ phần chênh lệch.
Vai trò của người rà soát được thu gọn còn ba bước:
- Đọc ý định và phần mô tả thay đổi.
- Xem từng quyết định, rồi phản biện những điểm không đồng ý.
- Kiểm tra các mục chưa đạt trước khi phê duyệt.
Ba bước này cho phép người rà soát hiểu thay đổi, xây dựng cách nhìn về hệ thống và tập trung vào những vấn đề cần phán đoán mà không phải đọc liên tục từng dòng.
Mỗi quyết định có một luồng thảo luận riêng, trong đó con người và tác tử được ghi nhãn khác nhau để nhóm biết ai đã đưa ra lựa chọn nào. Người rà soát có thể đồng ý, phản đối, thay thế quyết định hoặc chuyển nó thành công việc theo dõi. Mã nguồn vẫn có mặt và được mở khi một quyết định yêu cầu kiểm tra chi tiết. Nhận xét trực tiếp trên mã cũng được đưa vào cùng hồ sơ.
Việc không đọc từng dòng không đồng nghĩa với phê duyệt tự động. Rà soát quyết định vẫn đòi hỏi kỹ sư đặt câu hỏi, hiểu hậu quả và yêu cầu mở mã khi bối cảnh chưa đủ.
Điều gì xảy ra sau khi hợp nhất
Hồ sơ quyết định tiếp tục có giá trị sau khi mã được hợp nhất. Nhóm có thể dùng hồ sơ để theo dõi các thay đổi quan trọng, cung cấp trí nhớ cho tác tử, chuyển việc cần làm tiếp thành phiếu liên kết và chuẩn hóa những lựa chọn lặp lại thành quy tắc có người phê duyệt.
Các quyết định có thể tiếp tục phục vụ nhóm theo bốn cách:
- Theo dõi hoạt động của nhóm cho phép kỹ sư xem những quyết định quan trọng trong phần hệ thống mình phụ trách theo ngày hoặc theo tuần mà không cần đọc lại toàn bộ yêu cầu hợp nhất mã.
- Tạo trí nhớ cho tác tử giúp tác tử lập trình và tác tử rà soát lấy lại các quyết định trước đây liên quan đến phần mã chúng đang xử lý, nhờ đó không phải tranh luận lại những đánh đổi đã được giải quyết.
- Giữ công việc tiếp theo khỏi bị quên bằng cách chuyển việc cần làm sau thành phiếu liên kết thay vì để nó nằm trong phần mô tả ít người đọc lại.
- Biến mẫu lặp lại thành quy tắc bắt đầu khi cùng một quyết định liên tục xuất hiện và nhóm đề xuất nó thành quy tắc cố định. Quy tắc chỉ có hiệu lực sau khi được một người phê duyệt.
Cuối cùng vẫn phải có người ký tên. Mỗi quyết định được tranh luận cần kết thúc bằng một cá nhân có tên cụ thể xác nhận rằng họ đồng ý. Đây là điểm mà quá trình thảo luận chuyển thành trách nhiệm.
Từ đọc mã sang hiểu hệ thống
Rà soát quyết định thay đổi thứ tự kiểm tra chứ không loại bỏ mã nguồn. Người rà soát bắt đầu bằng mục tiêu, tiêu chí chấp nhận và các lựa chọn đã được đưa ra. Sau đó, mã trở thành bằng chứng để xác minh một quyết định cụ thể khi có rủi ro, kiểm tra tự động thất bại hoặc lời giải thích chưa đủ.
Thay vì bắt đầu bằng hàng trăm dòng chênh lệch rồi cố đoán ý định, người rà soát bắt đầu bằng mục tiêu, tiêu chí chấp nhận và các lựa chọn đã được đưa ra. Cách làm này giữ lại cuộc trao đổi kỹ thuật mà nhóm có thể mất khi AI đảm nhận phần kiểm tra cơ học.
Nếu AI đang rà soát phần lớn yêu cầu hợp nhất mã của nhóm, câu hỏi cần trả lời là: tuần trước nhóm đã quyết định điều gì và ai đã đồng ý với quyết định đó?
Hãy tiếp tục theo dõi Sine để cập nhật những cách tổ chức quy trình phát triển phù hợp khi AI ngày càng viết và rà soát nhiều mã hơn.
