Đọc thay đổi mã nguồn: bắt đầu từ đâu để đỡ ngợp?

Mở một pull request có ba mươi file, bạn kéo ngay xuống phần code màu xanh. Mười phút sau, bạn đã nghĩ ra hai tên biến hay hơn nhưng vẫn chưa biết thay đổi này sửa lỗi gì. Cảm giác hơi quê, nhưng chuyện đó khá dễ xảy ra khi mình đọc từng dòng mà chưa có câu hỏi dẫn đường.

Đọc thay đổi mã nguồn sẽ dễ theo hơn nếu bắt đầu từ tình huống người dùng. Trong ví dụ giả định này, Minh review bản sửa lỗi gửi email xác nhận trùng. Cậu cần hiểu khi nào lỗi xuất hiện, code mới chặn nó ở đâu và những trường hợp nào vẫn phải gửi thư bình thường.

Bắt đầu bằng một thay đổi nhỏ

Mô tả PR chỉ ghi “sửa lỗi email”. Minh hỏi thêm: người dùng bấm hai lần hay hệ thống xử lý lại một yêu cầu? Hai tình huống cùng tạo ra thư trùng, nhưng cách kiểm khác nhau. Chưa rõ điều kiện gây lỗi thì rất khó biết bản sửa đã đi đúng hướng chưa.

Người viết bổ sung một ví dụ cụ thể: khách gửi yêu cầu xác nhận, sau đó thao tác lại vì chưa thấy phản hồi. Minh ghi ngắn hành vi mong đợi để theo dõi khi đọc. Với một yêu cầu được xử lý lại, hệ thống cần tránh tạo thêm thông báo ngoài ý muốn.

Cậu nhìn danh sách file trước khi đọc chi tiết. Có phần nhận yêu cầu, phần tạo tác vụ gửi thư và bài kiểm tra. Một file trang hồ sơ cũng thay đổi. Minh hỏi lý do để biết nó thuộc cùng luồng hay là việc sửa tiện tay có thể đưa sang PR riêng.

PR nhỏ dễ đọc khi giải quyết một chuyện rõ ràng, không nhất thiết ít dòng bằng mọi giá. Nếu các phần phải đi cùng nhau để tính năng hoạt động, cứ giữ chúng cùng nhau. Điều Minh cần là hiểu vai trò từng phần, thay vì chia nhỏ tới mức mỗi bản sửa đều dang dở.

Tiếp theo, Minh tìm một luồng gửi thông báo đang hoạt động trong dự án. Yêu cầu đi qua những bước nào? Nhóm ghi nhận lỗi ở đâu? Cách hiện có giúp cậu hiểu bối cảnh trước khi nhận xét. Một giải pháp quen tay ở dự án khác chưa chắc hợp với nơi này.

Khi gặp tham số chưa hiểu, Minh tìm nơi gọi hàm và nơi tạo giá trị. Cậu không vội kết luận nó thừa chỉ vì màn hình đang xem chưa dùng. Nếu chữ ký hàm thay đổi, các nơi gọi liên quan cũng cần được xem lại để tránh sửa đúng một chỗ nhưng làm hỏng chỗ khác.

Minh giữ một ghi chú ngắn gồm câu hỏi và vị trí cần đọc tiếp. “Yêu cầu lặp được nhận diện ở đâu?” hữu ích hơn “chưa hiểu đoạn này”. Câu hỏi cụ thể giúp cậu mở đúng file, rồi quay lại mạch chính khi đã có lời giải.

Theo một luồng từ đầu đến cuối

Minh bắt đầu với một lượt gửi bình thường. Cậu đi từ điểm nhận yêu cầu tới lúc tác vụ gửi thư được tạo. Ở mỗi đoạn, cậu xem đầu vào là gì và kết quả được chuyển cho phần tiếp theo ra sao. Chưa cần đọc mọi nhánh cùng lúc.

Đến phần kiểm dữ liệu, Minh xem hệ thống yêu cầu thông tin nào và xử lý phần thiếu ra sao. Giao diện có thể đã chặn nút, nhưng đó chưa phải toàn bộ luồng. Phần nhận yêu cầu vẫn cần xử lý trường hợp dữ liệu gửi tới không giống điều màn hình đang mong đợi.

Cậu đọc tiếp điều kiện tìm bản ghi. Người gửi có được thao tác với bản ghi đó không? Một nút bị ẩn chưa trả lời được câu hỏi này. Minh đối chiếu với cách kiểm quyền đang dùng trong dự án và hành vi mà tính năng yêu cầu.

Tới bước lưu trạng thái, cậu ghi lại điều gì thay đổi trước khi gửi thư. Nếu phần gửi gặp lỗi, trạng thái còn lại sẽ nói gì với lần thử sau? Câu hỏi này bám sát bản sửa đang đọc. Nó giúp tránh trường hợp chặn thư trùng nhưng vô tình chặn luôn lượt cần thử lại.

Không phải thấy rủi ro là lập tức đề xuất một kiến trúc mới. Minh kiểm cách dự án đang xử lý công việc tương tự rồi trao đổi với người viết. Nếu có phần cần kiến thức chuyên sâu, cậu nhờ người phù hợp xem thêm và nói rõ mình đã kiểm tới đâu.

Sau luồng bình thường, Minh theo lại lượt yêu cầu lặp. Điều kiện mới được kiểm lúc nào? Có bước nào đã chạy trước khi hệ thống nhận ra sự lặp không? Tự kể lại luồng bằng câu đơn giản thường giúp phát hiện khoảng trống mà việc đọc tên hàm chưa cho thấy.

Khi góp ý, Minh viết cả tình huống và hậu quả: “Nếu lần gửi đầu thất bại sau khi lưu trạng thái, lần thử sau có bị bỏ qua không?” Người viết có thể kiểm ngay câu hỏi ấy. Nhận xét “logic chưa ổn” thì chỉ khiến hai bên mất thêm lượt hỏi nhau.

Góp ý cũng nên phân biệt lỗi cần sửa với sở thích trình bày. Một tên biến có thể rõ hơn, nhưng chưa chắc là lý do giữ PR lại. Hướng dẫn code review của Google cũng lưu ý không chặn thay đổi chỉ vì sở thích cá nhân về phong cách code.

Thử lại đúng tình huống gây lỗi

Minh quay lại mô tả ban đầu để chọn cách kiểm. Nếu vấn đề nằm ở yêu cầu lặp, chỉ gửi một lần thành công chưa đủ. Cậu cần thử trường hợp lặp theo điều kiện thực tế của lỗi, rồi xem số tác vụ hoặc thông báo được tạo bằng cách dự án đang hỗ trợ.

Cậu đọc bài kiểm tra đi kèm thay vì chỉ nhìn dấu xanh. Test có tạo ra điều kiện lặp không? Nó xác nhận điều gì? Một test có tên “không gửi trùng” nhưng chỉ kiểm phản hồi thành công có thể chưa chứng minh được hành vi đang cần sửa.

Nếu cần thử lại qua giao diện, ghi rõ tài khoản, dữ liệu mẫu và thao tác. Cách ghi lại tình huống báo lỗi giúp cả người viết lẫn người review tái hiện cùng một việc. Tránh dùng thông tin khách thật trong ảnh hoặc dữ liệu chia sẻ.

Tiếp đó, Minh kiểm một lượt gửi bình thường để chắc bản sửa không chặn nhầm hành vi cần giữ. Với trường hợp lỗi giữa chừng, cậu xem cách thử lại theo yêu cầu đã thống nhất. Mỗi lần kiểm nên trả lời một câu hỏi, thay vì chạy thêm nhiều bước mà không biết đang muốn xác nhận gì.

Nếu chưa chạy được vì thiếu môi trường, Minh nói rõ giới hạn ấy. Cậu có thể nhận xét dựa trên code nhưng không ghi đã kiểm hoạt động. Khi nhờ người khác chạy giúp, gửi điều kiện cụ thể; cách nói rõ kết quả cần kiểm giúp tránh nhận về một câu “chạy ổn” quá chung.

Trước khi kết thúc, Minh gom những câu hỏi còn mở và kết quả đã xác nhận. Cậu ghi cả phần chưa kiểm được. Người viết biết chỗ nào cần sửa, chỗ nào chỉ là gợi ý. Nếu còn vấn đề lớn ngoài phạm vi PR, ghi riêng để xử lý sau. Lượt review hoàn thành khi mọi người hiểu bản sửa làm gì và bằng chứng kiểm tra tới đâu.