Code Review — bản chất, quy tắc và cách thực hiện đánh giá trong nhóm

Code Review là gì?

Code Review là quá trình kiểm tra mã nguồn bởi một hoặc nhiều nhà phát triển trước khi tích hợp vào nhánh chính của dự án. Mục đích của việc đánh giá không chỉ là tìm lỗi mà còn cải thiện kiến trúc, đảm bảo tuân thủ các tiêu chuẩn của nhóm và phổ biến kiến thức. Khác với phân tích tự động (linters), đánh giá mã được thực hiện bởi con người và đánh giá tính dễ đọc, logic và các quyết định kiến trúc.

Theo Google Engineering Practices, 2024, Code Review có hai mục tiêu quan trọng như nhau: bảo vệ cơ sở mã khỏi lỗi và đào tạo các nhà phát triển thông qua phản hồi. Trong các dự án di động, việc đánh giá bắt buộc bao gồm kiểm tra các framework (UIKit, SwiftUI, Jetpack Compose), quản lý bộ nhớ và xử lý yêu cầu mạng.

Code Review trong GitLab và GitHub được tổ chức thông qua Merge Request và Pull Request tương ứng. Mỗi MR/PR chứa diff, nhận xét dòng, thảo luận và trạng thái kiểm tra. Theo Microsoft Research (2023), các nhóm thực hành đánh giá thường xuyên phát hành ít hơn 40% lỗi nghiêm trọng ra sản xuất.

Lịch sử Code Review: từ kiểm tra chính thức đến PR không đồng bộ

Code Review chính thức đầu tiên xuất hiện tại IBM vào những năm 1970 dưới dạng “kiểm tra có cấu trúc” với danh sách kiểm tra từng bước và giao thức. Vào những năm 2000, với sự phổ biến của Git và các nhóm phân tán, việc đánh giá đã phát triển thành định dạng không đồng bộ thông qua Pull Request. GitHub (2008) đã biến PR thành thông lệ phổ biến. Code Review hiện đại là một quá trình không chính thức, không đồng bộ tập trung vào tốc độ và học hỏi, không phải quan liêu.

Các loại Code Review: phương pháp chính thức và không chính thức

Code Review được phân loại thành bốn loại chính dựa trên quy trình và sự tham gia. Chính thức (Đánh giá không đồng bộ) — kiểm tra qua MR/PR mà không có giao tiếp đồng bộ, phổ biến nhất trong các nhóm phân tán. Không chính thức — quick CR, khi một nhà phát triển tiếp cận người khác và yêu cầu xem mã trong 5 phút.

Theo Microsoft Research, 2023, lập trình cặp đôi (Pair Programming) có nghĩa là hai nhà phát triển làm việc trên một màn hình, mỗi dòng mã được viết theo thời gian thực với đánh giá ngay lập tức. Over-the-shoulder — một nhà phát triển nhìn vào màn hình của người khác và nhận xét mã mà không có quy trình chính thức. Walkthrough — tác giả mã dẫn dắt một nhóm nhà phát triển qua các thay đổi, giải thích từng quyết định.

Danh sách kiểm tra Code Review: cần kiểm tra gì trong mã

Danh sách kiểm tra Code Review giúp người đánh giá không bỏ qua các khía cạnh quan trọng. Danh mục đầu tiên — tính đúng đắn và kiến trúc: giải pháp có phù hợp với nhiệm vụ không, có độ phức tạp không cần thiết không, các mẫu có được chọn đúng không (MVP, MVVM, Clean Architecture). Danh mục thứ hai — phong cách và định dạng: mã có tuân theo phong cách mã của nhóm không (Kotlin Code Style, Swift Style Guide).

Theo Thoughtbot Code Review Guide, 2024, khối thứ ba — kiểm thử: các bài kiểm thử đơn vị đã được viết chưa, chúng có bao phủ các trường hợp biên không, các bài kiểm thử hiện có còn pass không. Thứ tư — bảo mật: có token, khóa API, SQL injection, rò rỉ bộ nhớ được mã hóa cứng không? Thứ năm — hiệu suất: coroutines/RxJava có được sử dụng đúng không, có chặn luồng UI không, có cấp phát quá mức không?

• Logic — tính đúng đắn của thuật toán, xử lý trường hợp biên và lỗi
• Kiến trúc — tuân thủ Clean Architecture, MVVM, phân tách trách nhiệm
• Phong cách mã — đặt tên, định dạng, nhất quán với dự án
• Kiểm thử — sự hiện diện của các bài kiểm thử đơn vị, tính đầy đủ và trạng thái xanh

Cách thực hiện Code Review: quy tắc cho người đánh giá

Code Review yêu cầu người đánh giá cân bằng giữa sự kỹ lưỡng và tốc độ. Quy tắc chính là kiểm tra mã theo từng phần nhỏ. Khối lượng tối ưu — 200–400 dòng thay đổi mỗi phiên. Theo Google Research (2022), việc đánh giá hơn 500 dòng sẽ mất hiệu quả: số lượng lỗi bị bỏ sót tăng tuyến tính với khối lượng thay đổi. Quy tắc thứ hai — bắt đầu với kiến trúc, sau đó logic, rồi chi tiết.

Theo SmartBear, 2025, các nhận xét phải cụ thể: không phải “ciái này tồi” mà là “phương thức này vi phạm SRP — hãy trích xuất logic xác thực vào một lớp riêng”. Mỗi nhận xét là một đề xuất cải tiến, không phải chỉ trích. Nếu mã đúng nhưng phong cách không phù hợp với sở thích của người đánh giá — hãy để nguyên không nhận xét. Người đánh giá nên phê duyệt giải pháp đúng đắn ngay cả khi họ sẽ viết khác đi.

Cách tiếp nhận Code Review: lời khuyên cho tác giả

Tiếp nhận Code Review là kỹ năng không kém phần quan trọng so với việc đánh giá mã. Tác giả nên cởi mở với các nhận xét và coi chúng là cơ hội để cải thiện giải pháp. Quy tắc đầu tiên — đừng coi nhận xét là chỉ trích cá nhân. Code Review kiểm tra mã, không phải nhà phát triển. Thứ hai — nếu nhận xét không rõ ràng, hãy yêu cầu làm rõ thay vì sửa ngay lập tức.

Theo LeadDev, 2024, trước khi gửi đi đánh giá, tác giả phải tự kiểm tra mã của mình: chạy kiểm thử, xem qua danh sách kiểm tra, đảm bảo không có log gỡ lỗi hoặc mã bị comment. MR/PR phải có mô tả rõ ràng với ngữ cảnh thay đổi. Mô tả càng tốt, việc đánh giá càng nhanh và hiệu quả.

An toàn tâm lý trong Code Review

Một khía cạnh quan trọng của Code Review là sự an toàn tâm lý trong nhóm. Nếu một nhà phát triển sợ bị chỉ trích gay gắt hoặc chế giễu, họ sẽ che giấu vấn đề thay vì thảo luận. Google Project Aristotle (2017) cho thấy: các nhóm có sự an toàn tâm lý cao thì năng suất hơn 25%. Nguyên tắc: chỉ trích mã, không phải tác giả; đặt câu hỏi thay vì cáo buộc; cảm ơn vì những giải pháp tốt.

Quy tắc quan trọng cho tác giả — đừng vội đóng các nhận xét. Nếu người đánh giá yêu cầu thay đổi, chúng phải được thực hiện, không chỉ trả lời “ok” và bỏ mặc không sửa. Sau khi thực hiện chỉnh sửa — yêu cầu đánh giá lại. GitLab và GitHub hỗ trợ Re-request Review để thông báo cho người đánh giá.

Tự động hóa Code Review: linters và phân tích tĩnh

Tự động hóa Code Review giảm tải cho các nhà phát triển bằng cách loại bỏ việc kiểm tra các quy tắc hình thức. Linters (ktlint, SwiftLint, ESLint) kiểm tra phong cách mã, định dạng và các lỗi cơ bản. Các trình phân tích tĩnh (Detekt, SonarQube, Infer) tìm các lỗi tiềm ẩn, rò rỉ bộ nhớ và vấn đề bảo mật trước khi mã đến được đánh giá bởi con người.

Theo detekt Documentation, 2024, trong đường ống CI/CD, linters và trình phân tích tự động chạy khi tạo MR/PR. Nếu kiểm tra thất bại, MR sẽ bị chặn bởi nút Merge. Điều này đảm bảo rằng mã đến được đánh giá con người đã vượt qua các kiểm tra cơ bản. Người đánh giá tập trung vào kiến trúc, logic và tính dễ đọc, không phải khoảng trống và thụt đầu dòng.

// Ví dụ cấu hình detekt cho dự án Android
build.gradle.kts (app):

detekt {
    config = files("detekt-config.yml")
    buildUponDefaultConfig = true
    allRules = false
    autoCorrect = true
    debug = false
    parallel = true
}

tasks.named("preMerge") {
    dependsOn("detekt")
    dependsOn("ktlintCheck")
}

Công cụ Code Review cho các dự án di động

Công cụ Code Review trong phát triển di động được chia thành dựa trên nền tảng (GitLab, GitHub, Bitbucket) và chuyên dụng (Gerrit, Reviewable, Crucible). GitLab và GitHub cung cấp chức năng tích hợp: so sánh diff, nhận xét dòng, luồng thảo luận, trạng thái Phê duyệt/Yêu cầu thay đổi, tích hợp CI/CD. Việc chọn công cụ phụ thuộc vào quy mô nhóm và chính sách đánh giá.

Theo GitLab Docs, 2025, đối với các nhóm lớn (50+ nhà phát triển), Gerrit cung cấp kiểm soát chặt chẽ hơn: xác minh CI bắt buộc trước khi hợp nhất, phê duyệt có trọng số (Verified + Code-Review) và quyền truy cập chi tiết. Đối với các nhóm nhỏ và vừa, GitLab và GitHub là lựa chọn tối ưu: việc cấu hình Required Approvals, Code Owners và Merge Checks chỉ mất vài phút.

• GitLab — Approvals, Code Owners, Merge Checks, MR Templates, CI/CD tích hợp
• GitHub — Pull Requests, CODEOWNERS, Required Reviews, GitHub Actions
• Bitbucket — Pull Requests cho Mercurial/Git, Approvals với nhận xét diff
• Gerrit — quy trình xác minh nghiêm ngặt, đánh giá có trọng số, tích hợp Jenkins

Các lỗi thường gặp trong Code Review

Các lỗi trong Code Review làm giảm hiệu quả và làm nhóm mất động lực. Thứ nhất — đánh giá khối lượng thay đổi quá lớn cùng một lúc. Khi MR chứa hơn 2000 dòng, người đánh giá bỏ qua tới 70% lỗi. Thứ hai — nhận xét chủ quan không dựa trên phong cách mã hoặc kiến trúc. Những nhận xét như “tôi sẽ viết khác” mà không có lý do không mang lại giá trị.

Theo Google Engineering Practices, 2024, lỗi thứ ba — bỏ qua kiểm thử. Nếu MR không bao gồm kiểm thử cho chức năng mới, người đánh giá phải yêu cầu chúng, không phê duyệt với “để sau”. Thứ tư — đánh giá vào cuối ngày hoặc cuối sprint khi sự tập trung bị phân tán. Thời gian tốt nhất cho đánh giá là nửa đầu ngày, dành 30–60 phút tập trung mà không chuyển đổi tác vụ.

Bảo mật đánh giá — lỗi phổ biến thứ năm: người đánh giá không kiểm tra mã có chứa bí mật được mã hóa cứng, WebView không an toàn với JavaScript hoặc thư viện dễ bị tổn thương hay không. Trong các dự án di động, điều này rất quan trọng: rò rỉ khóa API có thể xâm phạm toàn bộ backend.

Code Review trong các nhóm phân tán

Đối với các nhóm từ xa, Code Review là kênh truyền tải kiến thức chính. Định dạng không đồng bộ qua MR với thời hạn rõ ràng được khuyến nghị: tối đa 24 giờ cho đánh giá. Sử dụng bản ghi màn hình (Loom) cho các cuộc thảo luận kiến trúc phức tạp. Trong các nhóm phân tán, việc ghi lại các quyết định bằng văn bản trong nhận xét MR đặc biệt quan trọng để ngữ cảnh không bị mất khi thay đổi múi giờ.