Code review checklist - tập trung vào vấn đề quan trọng

Một checklist cho việc code review hay các quy tắc hướng dẫn code review là rất quan trọng. Nó giúp cho việc thực thi code review được nhanh chóng và chất lượng hơn trong team của bạn.

Có những nghiên cứu chỉ ra rằng sử dụng checklist để review code cho kết quả tốt hơn là không sử dụng checklist. Vì vậy, dù là lập trinh viên có kinh nghiệm hay mới bắt đầu bước chân vào con đường này cũng nên sử dụng checklist cho review code.

#Self review - tự review code của bạn

Code review checklist không chỉ dùng cho người review source code mà những lập trình viên viết ra những dòng code nên sử dụng checklist này để xem lại code của minh trước. Vỉ vậy, trước khi gửi code cho người review - reviewer, bạn cần đảm bảo các điều sau đây:

Code được biên dịch mà không có lỗi hoặc cảnh báo
Code đã vượt qua automation test ( unit, integration, sytem tests)
Kiểm tra kỹ lỗi chính tả và đã hoàn thành các comment, todo
Mô tả ngắn gọn về nội dung và lý do thay đổi code

Ngoài ra, người viết code cũng nên dùng cùng một checklist với reviewer.

#Checklist cho reviewer

Là một reviewer - người đánh giá code thì nhiệm vụ của bạn là tìm kiếm những vấn đề quan trọng trước tiên.

Microsoft đã nghiên cứu xem như thế nào là đánh giá tốt khi code review. Và họ nhận ra rằng những nhận xét về các vấn đề liên quan tới logic hay cấu trúc code quan trọng hơn nhiều là đánh giá tập trung vào những điều nhỏ nhặt.

Và đây là lúc mà code review checklist phát huy tác dụng. Một checklist tuyệt vời sẽ hướng sự chú ý của bạn tới những điều quan trọng và có giá trị nhất. Dưới đây là một checkist bao gồm 10 phần. Mỗi phần có vài câu hỏi mà bạn cần trả lời:

Implementation

Code có thực hiện được những gì bạn mong muốn - cái mà code cần phải làm không?
Có giải pháp nào đơn giản hơn?
Thay đổi này có thêm những dependency - phụ thuộc không cần thiết cho compile-time(thời gian biên dịch) và run-time hay không
Có API, library hay service nàop không cần dùng hay không?
Code có ở đúng abstraction level( mức độ trừu tượng) hay không?
Có code được module hoá không?
Code có đảm bảo tính dễ đọc, dễ bảo trì và không ảnh hưởng tới hiệu năng và bảo mật của hệ thống hay không?
Có function mới nào tương tự với một function trong codebase không? và vì sao không sử dụng function trong codebas
Có thể cải thiện source code bằng best practice hay design pattern hay không?
Code có tuân thủ theo các nguyên lý như SOLID, DRY, KISS... hay không?

2. Logic errors and bugs

Có tìm ra trường hợp nào mà code không hoạt động như dự kiến không?
Có bất kỳ input hay tác nhân bên ngoài hệ thống có thể gây lỗi không?

3. Error handling and logging

Bạn đã xử lý lỗi đúng cách?
Có nên bổ sung hay loại bỏ thông tin về logging hay debugging nào không?
Thông báo lỗi đã đủ thân thiện với người?
Đã đủ log được viết để việc debugging được dễ dàng hơn hay chưa?

4. Usability and Accessibility

Giải pháp có được thiết kế tốt từ góc độ sử dụng (UX) không?
API có tài liệu tốt hay không?
Có thể truy cập giao diện (UI) của giải pháp hay không?
API/UI có trực quan để sử dụng hay không?

5. Ethics and Morality (đạo đức và luân lý)

Có thay đổi nào làm vi phạm quyền riêng tư cho dữ liệu người dùng không?
Sự thay đổi có khai thác điểm yếu của con người hay không?
Code có ảnh hưởng hay dẫn đến sự tổn thương thể chất, tinh thần nào cho người dùng hay không?
Nếu code được thêm vào hoặc thay đổi các con người tương tác với nhau thì có biện pháp nào ngăn chặn/ báo cáo/ hạn chế các hành vi quấy rối không?
Thay đổi có dẫn đến loại bỏ một nhóm cụ thế người dùng hay không?
Việc thay đổi code có dẫn đến bất kỳ sai lệch cho thuật toán, AI hay học máy nào không?
Thay đổi có gây ra thành kiến nào về giới tính, chủng tộc, tôn giáo... nào không?

6. Testing and tesability ( kiểm thử và khả năng kiểm thử)

Code có thể được kiểm thử?
Đã có đủ automated test chưa? (unit/ integration/ system tests)?
Test hiện có cover đủ lượng code thay đổi không?
Có cần bổ sung thêm test case nào hay không?

7. Depedenncies ( phụ thuộc)

Đã cập nhật các tài liệu, hướng dẫn cài đặt, cấu hình liên quan chưa?
Thay đổi này có ảnh hưởng tạo ra sự phân nhánh hay tương thích ngược với các phần còn lại của hệ thống không?

8. Security and Data Privacy ( bảo mật và quyền riêng tư về dữ liệu)

Code có gây ra lỗ hổng bảo mật nào không?
Xác thực và uỷ quyền có được thực thi đúng cách?
Dữ liệu nhạy cảm của người dùng có được xử lý và lưu trữ an tôàn không? Có sử dụng mã hoá đúng cách không?
Code có tiết lộ thông tin bí mật nào của người dùng không? (username, key...)
Nếu code liên quan tới input của người dùng thì có giải quyết các vấn đề bảo mật liên quan hay chưa? (XSS, SQL injection, validation...)
Đã kiểm tra các dữ liệu lấy từ API ngoài hệ thống chưa?

9. Performance

Bạn có nghĩ code sẽ ảnh hưởng tiêu cực tới hiệu năng của hệ thống?
Bạn có nhìn ra cách để cải thiện hơn hiệu năng của code không?

10. Readability

Code có dễ hiểu không?
Có phần nào của code gây khó hiểu và vì sao?
Có thể cải thiện khả năng đọc bằng cách chia nhỏ method?
Có thể cải thiện khả năng đọc bằng tên của method/function hay biến?
Code đã nằm đúng file/folder/package chưa?
Có method nào cần cấu trúc lại để luồng chạy được trực quan hơn?
Luồng dữ liệu có dễ hiểu không?
Có comment nào thừa không?
Có comment nào cần sửa để truyền tải thông điệp tốt hơn?
Có cần bổ sung thêm comment nào để code dễ hiểu hơn không?
Có comment nào xoá thì làm code dễ đọc hơn không?
Có comment nào không đi kèm theo code?

11. Experts opinion ( ý kiến của chuyên gia)

Có cần xin ý kiến chuyên gia nào đó như chuyên gia về bảo mật hay UI/UX trước khi commit code?
Code có ảnh hưởng tới nhóm khác không? Nên báo cho họ về những thay đổi này chứ?

Trên đây là những vấn đề cấp bách nhất về code review. Hy vọng nó giúp bạn cải thiện được chất lượng code review của bản thân và team của mình.

Tài liệu tham khảo:
https://www.michaelagreiler.com/code-review-checklist-2/