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

Ý chính

Giới thiệu

Hãy tưởng tượng mã là nền móng cho tòa nhà của bạn. Nền móng càng vững chắc thì công trình càng bền lâu và đáng tin cậy. Code review hoạt động như một chuỗi các kiểm tra kỹ lưỡng nền móng này. Nó giúp:

• Nâng cao chất lượng mã. Đây là mục tiêu chính. Một cái nhìn từ bên ngoài giúp phát hiện lỗi logic, bug tiềm ẩn, các lỗ hổng bảo mật và vấn đề hiệu suất mà tác giả có thể bỏ sót. Kết quả là chúng ta có phần mềm ổn định và đáng tin cậy hơn. Đây là cải thiện trực tiếp về chất lượng mã.
• Chia sẻ kiến thức. Khi một lập trình viên xem xét mã của người khác, họ không chỉ tìm lỗi mà còn học được các phương pháp mới, mẫu thiết kế và các đặc điểm của dự án. Đây là cách quý giá để trao đổi kiến thức trong nhóm, giúp người mới nhanh hòa nhập và nâng cao năng lực chung.
• Đảm bảo sự đồng nhất. Code review giúp duy trì phong cách viết mã thống nhất, cấu trúc và các quyết định kiến trúc. Điều này rất quan trọng cho việc bảo trì dài hạn, nhất là khi nhiều người cùng làm việc trên dự án.
• Củng cố tinh thần làm việc nhóm. Code review là hành động hợp tác chứ không phải chỉ trích. Nó tạo ra môi trường mà các lập trình viên hỗ trợ nhau, giúp nhau phát triển. Điều này góp phần xây dựng đội nhóm làm việc hiệu quả và đoàn kết.
• Giảm nợ kỹ thuật. Các review thường xuyên giúp phát hiện và sửa các giải pháp không hiệu quả ngay từ đầu, ngăn ngừa tích tụ nợ kỹ thuật vốn có thể trở thành gánh nặng lớn theo thời gian.
• Tăng trách nhiệm. Biết rằng mã của bạn sẽ được đồng nghiệp xem xét sẽ tự nhiên thúc đẩy bạn viết mã chất lượng hơn, có suy nghĩ kỹ và dễ hiểu.

Sẵn sàng cho review

Trước khi gửi mã để kiểm tra, hãy đảm bảo mã đã sẵn sàng. Điều này giúp tiết kiệm thời gian cho người review và làm quá trình hiệu quả hơn.

• Chia nhỏ thành các phần nhỏ. Đừng gửi các thay đổi lớn bao gồm nhiều tệp và chức năng cùng lúc. Thay đổi càng nhỏ và tập trung thì càng dễ xem và hiểu. Kích thước tối ưu của pull request là 100-200 dòng mã thay đổi. Nếu thay đổi lớn hơn, hãy cố gắng chia thành các phần logic.
• Tự kiểm tra. Luôn tự "mini-review" trước khi gửi. Đảm bảo mã biên dịch được, các bài test pass và logic rõ ràng. Kiểm tra định dạng, thụt lề, tên biến và hàm. Hãy tưởng tượng bạn là người review.
• Mô tả chi tiết. Cung cấp mô tả rõ ràng và đầy đủ về pull request của bạn. Giải thích bạn đã làm gì, tại sao làm, những vấn đề được giải quyết và mối liên hệ với mục tiêu chung của dự án. Nêu rõ những điểm cần chú ý đặc biệt. Các liên kết tới task tracker là bắt buộc.
• Xóa mã bị chú thích hoặc không cần thiết. Pull request của bạn chỉ nên chứa mã sạch, hoạt động. Các đoạn mã bị chú thích hoặc biến không dùng làm mất tập trung và gây khó khăn cho việc đọc.
• Kiểm tra trên máy cục bộ. Đảm bảo tất cả các bài test tự động (unit test, tích hợp) đã pass trên máy của bạn. Nếu có test thủ công cần làm, hãy mô tả chúng.

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

Code review hiệu quả trước hết là về con người, rồi mới đến mã. Văn hóa và giao tiếp đúng đắn rất quan trọng để cải thiện quá trình review.

• Hãy mang tính xây dựng. Mục tiêu của người review là giúp đỡ chứ không phải phán xét. Tập trung vào mã, không phải người viết. Tránh các câu như "Bạn đã sai", thay vào đó hãy dùng "Có thể cải thiện phần này" hoặc "Nếu thử cách này thì sao?".
• Đề xuất giải pháp. Nếu bạn thấy thiếu sót, hãy thử gợi ý cách sửa hoặc cải thiện. "Thay vì dùng vòng for, dùng forEach sẽ dễ đọc hơn" sẽ hiệu quả hơn nhiều so với "Vòng for tệ".
• Hỏi thay vì ra lệnh. Đôi khi tốt hơn là đặt câu hỏi để khuyến khích tác giả tìm ra giải pháp đúng thay vì chỉ ra lỗi trực tiếp. Ví dụ: "Bạn đã cân nhắc sử dụng pattern Factory ở đây chưa?"
• Hạn chế nói chung chung. Các bình luận nên rõ ràng và đi thẳng vào vấn đề. Tránh những câu chung chung và khẳng định không có căn cứ. Đưa ví dụ, liên kết tài liệu hoặc tiêu chuẩn mã hóa.
• Chú ý đến giọng điệu. Trong giao tiếp viết, giọng điệu dễ bị hiểu lầm. Hãy lịch sự và tôn trọng. Dùng emoji hoặc trao đổi trực tiếp nếu có nguy cơ hiểu nhầm.
• Trả lời bình luận. Tác giả mã cần phản hồi kịp thời các câu hỏi và nhận xét của người review, giải thích quyết định của mình hoặc chấp nhận các thay đổi được đề xuất. Ngay cả khi không đồng ý, cũng hãy giải thích quan điểm của bạn.
• Cảm ơn. Tác giả nên cảm ơn người review vì thời gian và công sức họ bỏ ra. Điều này giúp tạo không khí tích cực.

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

Với vai trò là người đánh giá, bạn cần biết những điểm cần chú ý. Việc đánh giá mã hiệu quả đòi hỏi một phương pháp hệ thống.

• Chức năng. Trước tiên, hãy đảm bảo mã thực hiện đúng những gì được mong đợi. Nó có phù hợp với yêu cầu không? Có giải quyết được vấn đề không?
• Độ 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? Nếu có sự cố xảy ra (null-pointer, chia cho 0), lỗi có được xử lý đúng cách không?
• Bảo mật. Có các lỗ hổng tiềm ẩn không (SQL injection, XSS, xử lý dữ liệu người dùng không an toàn)?
• Hiệu suất. Mã có tạo ra nút thắt cổ chai không? Có thuật toán quá phức tạp gây ra vấn đề khi xử lý dữ liệu lớn không?
• Tính dễ đọc và bảo trì. Có dễ hiểu mã đang làm gì không? Các biến, hàm, lớp có được đặt tên rõ ràng không? Có đủ chú thích ở những nơi cần thiết (nhưng không phải mọi nơi)? Mã có tuân thủ tiêu chuẩn mã hóa của nhóm không?
• Kiểm thử. Có các unit test cho chức năng mới không? Các test hiện tại có chạy thành công không? Mã mới có thêm test hồi quy cho các lỗi đã sửa không?
• Trùng lặp mã. Có đoạn mã nào được thêm vào mà đã tồn tại ở nơi khác trong dự án không?
• Kiến trúc và thiết kế. Các thay đổi có phù hợp với kiến trúc tổng thể của dự án không? Mã mới có mang lại các anti-pattern không?

Hãy cố gắng tuân thủ checklist đánh giá để không bỏ sót điểm quan trọng. Và hãy nhớ rằng đánh giá mã không phải là viết lại mã theo cách của bạn mà là tìm kiếm những cải tiến và lỗi đáng kể.

Công cụ

Sử dụng các công cụ hiện đại để tự động hóa các tác vụ tẻ nhạt trong đánh giá mã. Điều này giúp bạn tập trung vào các khía cạnh logic phức tạp hơn.

1. Hệ thống quản lý phiên bản hỗ trợ PR/MR: GitHub, GitLab, Bitbucket cung cấp giao diện tiện lợi để tạo, xem và bình luận các yêu cầu hợp nhất (Pull Requests / Merge Requests). Đây là nền tảng tập trung cho mọi thảo luận.

2. CI/CD (Tích hợp liên tục / Triển khai liên tục): Thiết lập kiểm tra tự động cho mỗi yêu cầu hợp nhất. Điều này bao gồm:

• Kiểm thử tự động: Unit test, test tích hợp, test chức năng phải được chạy tự động.
• Lint và định dạng mã: Các công cụ như ESLint, Prettier, Black, SwiftLint tự động kiểm tra mã theo tiêu chuẩn và định dạng. Điều này giúp người đánh giá không phải kiểm tra lỗi thụt lề hay dấu ngoặc, từ đó tập trung vào logic.
• Phân tích mã tĩnh: Các công cụ như SonarQube, Bandit (cho Python), Semgrep phát hiện lỗi tiềm ẩn, lỗ hổng và vấn đề chất lượng mã ở giai đoạn sớm.
• Kiểm tra phụ thuộc: Công cụ phân tích lỗ hổng trong thư viện bên thứ ba.

3. Mẫu yêu cầu hợp nhất: Tạo mẫu chuẩn cho PR/MR bao gồm các trường bắt buộc: mô tả thay đổi, liên kết công việc, danh sách test đã chạy, và câu hỏi cho người đánh giá. Điều này đảm bảo tác giả cung cấp đầy đủ thông tin cần thiết.

4. Công cụ bình luận: Nhiều nền tảng cho phép để lại bình luận trực tiếp trên mã, gắn với dòng cụ thể. Điều này làm cho thảo luận mang tính ngữ cảnh hơn.

Sử dụng những công cụ này giúp tăng tốc và nâng cao hiệu quả đánh giá mã, giảm tải công việc tẻ nhạt cho lập trình viên và giúp họ tập trung vào những khía cạnh quan trọng thực sự.

Vòng lặp và học hỏi

Quá trình đánh giá mã không cố định. Nó phải phát triển cùng với nhóm và dự án.

• Phương pháp lặp lại. Đừng mong một lần đánh giá sẽ làm mã hoàn hảo. Có thể cần nhiều vòng bình luận và chỉnh sửa. Điều đó bình thường. Quan trọng là luôn hướng tới cải thiện liên tục.
• Họp hồi cứu. Thường xuyên tổ chức các buổi hồi cứu về quy trình đánh giá mã. Điều gì hoạt động tốt? Có thể cải thiện gì? Khó khăn nào phát sinh? Thu thập phản hồi từ tất cả thành viên tham gia.
• Đào tạo và hướng dẫn. Sử dụng đánh giá mã như một công cụ học tập. Các lập trình viên trẻ có thể học từ người có kinh nghiệm, người có kinh nghiệm cũng rèn luyện kỹ năng hướng dẫn. Nếu ai đó thường xuyên mắc cùng lỗi, có thể cần thêm buổi đào tạo hoặc lập trình cặp.
• Điều chỉnh quy tắc. Tiêu chuẩn mã hóa và quy tắc đánh giá không phải là bất biến. Chúng cần tiến hóa cùng dự án và sự phát triển của nhóm. Đừng ngại thay đổi nếu điều đó giúp nâng cao hiệu quả và chất lượng.
• Đừng trì hoãn. Hãy cố gắng thực hiện đánh giá kịp thời để không làm chậm tiến độ của tác giả mã. Yêu cầu hợp nhất càng để lâu, việc tích hợp càng khó và khả năng xung đột càng cao. Thiết lập SLA nội bộ cho thời gian đánh giá.
• Đừng làm gián đoạn dòng công việc. Đánh giá là phần quan trọng trong ngày, nhưng không nên làm gián đoạn hoàn toàn công việc chính của bạn. Có thể dành thời gian nhất định cho việc đánh giá hoặc phân chia giữa nhiều người đánh giá.

Cũng nên đọc:

Để hiểu sâu hơn về năng suất, hãy xem bài viết về tăng năng suất với Kanban: mẹo quản lý công việc hiệu quả. 

Để tránh kiệt sức, hãy đọc về cách tránh kiệt sức: các chiến lược duy trì sức khỏe tinh thần quan trọng.

Để lập kế hoạch tốt hơn, hãy tìm hiểu biểu đồ Gantt. Hướng dẫn sử dụng biểu đồ Gantt trong quản lý dự án.

Kết luận

Thực hành tốt nhất trong đánh giá mã là nền tảng cốt lõi cho phát triển phần mềm chất lượng cao. Áp dụng các khuyến nghị này sẽ biến đánh giá mã từ một công việc thường nhật thành một quá trình trao đổi kiến thức năng động, dẫn đến việc tạo ra các sản phẩm phần mềm đáng tin cậy, sạch sẽ và đổi mới hơn. Hãy bắt đầu áp dụng các nguyên tắc này ngay hôm nay và bạn sẽ thấy chất lượng mã và hiệu suất làm việc của nhóm được cải thiện rõ rệt.

Đề xuất đọc

“Code Complete”

Hướng dẫn chi tiết về viết mã sạch và dễ bảo trì với nhấn mạnh tầm quan trọng của thực hành đánh giá mã.

Trên Amazon

“The Art of Readable Code”

Cuốn sách dạy cách viết mã dễ đọc và thuận tiện cho việc đánh giá.

Trên Amazon

“Team Geek”

Tập trung vào khía cạnh con người trong phát triển phần mềm: hợp tác nhóm, giao tiếp hiệu quả và đánh giá mã chung.

Trên Amazon