Xem Lại Kết Quả Ở Quy Mô Lớn
Đây là vấn đề thẳng thắn: khi các viết hàng trăm dòng trên nhiều tác vụ, bạn không thể đọc từng dòng theo cách bạn xem lại một diff mười dòng. Giả vờ như bạn có thể sẽ dẫn tới hoặc là đóng dấu thông qua một cách qua loa (rubber-stamping — bạn chấp thuận mà không nhìn), hoặc là tê liệt (bạn không bao giờ tin tưởng bất cứ điều gì). Cả hai đều không đưa được sản phẩm ra.
Con đường đi qua là chốt chặn ở một vài lớp thay vì đọc mọi thứ:
- Các bài test là tầng nền. Không có kết quả nào của agent được gộp vào mà không có các bài test liên quan chạy xanh và trình kiểm tra kiểu (type-checker) sạch. Điều này không thể thương lượng và nó tự động — máy làm phần này.
- Xem lại kỹ các phần rủi ro. Bạn không thể đọc tất cả, nên hãy đọc những phần có bán kính ảnh hưởng cao: bất cứ thứ gì đụng tới xác thực (auth), tiền bạc, xóa dữ liệu, hoặc các cuộc gọi bên ngoài. Lướt qua phần còn lại để tìm các cờ đỏ từ chương xây dựng tính năng — những file lẽ ra không nên chạm vào, những thứ bị xóa âm thầm, một yêu cầu nhỏ xíu tạo ra một diff khổng lồ.
- Đọc diff, không phải đọc cả codebase.
git diff --statcho bạn biết cái gì đã thay đổi và thay đổi bao nhiêu trong vài giây. Một tác vụ được giới hạn phạm vi trong một module mà lại hiện thay đổi ở sáu module là một tín hiệu để nhìn kỹ hơn, trước khi bạn đọc dù chỉ một dòng. - Chạy nó. Một bộ test chạy xanh không phải là một ứng dụng hoạt động. Hãy bấm vào thứ đó. Kiểm tra cuối cùng luôn là kiểm tra giống như trong mọi chương khác: nó có thực sự làm những gì bạn yêu cầu, ngay trước mắt bạn không?
Việc giới hạn phạm vi mang lại lợi ích gấp đôi ở đây. Một tác vụ mà bạn giới hạn phạm vi chặt chẽ tạo ra một diff mà bạn thực sự có thể xem lại; một tác vụ bạn thả lỏng tạo ra một diff mà bạn không thể. Vấn đề xem lại phần lớn được giải quyết từ đầu nguồn, trong bản mô tả công việc.