TL;DR
Code review là nơi phần lớn quyết định thiết kế được chốt, nơi lỗ hổng bảo mật bị chặn lại trước khi vào nhánh main, và cũng là nơi văn hoá kỹ thuật của đội hình thành. Làm tốt, nó là công cụ đảm bảo chất lượng rẻ nhất. Làm tệ, nó là điểm nghẽn và là nguồn mệt mỏi lớn nhất của kỹ sư.
roadmap.sh có một trang tổng hợp thực hành tốt cho code review — danh sách đúng nhưng không có trọng số và không có ví dụ cụ thể. Bài này mở rộng danh sách đó thành một sổ tay thực hành: bốn trục (tác giả PR, người rà soát, quy trình, công cụ), thực hành chi tiết cho từng trục, phần rà soát theo góc độ bảo mật, cách đo hiệu quả, và các lỗi phổ biến mình thấy ở các đội vừa và nhỏ.
Nếu bạn mới vào đội và muốn nâng chất lượng code review, đọc đến hết phần “Thực hành chi tiết” là đủ. Nếu bạn là trưởng nhóm kỹ thuật và muốn thiết lập quy trình, đọc thêm phần “Vận hành” và “Đánh đổi”.
Bối cảnh
Phần lớn các đội mình từng làm cùng đều rơi vào một trong ba trạng thái code review:
- Gần như không có — PR được mở rồi tự duyệt, hoặc được duyệt trong 30 giây với một dòng “LGTM”. Mã vẫn được gộp, lỗi vẫn sinh ra, chỉ là muộn hơn — ở môi trường kiểm thử hoặc ở môi trường chạy thật.
- Có nhưng mệt — PR mở hai ngày chưa ai rà soát. Khi có người rà soát thì bị hơn 20 bình luận, phần lớn về đặt tên biến và dấu chấm phẩy. Tác giả chán, người rà soát mệt, cả hai đều ghét quy trình.
- Có và hoạt động tốt — PR nhỏ, mô tả rõ, rà soát trong ngày, bình luận tập trung vào thiết kế và trường hợp biên, bảo mật được nhắc đến khi đáng nhắc. Đội nào ở trạng thái này thường là đội có chất lượng ổn định nhất.
Khoảng cách giữa trạng thái 2 và 3 không nằm ở công cụ — GitHub, GitLab, Gerrit đều đủ tốt. Khoảng cách nằm ở thói quen, kỳ vọng chung, và việc đội có coi code review là một phần của công việc hay phần phụ làm khi rảnh.
Vấn đề
roadmap.sh liệt kê các thực hành rời rạc: giữ PR nhỏ, rà soát nhanh, bình luận tử tế, tự động hoá những gì có thể… Đúng, nhưng một danh sách không cho bạn biết:
- Nhỏ là bao nhiêu? 100 dòng hay 400 dòng?
- Nhanh là bao lâu? Trong 4 tiếng, 24 tiếng, hay 2 ngày?
- Tử tế trong bình luận nghĩa là gì khi bạn thực sự phản đối thiết kế?
- Tự động hoá phần nào? Phần nào vẫn cần con người?
- Khi tác giả và người rà soát không đồng ý, ai quyết?
Một danh sách thực hành không có trọng số và không có ví dụ sẽ thành khẩu hiệu — ai cũng gật đầu nhưng không ai thay đổi cách làm việc. Bài này cố gắng trả lời các câu hỏi cụ thể trên.
Còn một vấn đề nữa: phần lớn tài liệu về code review được viết từ góc nhìn của các đội lớn (Google, Microsoft, Meta). Đội 5-15 người — cỡ phổ biến ở Việt Nam — có ràng buộc khác. Không có sẵn văn hoá rà soát, không có nhiều kỹ sư kỳ cựu để luân phiên rà soát, và thời gian của người rà soát không vô hạn. Bài này viết với giả định đó.
Kiến trúc: bốn trục của code review tốt
Mình quen chia code review thành bốn trục. Mỗi trục có người chịu trách nhiệm, có kết quả rõ ràng, và có chỗ hay sai.
| Trục | Ai chịu trách nhiệm | Kết quả kỳ vọng |
|---|---|---|
| Tác giả PR | Người mở PR | PR dễ rà soát: nhỏ, có ngữ cảnh, có kiểm thử |
| Người rà soát | Người được gán rà soát | Phản hồi đúng tầng: thiết kế trước, chi tiết sau |
| Quy trình | Trưởng nhóm kỹ thuật | SLA rõ, không ai chờ vô hạn, tiêu chí gộp mã thống nhất |
| Công cụ | Đội nền tảng / DevOps | Tự động hoá phần máy làm được, giải phóng con người cho phần máy không làm được |
Ba lỗi phổ biến khi đọc bảng này:
- Chỉ tối ưu trục người rà soát — “đội cần rà soát kỹ hơn”. Nhưng nếu PR dày 1200 dòng, người rà soát giỏi mấy cũng bỏ sót.
- Chỉ tối ưu trục công cụ — mua SonarQube, bật CodeQL, nghĩ là xong. Công cụ bắt được lỗi cú pháp và mẫu quen thuộc, không bắt được quyết định thiết kế sai.
- Chỉ tối ưu trục quy trình — viết một trang tài liệu “Chính sách Code Review” rồi không ai đọc.
Cả bốn trục phải hoạt động cùng lúc.
Thực hành chi tiết
Trục 1 — Tác giả PR
1.1. PR nhỏ, một mục đích
Con số cụ thể mình áp dụng: dưới 400 dòng thay đổi (trừ các tệp tự sinh, tệp migration, snapshot test). Trên 400 dòng, chất lượng rà soát giảm mạnh — nghiên cứu của SmartBear (Cisco) từ lâu đã chỉ ra đường cong này: sau khoảng 400 dòng, tỉ lệ phát hiện lỗi tụt xuống dưới 50%.
Cách chia PR lớn:
- Tái cấu trúc trước, thay đổi hành vi sau. PR 1: đổi tên, tách hàm, di chuyển tệp — không đổi hành vi. PR 2: thêm tính năng trên mã đã sạch.
- Chia theo lớp. PR 1: lược đồ cơ sở dữ liệu và migration. PR 2: logic API. PR 3: giao diện.
- Dùng cờ tính năng (feature flag). Gộp PR nhiều lần vào nhánh
mainnhưng tính năng vẫn tắt cho đến khi hoàn thiện.
Ngoại lệ hợp lý: migration lược đồ, đổi cấu hình toàn kho mã (ví dụ đổi tên biến ở khắp nơi), nhập khối dữ liệu tĩnh lớn. Khi gặp ngoại lệ, ghi rõ trong mô tả PR để người rà soát biết phần nào cần xem kỹ.
1.2. Tự rà soát trước khi gán người rà soát
Trước khi bấm “sẵn sàng rà soát”, mở tab hiển thị các tệp đã đổi và tự đọc lại PR của mình như một người ngoài. Mình thường bắt được:
- Dòng
console.logbỏ quên. - Chú thích TODO chưa giải quyết.
- Các
importkhông dùng. - Tên biến đặt vội lúc nửa đêm.
- Một hàm dài đáng lẽ nên tách.
Quy tắc 30 giây: nếu chính bạn thấy chỗ nào khó hiểu trong 30 giây, người rà soát cũng sẽ thấy — sửa trước khi gán.
1.3. Mô tả PR có ngữ cảnh
Một mô tả PR tốt trả lời ba câu hỏi:
- Tại sao? — vấn đề đang giải quyết, liên kết tới phiếu, ngữ cảnh kinh doanh nếu cần.
- Cách tiếp cận? — quyết định thiết kế chính, các phương án đã cân nhắc và vì sao chọn cái này.
- Cách kiểm chứng? — kiểm thử nào đã chạy, ảnh chụp màn hình, log, hoặc lệnh để người rà soát tự thử lại.
Khuôn mẫu mình dùng:
## Thay đổi gì
<!-- Một câu. -->
## Tại sao
<!-- Vấn đề đang giải quyết. Liên kết phiếu nếu có. -->
## Tiếp cận thế nào
<!-- Quyết định thiết kế chính. Phương án đã bỏ qua. -->
## Kiểm chứng
- [ ] Kiểm thử mới đã viết
- [ ] Kiểm thử cũ vẫn qua
- [ ] Đã thử ở môi trường dev
- [ ] (Giao diện) Ảnh chụp trước/sau
## Rủi ro
<!-- Phần dễ sai nhất của PR này. Người rà soát nên xem kỹ chỗ nào. -->Mục Rủi ro là phần mình thấy hiệu quả nhất. Nó ép tác giả tự suy nghĩ và giúp người rà soát tập trung đúng chỗ.
1.4. Không để commit “fix typo” lẫn vào vòng rà soát
Trong quá trình rà soát, hãy gộp các commit nhỏ bằng rebase hoặc fixup. Một PR với 25 commit dạng “fix”, “fix v2”, “fix v3 please merge” là cơn ác mộng khi cần chạy git bisect về sau. Chính sách đơn giản mình hay dùng: gộp khi hợp nhất, nhưng trong quá trình rà soát thì giữ commit rời để người rà soát thấy từng bước.
Trục 2 — Người rà soát
2.1. Rà soát theo tầng, không rà soát từ trên xuống dưới
Đọc lần lượt từ tệp đầu đến tệp cuối là cách dễ nhất để bỏ sót vấn đề lớn. Thứ tự mình khuyến nghị:
- Đọc mô tả PR và phiếu liên kết. Hiểu bài toán trước khi xem mã.
- Nhìn tổng thể các tệp đã đổi. Tệp nào là trung tâm? Tệp nào là phụ?
- Đọc kiểm thử trước khi đọc mã chính. Kiểm thử cho biết tác giả nghĩ mã này phải làm gì.
- Đọc mã chính (tệp trung tâm). Kiểm tra logic, trường hợp biên.
- Đọc tệp phụ. Thường là định dạng, đổi tên, cấu hình.
- Cuối cùng mới bình luận chi tiết.
Cách này giúp bắt lỗi thiết kế trước khi sa đà vào chi tiết cú pháp.
2.2. Phân loại bình luận
Không phải bình luận nào cũng cùng trọng số. Mình gắn nhãn đầu câu để tác giả biết cái nào bắt buộc, cái nào gợi ý:
[blocker]— phải sửa trước khi hợp nhất. Lỗi chức năng, lỗi bảo mật, thiết kế sai.[must]— bắt buộc, nhưng không chặn hợp nhất nếu sửa trong PR tiếp theo.[should]— nên sửa, có thể bỏ qua nếu có lý do.[nit]— nhỏ nhặt, tuỳ tác giả.[question]— hỏi để hiểu, không yêu cầu sửa.[praise]— khen một đoạn tốt. Quan trọng để cân bằng.
Quy ước này không phải mình nghĩ ra — nó lấy từ Conventional Comments, mình chỉ áp dụng. Lợi ích rõ ràng: người rà soát không cần dài dòng xin lỗi “không quan trọng đâu nhưng…”, và tác giả biết đâu là đường chốt.
2.3. Phản hồi đúng tầng
Người rà soát tốt chia phản hồi theo ba tầng, theo thứ tự ưu tiên:
- Thiết kế / kiến trúc — API có đúng không, trừu tượng hoá có đặt đúng chỗ không, ranh giới mô-đun có rõ không. Sửa ở tầng này tốn nhất, phải nói sớm.
- Đúng/sai của logic — trường hợp biên, xử lý lỗi, điều kiện tranh chấp, giả định ngầm.
- Phong cách, chi tiết — tên biến, định dạng, cấu trúc nhỏ.
Lỗi phổ biến: nhảy vào tầng 3 trước. Khi tác giả đã sửa 20 bình luận về đặt tên biến, mới có người phát hiện API bị thiết kế sai — phải làm lại từ đầu.
Nếu bạn thấy vấn đề tầng 1, hãy để lại một bình luận duy nhất về vấn đề đó và tạm dừng rà soát. Chờ tác giả phản hồi rồi mới đi tiếp. Không cần bình luận 40 chỗ khi 30 chỗ trong số đó sẽ biến mất nếu thiết kế thay đổi.
2.4. Chạy mã nếu PR phức tạp
Với các PR thay đổi hạ tầng, migration, hoặc logic phức tạp, hãy checkout nhánh và chạy thật. Không có cách nào đọc diff mà phát hiện được “lệnh này treo vô tận khi cơ sở dữ liệu trống”.
2.5. Gợi ý thay vì ra lệnh
So sánh hai bình luận cùng ý:
❌ “Đổi cái này thành
useMemo.”
✅ “Mình nghĩ
useMemoở đây sẽ tránh tính lại khi kết xuất lại. Bạn có lý do nào để không dùng không?”
Cái thứ hai không chỉ tử tế hơn — nó còn đúng hơn. Có thể tác giả đã có lý do không dùng useMemo, và người rà soát nên nghe lý do đó trước khi chốt.
Trên GitHub và GitLab, tính năng “đề xuất thay đổi” rất tiện cho các sửa nhỏ về cú pháp — tác giả chỉ cần bấm một nút để áp dụng. Với thay đổi lớn hơn, viết bằng văn xuôi, không ép mã.
2.6. Khen khi đáng khen
Khi gặp một đoạn mã sạch, một trừu tượng hoá tốt, hoặc một quyết định khó nhưng đúng, hãy để lại bình luận [praise]. Nghe sến nhưng hiệu quả: nó cân bằng với các bình luận sửa, giúp tác giả không cảm thấy bị công kích, và củng cố thói quen tốt cho đội.
Trục 3 — Quy trình
3.1. SLA rà soát
Không có SLA, PR có thể nằm đó cả tuần. Quy tắc mình áp dụng:
- PR chặn (sửa lỗi môi trường chạy thật, chặn người khác): rà soát trong 2 tiếng làm việc.
- PR thường: rà soát trong 24 tiếng làm việc đầu tiên.
- PR lớn hoặc thiết kế mới: lên lịch một buổi rà soát đồng bộ, không rà soát bất đồng bộ.
Nếu người rà soát không thể đáp ứng SLA, phải chuyển cho người khác — không phải biến mất.
3.2. Quy tắc duyệt
Với đội 5-15 người:
- Tối thiểu một phê duyệt. Hai phê duyệt cho mã chạm vào bảo mật, thanh toán, hoặc hạ tầng chung.
- Không tự hợp nhất PR của mình nếu chưa có phê duyệt. Kể cả trưởng nhóm kỹ thuật.
- Tác giả có thể bỏ qua bình luận
[nit]và[should]nếu có lý do.[blocker]và[must]phải giải quyết. - Khi bế tắc (người rà soát và tác giả không đồng ý), đưa vào một buổi thảo luận đồng bộ 15 phút, hoặc nhờ một người thứ ba quyết. Không tranh luận 40 bình luận trên PR.
3.3. Bất đồng bộ trước, đồng bộ khi cần
Rà soát bất đồng bộ (qua bình luận trên PR) là mặc định — tốn ít thời gian hơn, ghi lại được. Nhưng một số tình huống bắt buộc phải đồng bộ:
- PR thay đổi kiến trúc lớn.
- Đã qua hai vòng trao đổi mà vẫn chưa hiểu nhau.
- PR có yếu tố nhạy cảm (khen chê cách làm, chạm sang đội khác).
Nguyên tắc: ý kiến kỹ thuật — bất đồng bộ; cảm xúc hoặc hiểu lầm — đồng bộ.
3.4. Không rà soát cũng là một lựa chọn
Vài thứ không đáng code review:
- Cập nhật phiên bản thư viện đã được Renovate hoặc Dependabot xác minh.
- Đổi nội dung tệp markdown đã được duyệt ở nơi khác (ví dụ bản nháp đã duyệt trong tài liệu nội bộ).
- Thay đổi cấu hình không ảnh hưởng môi trường chạy thật (ví dụ
README).
Áp dụng tự động hợp nhất khi các kiểm tra trạng thái đều qua cho các loại này. Đừng biến code review thành nghi thức trên mọi thay đổi — nghi thức hoá sẽ giết động lực thật.
Trục 4 — Công cụ
Công cụ không thay thế con người, nhưng phải gánh được các việc con người không nên làm. Phân vai chuẩn:
| Việc | Máy làm | Người làm |
|---|---|---|
| Định dạng mã | ✅ (Prettier, gofmt) | ❌ |
| Kiểm cú pháp/quy ước | ✅ (ESLint, Ruff, golangci-lint) | ❌ |
| Kiểm kiểu dữ liệu | ✅ (tsc, mypy) | ❌ |
| Bắt mẫu lỗi bảo mật | ✅ (Semgrep, CodeQL) | Đọc báo cáo |
| Quét rò rỉ bí mật | ✅ (gitleaks, trufflehog) | ❌ |
| Quét phụ thuộc có lỗ hổng | ✅ (Dependabot, Trivy) | ❌ |
| Quyết định thiết kế | ❌ | ✅ |
| Đánh giá trừu tượng hoá | ❌ | ✅ |
| Phát hiện điều kiện tranh chấp không rõ ràng | ❌ (một phần) | ✅ |
| Hiểu ngữ cảnh kinh doanh | ❌ | ✅ |
Quy tắc: không bao giờ để người rà soát bận tâm việc máy đã bắt được. Nếu CI chưa chạy xong, người rà soát chờ. Nếu kiểm cú pháp thất bại, tác giả sửa trước khi gán người rà soát. Mọi bình luận dạng “thiếu dấu chấm phẩy” là lãng phí thời gian con người.
4.1. Cổng CI tối thiểu
Cho một dự án web hoặc dịch vụ điển hình, các bước CI mình yêu cầu trước khi hợp nhất:
# .github/workflows/pr.yml (rút gọn)
jobs:
lint: # Ruff / ESLint / golangci-lint
typecheck: # tsc --noEmit / mypy
test: # kiểm thử đơn vị + tích hợp
secrets: # gitleaks detect
deps: # trivy fs . --severity HIGH,CRITICAL
build: # thử dựng bản vận hànhCổng nào thất bại, không hợp nhất được. Không có ngoại lệ “hợp nhất rồi sửa sau”.
4.2. Rà soát bằng AI — có dùng nhưng biết giới hạn
Các công cụ như Copilot for PRs, CodeRabbit, hay rà soát tự động của GitHub Advanced Security đã đủ tốt để:
- Tóm tắt PR cho người rà soát đọc trước.
- Bắt các mẫu lỗi quen thuộc (SQL injection cơ bản, đầu vào không kiểm tra hợp lệ).
- Gợi ý đặt tên rõ hơn.
Nhưng chúng không thay thế con người với các vấn đề thiết kế, lỗ hổng bảo mật phức tạp (ví dụ IDOR, lỗ hổng logic), hoặc ngữ cảnh kinh doanh. Dùng như lớp đầu, không phải lớp duy nhất.
Rà soát theo góc độ bảo mật
Code review là lớp phòng thủ rẻ nhất cho nhiều lỗ hổng. Một số chỗ mình luôn kiểm khi rà soát:
- Xác thực và phân quyền. Điểm cuối mới này có yêu cầu đăng nhập chưa? Người đã đăng nhập có được phép làm việc này không (phân quyền, không chỉ xác thực)?
- Đầu vào không tin được. Mọi tham số từ người dùng đã được kiểm tra hợp lệ? Có thoát ký tự đúng chỗ không (SQL, HTML, shell)?
- Bí mật và thông tin xác thực. Khoá API, token, mật khẩu có bị ghi log không? Có bị đẩy vào kho mã không? Có truyền qua URL không?
- Dữ liệu nhạy cảm. Thông tin cá nhân (PII) có bị ghi log không? Có mã hoá khi lưu không? Có gửi qua HTTPS không?
- Kiểm soát tải. Có giới hạn tốc độ không? Điểm cuối này có thể bị lạm dụng thành DoS không?
- Phụ thuộc mới. Thư viện mới được thêm — đã kiểm giấy phép? Người duy trì có uy tín không? Có lỗ hổng đã biết không?
- Phân quyền trong IAM hoặc hạ tầng đám mây. Vai trò mới có quá rộng không? Có dùng
*ở trường Resource hay Action không?
Mình giữ một danh mục kiểm ngắn trong .github/PULL_REQUEST_TEMPLATE.md với mục “Cân nhắc bảo mật” — ép tác giả tự đánh dấu trước khi đẩy PR, tạo thói quen ngay từ phía tác giả.
Vận hành: đo code review hiệu quả thế nào
Không đo thì không cải thiện được. Nhưng đo sai còn tệ hơn không đo — đừng dùng chỉ số code review làm KPI cá nhân. Đo để đội hiểu quy trình, không phải để so sánh cá nhân.
| Chỉ số | Ý nghĩa | Ngưỡng tham khảo |
|---|---|---|
| Thời gian đến lần rà soát đầu | Khoảng cách từ lúc PR mở đến bình luận hoặc phê duyệt đầu tiên | Dưới 4 tiếng làm việc |
| Thời gian đến khi hợp nhất | Tổng thời gian PR sống | Dưới 24 tiếng cho PR thường |
| Kích thước PR (dòng thay đổi) | Số dòng thay đổi trung bình | Dưới 400 dòng |
| Số bình luận mỗi PR | Số bình luận không phải [nit] mỗi PR | 3-10 (dưới 3: rà soát hời hợt; trên 15: PR quá lớn hoặc thiết kế sai) |
| Tỷ lệ làm lại | Phần trăm PR phải sửa sau khi đã phê duyệt (ví dụ hoàn tác trong tuần) | Dưới 5% |
| Độ bao phủ rà soát | Phần trăm commit đi qua rà soát | 100% trên main |
Công cụ: GitHub Insights, LinearB, Swarmia, hoặc một tập lệnh đơn giản gọi GitHub API. Với đội nhỏ, mình thường bắt đầu bằng một bảng chỉ số rất đơn giản — chỉ hai biểu đồ: thời gian đến lần rà soát đầu (trung vị) và kích thước PR (phân phối) trong 30 ngày. Khi hai con số này ổn, phần còn lại thường tự ổn theo.
Nhịp rà soát định kỳ
Mỗi tháng, đội nên dành 30 phút nhìn lại:
- PR nào mất quá lâu, vì sao?
- Có ai luôn là điểm nghẽn (một người rà soát tất cả)?
- Có mẫu nào lặp lại trong bình luận (ví dụ “lại thiếu kiểm thử cho trường hợp
null”) — đó là dấu hiệu cần thêm công cụ kiểm cú pháp hoặc thêm đào tạo.
Đánh đổi
| Quyết định | Phương án | Mình chọn | Vì |
|---|---|---|---|
| Số phê duyệt tối thiểu | 1 hay 2 | 1 cho mã thường, 2 cho mã nhạy cảm | 2 phê duyệt cho mọi thứ làm chậm mọi thứ; 1 không đủ cho bảo mật và thanh toán |
| Áp dụng phong cách | Bình luận tay hay công cụ định dạng tự động | Công cụ định dạng + móc pre-commit | Con người không nên tranh luận về dấu chấm phẩy |
| Kích thước PR | Nhỏ (dưới 400 dòng) hay cho phép lớn khi cần | Nhỏ, trừ ngoại lệ được nêu trước | Đường cong chất lượng rà soát tụt rõ sau 400 dòng |
| Đồng bộ hay bất đồng bộ | Chủ yếu đồng bộ hay chủ yếu bất đồng bộ | Bất đồng bộ trước, đồng bộ khi cần | Ghi lại được, không chặn cả đội, nhưng biết lúc nào cần kéo mọi người vào phòng |
| Rà soát bằng AI | Không dùng hay dùng như người rà soát chính | Dùng như lớp bổ trợ | Bắt được nhiễu, không thay được đánh giá thiết kế |
| SLA rà soát | Mềm hay cứng | SLA mềm (kỳ vọng) + nâng cấp khi vi phạm | SLA cứng thành áp lực không lành mạnh, SLA mềm với minh bạch hoạt động tốt hơn |
Bài học
- Code review tốt 80% nằm ở phía tác giả, 20% nằm ở người rà soát. PR nhỏ, mô tả rõ, tự rà soát cẩn thận — người rà soát gần như không phải cố gắng nhiều. PR lớn, mô tả “fix stuff”, chưa tự đọc lại — không có người rà soát nào cứu được.
- Phân loại bình luận bằng nhãn đầu câu là thay đổi nhỏ nhất có tác động lớn nhất mà mình từng áp dụng. Một ngày để đội làm quen, hiệu quả thấy được ngay trong tuần đầu.
- Thiết kế trước, chi tiết sau. Nếu người rà soát thấy vấn đề thiết kế, dừng rà soát chi tiết. Đừng tiếc 30 phút đã đọc.
- Đừng để con người làm việc của máy. Bất cứ bình luận nào mà công cụ kiểm cú pháp, định dạng, hoặc quét tự động có thể bắt là lãng phí — sửa công cụ, không sửa người.
- SLA mềm và minh bạch hơn SLA cứng và áp lực. Đội trưởng thành tự duy trì SLA khi nhìn thấy số. Đội không trưởng thành sẽ tìm cách lách SLA cứng.
- Đo để hiểu, không để so sánh. Khoảnh khắc chỉ số rà soát thành KPI cá nhân là khoảnh khắc rà soát chết.
Tham khảo
- roadmap.sh — Thực hành tốt cho Code Review — danh sách gốc mà bài này mở rộng.
- Google Engineering Practices — Code Review Developer Guide — tài liệu công khai tốt nhất về code review, rất đáng đọc hết.
- Conventional Comments — quy ước nhãn đầu câu cho bình luận (
blocker,nit,praise…). - SmartBear — Best Kept Secrets of Peer Code Review — nguồn gốc của con số “dưới 400 dòng”.
- The Art of Readable Code (Dustin Boswell, Trevor Foucher) — sách gối đầu cho cả tác giả và người rà soát.
- OWASP Code Review Guide — danh mục kiểm rà soát theo góc độ bảo mật.
- LinearB / Swarmia engineering metrics — khi cần đo chuyên sâu.
