Duyệt một phiên tác tử AI không giống đọc rà một đoạn mã: ngoài nội dung thay đổi, bạn còn phải xem tác tử đã chạy những lệnh gì, tạo thêm tệp nào, cài thêm gì và có chạm vào chỗ không được chạm không. Trình tự hợp lý là đi từ rộng đến hẹp: nhật ký hành động, danh sách tệp, phụ thuộc, kiểm thử, rồi mới đến từng dòng mã.
Bài này đưa ra một trình tự khoảng mười lăm phút cho một phiên cỡ vừa, kèm cách giữ lại phần tốt và bỏ phần không ưng mà không phải làm lại từ đầu. Phần dấu hiệu mã "trông đúng mà sai" và cách đọc rà chi tiết từng hàm nằm ở danh mục kiểm thử và rà soát của trang; ở đây tập trung vào những thứ riêng của tác tử.
Bắt đầu từ nhật ký hành động, không phải từ diff
Hầu hết công cụ tác tử đều giữ lại lịch sử phiên: tác tử đã đọc tệp nào, chạy lệnh nào, kết quả ra sao, sửa gì ở mỗi bước. Đọc lướt nhật ký này trước khi xem diff cho bạn bối cảnh: nó đã hiểu yêu cầu thế nào, có đi lạc rồi quay lại không, có lúc nào gặp lỗi rồi lách đi thay vì sửa không.
Có ba loại lệnh cần soi kỹ. Lệnh cài đặt hoặc gỡ gói, vì chúng đổi môi trường của bạn, không chỉ đổi mã. Lệnh xoá tệp hoặc thư mục, vì có thể xoá cả thứ không theo dõi trong git, mất là mất hẳn. Lệnh có tác dụng ra ngoài máy: gọi dịch vụ thật, chạy tệp chuyển đổi dữ liệu trên cơ sở dữ liệu dùng chung, đẩy mã lên kho từ xa. Nếu cài đặt quyền của bạn chặn đúng mấy loại này thì phần đọc nhật ký sẽ nhẹ hơn nhiều.
Một dấu hiệu nữa cần tìm trong nhật ký là những đoạn tác tử chạy kiểm thử thấy đỏ, rồi lần sửa ngay sau đó chạm vào tệp kiểm thử. Không phải lúc nào cũng sai, nhưng đó là nơi đáng xem đầu tiên khi sang phần đọc diff.
Nếu nhật ký quá dài, yêu cầu chính tác tử viết bản tóm tắt theo khung cố định trước khi kết thúc phiên: các lệnh đã chạy có tác dụng thay đổi, các gói đã cài, các tệp đã xoá, những lần kiểm thử thất bại và cách xử lý. Bản tóm tắt này không thay được việc bạn tự xem, nhưng giúp bạn biết nên mở nhật ký gốc ở đoạn nào.
Trình tự mười lăm phút cho một phiên cỡ vừa
Giả định tác tử làm trên nhánh riêng tách từ nhánh chính main, và bạn đang đứng trên nhánh đó.
- Chạy git status để thấy cả tệp đã sửa lẫn tệp mới chưa theo dõi. Tệp mới thường bị bỏ sót vì không hiện trong diff.
- Chạy git diff --stat main...HEAD cộng với phần chưa ghi nhận để thấy toàn cảnh số dòng thêm bớt ở từng tệp. Đánh dấu tệp nằm ngoài phạm vi phiếu việc.
- Mở tệp khai báo phụ thuộc và tệp khoá phiên bản. Có gói mới thì tra tên gói trên kho gói chính thức: có thật không, ai duy trì, cập nhật gần nhất khi nào.
- Mở các tệp kiểm thử đã đổi. Phân loại từng thay đổi: thêm kiểm thử mới, sửa kiểm thử cũ vì yêu cầu đổi, hay sửa kỳ vọng cho khớp với mã. Loại cuối cần lý do rõ.
- Đọc diff các tệp mã theo thứ tự quan trọng, bắt đầu từ chỗ xử lý tiền, quyền truy cập, dữ liệu người dùng.
- Tự chạy lại toàn bộ bộ kiểm thử và chạy thử tính năng bằng tay ít nhất một lần theo đường người dùng đi.
Nếu bước hai cho thấy tác tử đổi bốn mươi tệp cho một lỗi nhỏ, dừng lại ở đó. Phần lớn trường hợp là nó đã tiện tay định dạng lại hoặc đổi tên hàng loạt. Yêu cầu nó tách phần đó ra hoặc bỏ đi trước khi bạn đọc tiếp, vì đọc diff bốn mươi tệp thì không ai đọc kỹ được.
Giữ phần tốt, bỏ phần không ưng mà không làm lại từ đầu
Chọn từng khối thay đổi bằng git add -p. Lệnh này đi qua từng khối thay đổi và hỏi bạn có đưa vào lần ghi nhận hay không. Phần ưng thì chọn, phần không ưng thì để lại rồi bỏ bằng git restore kèm tên tệp. Cách này hợp khi tác tử làm đúng tám phần, sai hai phần.
Bỏ hẳn một tệp tác tử không nên đụng. Lệnh git restore --source=main [tệp] trả một tệp về đúng nội dung trên nhánh chính, kể cả khi thay đổi đã được ghi nhận trên nhánh. Sau đó ghi nhận lại để nhánh sạch.
Bỏ tệp mới không cần. Lệnh git clean -n chỉ liệt kê những tệp chưa theo dõi sẽ bị xoá, chưa xoá gì. Xem danh sách rồi mới chạy lại với tuỳ chọn xoá thật. Đừng chạy thẳng lệnh xoá khi chưa xem danh sách, vì tệp cấu hình cục bộ của bạn cũng có thể nằm trong đó.
Giao lại phần sai cho tác tử kèm lý do. Thay vì tự sửa, nói rõ khối nào không ưng và vì sao, rồi để tác tử làm lại đúng phần đó. Lý do bạn viết ra cũng là thứ đáng thêm vào tệp hướng dẫn dự án.
Bảng soát nhanh những thứ hay lọt khi duyệt phiên tác tử
Những mục dưới đây không lộ ra khi chỉ đọc diff các tệp mã chính, nhưng lại là nguồn sự cố hay gặp nhất sau khi gộp.
| Thứ cần soát | Vì sao hay lọt | Cách soát |
|---|---|---|
| Tệp nháp, tệp nhật ký, ảnh chụp kết quả | Tác tử tạo để thử rồi quên xoá | Xem danh sách tệp chưa theo dõi |
| Khoá bí mật trong mã hoặc tệp cấu hình | Tác tử chép giá trị từ tệp môi trường vào mã cho chạy được | Tìm chuỗi giống khoá trong diff; dùng công cụ quét bí mật nếu kho có |
| Kiểm thử bị đánh dấu bỏ qua | Cách nhanh nhất để bộ kiểm thử xanh | Tìm các từ khoá bỏ qua của khung kiểm thử trong diff |
| Chú thích tắt cảnh báo của trình kiểm tra mã | Cách nhanh nhất để hết cảnh báo | Tìm chú thích tắt cảnh báo mới thêm |
| Giá trị cứng thay cho cấu hình | Tác tử cố cho kiểm thử qua trên máy | Đọc kỹ hằng số mới: đường dẫn, địa chỉ, số cổng |
| Xử lý lỗi bị nuốt | Khối bắt lỗi rỗng làm lỗi biến mất khỏi kiểm thử | Tìm khối bắt lỗi mới không ghi nhật ký, không ném lại |
Bạn có thể giao chính bảng này cho một phiên tác tử khác, chỉ đọc, để nó soát diff và liệt kê những chỗ khớp. Kết quả là gợi ý để bạn xem, không phải phán quyết; người quyết gộp vẫn là bạn.
Khi phiên quá lớn để duyệt: dừng và tách
Có lúc bạn mở diff ra và thấy hàng nghìn dòng. Phản xạ tự nhiên là đọc lướt rồi tin. Đó chính là lúc lỗi lọt qua. Một nguyên tắc nhiều nhóm áp dụng: thay đổi vượt ngưỡng mà nhóm tự đặt, ví dụ giả định bốn trăm dòng không tính tệp sinh tự động, thì không duyệt nguyên khối mà tách ra.
Cách tách đơn giản là yêu cầu tác tử tự chia công việc đã làm thành nhiều nhánh nhỏ theo thứ tự phụ thuộc: phần đổi cấu trúc dữ liệu, phần logic, phần giao diện, phần kiểm thử. Mỗi nhánh duyệt và gộp riêng. Tác tử làm việc chia này khá tốt vì nó vừa viết xong mã và còn giữ bối cảnh trong phiên.
Nếu tách cũng khó, đôi khi lựa chọn đúng là bỏ cả phiên, viết lại phiếu việc nhỏ hơn và chạy lại. Nghe phí, nhưng một phiên tác tử tốn ít thời gian của bạn hơn nhiều so với một buổi chiều cố hiểu diff khổng lồ, và rủi ro gộp nhầm cũng thấp hơn hẳn.
Những phiên cần duyệt kỹ gấp đôi
Không phải phiên nào cũng đáng mười lăm phút như nhau. Một phiên đổi chữ trên giao diện có thể duyệt trong hai phút. Ngược lại, có vài loại thay đổi mà dù diff chỉ mười dòng, bạn vẫn nên đọc chậm và nhờ thêm một người thứ hai xem. Đó là thay đổi chạm vào tiền (tính giá, chiết khấu, hoàn tiền), vào quyền (ai được xem, ai được sửa, kiểm tra đăng nhập), và vào dữ liệu người dùng (lưu, xoá, xuất ra ngoài).
Loại thứ hai là tệp chuyển đổi dữ liệu. Một tệp thêm cột hoặc đổi kiểu dữ liệu chạy được trên cơ sở dữ liệu thử nghiệm nhỏ có thể khoá bảng hàng phút trên dữ liệu thật hàng triệu dòng. Tác tử thường không biết cỡ dữ liệu thật của bạn, nên nó không cân nhắc chuyện này nếu phiếu việc không nói.
Loại thứ ba là cấu hình triển khai và mã chạy định kỳ: tệp mô tả quy trình tích hợp liên tục, tệp dựng môi trường, lịch chạy tác vụ nền. Những tệp này không có kiểm thử đơn vị bảo vệ, sai thì chỉ lộ ra khi đã lên máy chủ. Với ba loại này, ghi sẵn trong tệp hướng dẫn dự án rằng tác tử phải dừng hỏi trước khi sửa, và khi duyệt thì đọc từng dòng, không lướt.
Ghi lại kết quả duyệt để phiên sau tốt hơn
Mỗi lần duyệt là một lần bạn học được tác tử hay sai ở đâu trên kho mã của mình. Nếu không ghi lại, bài học đó mất theo phiên. Vài cách ghi gọn:
- Thêm một dòng vào tệp hướng dẫn dự án cho mỗi lỗi lặp lại, ví dụ "không định dạng lại tệp ngoài những dòng đã sửa".
- Thêm vào danh sách điểm dừng chuẩn của nhóm nếu tác tử đã tự quyết một việc lẽ ra phải hỏi.
- Ghi vào thẻ công việc một câu đánh giá phiên: dùng được ngay, phải sửa ít, phải sửa nhiều, bỏ. Sau vài tuần nhìn lại sẽ thấy loại việc nào hợp giao cho tác tử.
- Nếu phát hiện gói phụ thuộc lạ hoặc khoá bí mật lọt vào mã, báo người phụ trách an toàn của nhóm ngay, kể cả khi bạn đã bỏ thay đổi đó.
Việc ghi chép này tốn một hai phút mỗi phiên. Đổi lại, tệp hướng dẫn dự án của nhóm dần phản ánh đúng những cái bẫy thật của kho mã, thay vì những quy tắc chung chung chép từ mạng.
Câu hỏi thường gặp
Có nên cho một tác tử khác duyệt phiên của tác tử thứ nhất?
Được, như một vòng soát đầu. Tác tử thứ hai chỉ nên có quyền đọc, nhận phiếu việc gốc và diff, rồi liệt kê điểm nghi vấn. Nó hay bắt được kiểm thử bị bỏ qua hay khối bắt lỗi rỗng, nhưng có thể bỏ sót lỗi logic nghiệp vụ, nên người vẫn phải đọc.
Nhật ký phiên bị mất hoặc công cụ không lưu thì duyệt thế nào?
Dựa vào git: danh sách tệp, lịch sử ghi nhận và tệp chưa theo dõi. Kiểm thêm môi trường như danh sách gói đã cài. Về sau nên chọn cách chạy có lưu lịch sử, hoặc yêu cầu tác tử ghi bản tóm tắt các lệnh đã chạy vào cuối báo cáo.
Duyệt phiên tác tử mất nhiều thời gian hơn tự viết thì sao?
Với việc nhỏ quen tay, điều đó hoàn toàn có thể xảy ra, và khi đó tự viết là lựa chọn hợp lý. Tác tử đáng dùng ở việc lặp lại, việc tìm kiếm khắp kho, việc viết kiểm thử hàng loạt, nơi phần duyệt ngắn hơn hẳn phần làm.
Thấy tác tử sửa kiểm thử cho khớp mã thì có phải luôn sai?
Không phải luôn sai. Nếu yêu cầu thay đổi làm hành vi đổi theo, kiểm thử cũ phải đổi. Điều cần là lý do rõ ràng, khớp với phiếu việc. Nếu lý do chỉ là cho kiểm thử qua, đó là dấu hiệu mã đang sai.
Có cần duyệt kỹ như vậy với dự án cá nhân nhỏ?
Mức kỹ có thể giảm, nhưng ba việc vẫn nên giữ: xem tệp mới chưa theo dõi, xem gói phụ thuộc mới và tìm khoá bí mật trong diff. Ba thứ đó gây hại thật kể cả ở dự án nhỏ, nhất là khi kho được đẩy lên nơi công khai.