Một lượt review hữu ích cần chỉ ra thay đổi nào gây vấn đề, điều kiện xảy ra và bằng chứng để người khác kiểm tra lại. Skill giúp giữ quy trình nhất quán; kết luận vẫn phải dựa trên mã nguồn, yêu cầu và kết quả kiểm thử thực tế.
A useful review identifies the change causing a problem, its trigger and evidence another person can verify. A skill keeps the procedure consistent; conclusions still depend on source, requirements and actual validation.
Trong bài nàyOn this page
1. Chốt phạm vi trước khi đọc mã1. Define the scope before reading code
Chuẩn bị checkout của nhánh cần review, base branch, mô tả PR và tiêu chí nghiệm thu. Kiểm tra working tree để phân biệt thay đổi đã commit với chỉnh sửa đang làm. Ví dụ dưới đây giả định base là origin/main và ref đó đã được cập nhật theo quy trình dự án.
Prepare the branch checkout, base branch, PR description and acceptance criteria. Inspect the working tree to distinguish committed changes from ongoing edits. This example assumes origin/main is the base and has already been refreshed through the project workflow.
git status --short
git rev-parse origin/main HEAD
git log --oneline origin/main..HEAD
git diff --stat origin/main...HEAD
git diff --check origin/main...HEAD
git diff origin/main...HEADDấu ba chấm lấy thay đổi từ merge base tới HEAD, phù hợp khi xem phần nhánh đóng góp. Ghi lại SHA của hai đầu vì nhánh có thể đổi sau lượt review. Các lệnh này không bao gồm toàn bộ chỉnh sửa chưa commit; nếu cần review chúng, thêm git diff và git diff --cached vào phạm vi đã thống nhất.
The three-dot diff compares the merge base with HEAD, isolating the branch contribution. Record the endpoint SHAs because branches can move. These commands do not cover all uncommitted edits; include git diff and git diff --cached when those changes are explicitly in scope.
2. Đối chiếu cả tiêu chuẩn và yêu cầu2. Check standards and requirements
Đọc hướng dẫn repository, mã xung quanh và test liên quan trước khi áp dụng code-review. Tách hai câu hỏi: thay đổi có tuân thủ quy ước đã ghi nhận không, và có thực hiện đúng yêu cầu của tác vụ không?
Ví dụ, một API có thể đúng style nhưng trả thiếu trường mà đặc tả yêu cầu. Ngược lại, đổi cách đặt tên không nhất thiết là bug nếu dự án không quy định. Ghi riêng lỗi hành vi, vi phạm quy ước và đề xuất mang tính lựa chọn.
Read repository instructions, surrounding code and relevant tests before applying code-review. Ask two separate questions: does the change follow documented standards, and does it satisfy the task requirements?
An API can follow the style guide while omitting a required response field. A naming preference is not automatically a bug when no repository standard requires it. Distinguish behavioral defects, documented-rule violations and optional suggestions.
Review thay đổi từ merge base của origin/main đến HEAD.
Đọc hướng dẫn repository và tiêu chí nghiệm thu đã cung cấp.
Với mỗi phát hiện, ghi đường dẫn/dòng, điều kiện kích hoạt,
hậu quả và bằng chứng hoặc test có thể tái hiện.
Phân biệt lỗi đã xác nhận với nghi vấn chưa kiểm chứng.
Chỉ báo cáo tại đây; chưa sửa file, commit, push hoặc đăng comment lên PR.Review changes from the merge base of origin/main to HEAD.
Read repository instructions and the supplied acceptance criteria.
For each finding, include the path/line, trigger, consequence,
and evidence or a reproducible test.
Separate confirmed defects from unverified concerns.
Report here only; do not edit, commit, push or post PR comments yet.3. Biến nghi vấn thành kiểm tra cụ thể3. Turn concerns into specific checks
Ưu tiên thay đổi ảnh hưởng dữ liệu, quyền truy cập, giao dịch, đầu vào và điều kiện biên. Theo luồng gọi đến nơi dữ liệu được dùng; một dòng trông bất thường có thể đã được bảo vệ ở tầng trước. Chạy test nhỏ nhất phân biệt được hành vi đúng và sai trong môi trường thử phù hợp.
Với thay đổi UI, xem DOM và luồng thực qua webapp-testing. Đối chiếu ảnh chụp với thao tác và kích thước màn hình, thay vì chỉ nhận xét từ CSS. Nếu thiếu tài khoản thử hoặc môi trường, ghi rõ phần chưa kiểm chứng.
Ví dụ minh họa cách viết phát hiện: “Khi giỏ hàng có hai đơn vị cùng một sản phẩm, phép cộng chỉ lấy đơn giá nên tổng thiếu một đơn vị. Ca kiểm tra với đơn giá 1.250 xu và số lượng 2 trả 1.250 thay vì 2.500.” Đây là ví dụ về hình thức bằng chứng, không phải kết quả review một dự án cụ thể.
Prioritize changes affecting data, access control, transactions, inputs and boundaries. Follow the call path to the data consumer; suspicious code may already be guarded upstream. Run the smallest check that distinguishes correct and incorrect behavior in an appropriate test environment.
For UI changes, inspect the rendered DOM and real flow with webapp-testing. Connect screenshots to actions and viewport sizes instead of judging CSS alone. Report missing test accounts or environments as verification gaps.
An illustrative finding could say: “With two units of one item, the sum uses only its unit price. A case with a 1,250-cent price and quantity 2 returns 1,250 instead of 2,500.” This demonstrates evidence format; it is not a finding against a specific repository.
4. Báo cáo đủ để quyết định và sửa4. Report enough to decide and fix
Sắp xếp phát hiện theo ảnh hưởng và khả năng xảy ra. Mỗi phát hiện cần ngắn nhưng có thể kiểm tra: vị trí, trigger, expected/actual và hướng sửa. Đừng nâng mức ưu tiên chỉ vì tên hàm hoặc công nghệ nghe quan trọng.
Kết thúc bằng phạm vi đã đọc, test đã chạy và phần còn chưa kiểm chứng. “Không thấy lỗi trong phạm vi này” không có nghĩa mọi đường chạy đều an toàn. Khi bản sửa được yêu cầu, thêm regression test có ý nghĩa, chạy lại ca lỗi và các test liên quan rồi review diff cuối cùng.
Muốn thực hành cách thu hẹp nguyên nhân, đọc debug với AI agent. Một ví dụ thực trong VAS là lỗi mất receipt khi nhiều tiến trình cập nhật JSON.
Order findings by impact and likelihood. Each should include its location, trigger, expected/actual behavior and a useful fix direction. Do not inflate severity merely because a function or technology sounds important.
Close the report with reviewed scope, executed tests and remaining gaps. Finding no defects in a scope does not establish that every path is safe. When a fix is requested, add a meaningful regression test, repeat the original failure and related checks, then review the final diff.
Practice narrowing a cause with AI-assisted debugging. A real VAS example is lost receipts during concurrent JSON updates.