Cải thiện code review: thực hành tốt nhất

• Cải thiện chất lượng mã: Một góc nhìn bên ngoài xác định các lỗi logic, lỗi tiềm ẩn, lỗ hổng bảo mật và các vấn đề hiệu suất mà tác giả có khả năng bỏ lỡ sau khi làm việc kéo dài trên cùng một codebase. Kết quả là phần mềm ổn định và đáng tin cậy hơn.
• Lan truyền kiến thức: Khi một nhà phát triển đánh giá mã của người khác, họ đồng thời học về các phương pháp mới, mẫu và quyết định cụ thể của dự án. Đây là một trong những cơ chế hiệu quả nhất cho việc chuyển giao kiến thức trong một nhóm — đặc biệt có giá trị cho việc giới thiệu và phân phối hiểu biết về các hệ thống con phức tạp.
• Đảm bảo tính nhất quán: Đánh giá mã thực thi phong cách mã hóa thống nhất, các mẫu cấu trúc và các quy ước kiến trúc. Tính nhất quán này rất quan trọng cho khả năng duy trì lâu dài, đặc biệt khi thành phần nhóm thay đổi theo thời gian.
• Tăng cường làm việc nhóm: Đánh giá mã là một hành động hợp tác tạo ra một môi trường nơi các nhà phát triển hỗ trợ sự phát triển của nhau. Kết quả là các nhóm gắn kết hơn và có hiệu suất cao hơn.
• Giảm nợ kỹ thuật: Các đánh giá thường xuyên xác định và giải quyết các quyết định có vấn đề sớm, trước khi chúng bị nhúng vào codebase và tốn kém để gỡ bỏ.
• Tăng trách nhiệm giải trình: Biết rằng mã sẽ được đồng nghiệp đánh giá tạo ra một động lực tự nhiên để tạo ra công việc cẩn thận hơn, dễ đọc và có cấu trúc tốt ngay từ đầu.

Sự sẵn sàng đánh giá

Chuẩn bị kỹ trước khi gửi mã đi đánh giá sẽ giảm công sức cho người review, đồng thời giúp khoảng thời gian họ bỏ ra đem lại nhiều giá trị hơn.

• Chia thành các phần nhỏ: Đừng gửi một thay đổi lớn trải khắp nhiều tệp và nhiều chức năng. Thay đổi càng nhỏ, càng tập trung thì càng dễ đọc và dễ hiểu, và con số nên nhắm tới là 100-200 dòng mã thay đổi cho mỗi pull request. Khi khối lượng lớn hơn, hãy tách nó thành những phần logic có thể review riêng rẽ.
• Tự đánh giá: Trước khi gửi, tác giả nên tự kiểm tra xem mã có biên dịch được không, test có chạy qua không, logic có hợp lý không, định dạng có thống nhất không và tên gọi có rõ ràng không. Làm vậy, người review đỡ phải góp ý những lỗi vặt và dồn sức cho các vấn đề thực chất.
• Mô tả đầy đủ: Viết mô tả pull request rõ ràng và đầy đủ: bạn đã thay đổi gì, vì sao thay đổi, giải quyết vấn đề nào và thay đổi đó gắn với mục tiêu dự án ra sao. Chỉ ra những chỗ cần người review chú ý đặc biệt, và nhớ gắn liên kết tới nhiệm vụ tương ứng trong hệ thống theo dõi.
• Xóa mã đã chú thích và không sử dụng: Pull request chỉ nên chứa mã thực sự chạy. Những đoạn bị comment lại hay biến không dùng tới chỉ tạo thêm nhiễu, khiến người đọc khó thấy đâu là phần đang cần review.
• Kiểm tra cục bộ: Mọi bài test tự động, cả unit test lẫn integration test, phải chạy qua trên máy của bạn trước khi gửi. Nếu cần kiểm tra thủ công bước nào, hãy ghi rõ trong mô tả pull request.

Văn hóa và giao tiếp

Chất lượng code review phụ thuộc vào cách con người trao đổi với nhau chứ không riêng quy trình kỹ thuật. Chính những chuẩn mực văn hóa trong nhóm quyết định việc review sẽ là một thói quen làm việc hiệu quả hay một nguồn va chạm giữa các thành viên.

• Hãy mang tính xây dựng, không phải chỉ trích: Nhận xét nhắm vào mã chứ không nhắm vào người viết. Những câu như "Chỗ này có thể cải thiện" hay "Nếu mình thử cách này thì sao?" đem lại nhiều kết quả hơn các lời phán xét dành cho tác giả.
• Đề xuất giải pháp, không chỉ vấn đề: Khi phát hiện một chỗ chưa ổn, việc gợi ý cách sửa cụ thể có ích hơn nhiều so với chỉ đánh dấu lỗi. Câu "Dùng forEach ở đây sẽ dễ đọc hơn" giúp tác giả biết phải làm gì, còn câu "Vòng lặp tệ quá" thì không.
• Hỏi, thay vì chỉ đạo: Những câu hỏi gợi mở dẫn tác giả tới lời giải, chẳng hạn "Bạn đã cân nhắc dùng mẫu Factory ở đây chưa?", thường có tác dụng hơn là sửa thẳng, nhất là khi bạn đang kèm các thành viên còn ít kinh nghiệm.
• Hãy cụ thể: Nhận xét cần rõ ràng và có căn cứ, tránh những câu chung chung. Khi phù hợp, hãy đưa ví dụ, gắn liên kết tới tài liệu hoặc dẫn chiếu tới tiêu chuẩn viết mã của nhóm.
• Chú ý đến giọng điệu: Qua văn bản, giọng điệu rất khó điều chỉnh. Hãy giữ sự lịch sự rõ ràng và nói thẳng ý mình ở những chỗ dễ bị hiểu lầm, như vậy nhận xét ít có nguy cơ bị hiểu thành chỉ trích cá nhân.
• Phản hồi các nhận xét: Tác giả nên trả lời sớm các câu hỏi và góp ý của người review, dù là giải thích lựa chọn của mình, nhận đề xuất hay nêu lý do cụ thể khi không đồng ý.
• Công nhận đóng góp của người đánh giá: Một lời ghi nhận thời gian và công sức người review đã bỏ ra sẽ làm tinh thần hợp tác bền hơn và giúp những lần review sau suôn sẻ hơn.

Trọng tâm của người đánh giá

Muốn review tốt, người đánh giá cần biết rõ mình phải xem những gì. Một danh sách kiểm tra cố định giúp không bỏ sót hạng mục quan trọng nào:

• Chức năng: Mã có làm đúng những gì nhiệm vụ yêu cầu không? Nó có giải quyết được vấn đề đã nêu không?
• Tính chính xác và logic: Có lỗi logic nào không? Các trường hợp biên có được xử lý đúng không? Các tình huống lỗi như null-pointer, chia cho 0 hay lỗi mạng đã được tính đến chưa?
• Bảo mật: Có lỗ hổng tiềm ẩn nào không, chẳng hạn SQL injection, XSS hay cách xử lý dữ liệu người dùng thiếu an toàn?
• Hiệu suất: Mã có tạo ra điểm nghẽn mới không? Có thuật toán nào sẽ chạy chậm tới mức không chấp nhận được khi dữ liệu đạt quy mô dự kiến không?
• Khả năng đọc và bảo trì: Người đọc lần đầu có hiểu được mã không? Tên biến, tên hàm, tên lớp có rõ nghĩa không? Những chỗ cần chú thích đã có chú thích chưa? Mã có theo đúng tiêu chuẩn viết mã của nhóm không?
• Kiểm thử: Chức năng mới đã có unit test chưa? Các bài test hiện có vẫn chạy qua chứ? Bản sửa lỗi có kèm test hồi quy không?
• Sự trùng lặp mã: Thay đổi này có lặp lại đoạn mã đã có ở nơi khác trong dự án không?
• Kiến trúc và thiết kế: Thay đổi có khớp với kiến trúc chung của dự án không? Mã mới có đưa vào anti-pattern nào không?

Người review không có nhiệm vụ viết lại mã theo gu riêng của mình: họ kiểm tra có phương pháp, đối chiếu với tiêu chuẩn chung của nhóm để tìm lỗi và những chỗ thật sự đáng cải thiện.

Công cụ và tự động hóa

Khi những phần việc lặp lại trong review như kiểm tra phong cách viết, chạy test hay quét lỗ hổng được giao cho máy, người review có thể thôi soát lỗi máy móc và tập trung đánh giá logic của mã.

1. Hệ thống kiểm soát phiên bản có hỗ trợ PR/MR: GitHub, GitLab và Bitbucket cho bạn một giao diện chung để tạo, xem và bình luận pull request hay merge request, với nhận xét gắn thẳng vào từng dòng mã.

2. Tích hợp CI/CD: Mỗi pull request nên tự động kích hoạt các bước kiểm tra sau:

• Bộ kiểm tra tự động: unit test, integration test và test chức năng chạy sau mỗi lần gửi mã
• Trình kiểm tra và định dạng mã: ESLint, Prettier, Black, SwiftLint tự áp tiêu chuẩn phong cách, nhờ vậy người review không còn phải nhắc chuyện định dạng
• Phân tích mã tĩnh: SonarQube, Bandit (Python), Semgrep chỉ ra lỗi tiềm ẩn, lỗ hổng và vấn đề chất lượng ngay trước khi con người bắt tay vào review
• Quét lỗ hổng phụ thuộc: tự động kiểm tra mức an toàn của các thư viện bên thứ ba

3. Mẫu pull request: Mẫu PR/MR thống nhất với các trường bắt buộc như mô tả thay đổi, liên kết nhiệm vụ, các test đã chạy và câu hỏi dành cho người review giúp tác giả cung cấp đủ bối cảnh để người đánh giá làm tốt phần việc của mình.

4. Nhận xét nội tuyến: Hầu hết các nền tảng cho phép gắn nhận xét vào đúng dòng mã, nên cuộc trao đổi luôn bám sát bối cảnh và người review chẳng phải ghi số dòng riêng ra.

Vòng lặp và học tập

Code review không phải một quy trình đứng yên, nó cần thay đổi theo nhóm và theo dự án khi cả hai cùng lớn lên.

• Cách tiếp cận lặp: Với thay đổi phức tạp, vài vòng nhận xét và sửa là chuyện bình thường. Mỗi vòng chỉ cần làm mã tốt hơn một bước, không nhất thiết phải đạt bản hoàn chỉnh ngay từ lần đầu.
• Hồi tưởng: Những buổi retro định kỳ dành riêng cho quy trình review, xem điều gì trơn tru, điều gì gây vướng, kiểu góp ý nào cứ lặp đi lặp lại, sẽ cho nhóm dữ liệu cần thiết để cải thiện quy trình có hệ thống.
• Học tập và cố vấn: Review là một trong những cách học hiệu quả nhất trong nhóm. Lập trình viên mới học được từ người review giàu kinh nghiệm, còn người giàu kinh nghiệm rèn được kỹ năng dẫn dắt. Nếu cùng một kiểu lỗi cứ xuất hiện trong mã của một người, có thể người đó cần được đào tạo bài bản hơn hoặc nên thử lập trình theo cặp.
• Sự thích ứng quy tắc: Tiêu chuẩn viết mã và tiêu chí review nên thay đổi khi dự án trưởng thành và thành phần nhóm đổi khác. Những quy tắc hợp với một nhóm nhỏ có thể phải sửa lại khi codebase phình to.
• Đánh giá kịp thời: Review chậm trễ khiến tác giả bị kẹt và làm tăng khả năng xung đột khi gộp mã. Một SLA nội bộ cho thời gian phản hồi review, thường là 24-48 giờ, giúp dòng công việc không bị đứt quãng.
• Bảo vệ thời gian tập trung: Hãy sắp xếp giờ review có trật tự, bằng các khối thời gian cố định hoặc chia đều cho nhiều người review, để việc đánh giá liên tục không cắt ngang những lúc cần làm việc sâu.

Các bài viết liên quan:

Nếu bạn cần một khung làm việc để trực quan hóa và sắp xếp ưu tiên nhiệm vụ, hãy đọc Tăng năng suất với Kanban: lời khuyên để quản lý nhiệm vụ hiệu quả.

Để nhận ra và ngăn tình trạng kiệt sức trước khi nó ảnh hưởng tới kết quả làm việc, hãy đọc Cách tránh kiệt sức: các chiến lược chính để duy trì sự khỏe mạnh.

Để trực quan hóa và quản lý tiến độ dự án bằng biểu đồ Gantt, hãy đọc Biểu đồ Gantt là gì? Hướng dẫn trực quan hóa và quản lý dòng thời gian dự án. Tìm hiểu thêm: Phần mềm Năng suất Cá nhân.

Kết luận

Khi nhóm chuẩn bị mã chu đáo trước mỗi lần gửi, giữ cách trao đổi mang tính xây dựng, dùng công cụ tự động và liên tục điều chỉnh quy trình, code review sẽ vừa là kênh truyền kiến thức vừa là lớp bảo đảm chất lượng, chứ không đơn thuần là một khâu soát lỗi. Lợi ích lâu dài của nó, gồm ít lỗi hơn, mã dễ bảo trì hơn và chuyên môn được chia đều trong nhóm, lớn đến đâu còn tùy vào việc các thực hành nêu trên được duy trì đều đặn tới mức nào.