"Best Practices" Khi Thực Hiện Code Review

Chào các bạn! Qua những trải nghiệm mình đúc kết được trong quá trình làm việc thì nhận thấy việc thực hiện code review là rất quan trọng. Tuy nhiên, theo bản năng con người thì chúng ta thường không lên một timeline hay kế hoạch rõ ràng trước khi review code. Thay vào đó, chúng ta sẽ làm theo những bước mà bản thân cho là đúng. Vậy với bài viết này, mình muốn mô tả trình tự các bước "best practices" khi chúng ta thực hiện code review như thế nào cho đúng nhé!

1. Đặt mục tiêu rõ ràng cho việc review

Mỗi lần review, cần biết mình đang tìm kiếm gì: cải thiện hiệu suất, đảm bảo tuân thủ chuẩn mã hoá, hay tìm lỗi cụ thể.

2. Không chỉ trách lỗi, hãy đề xuất giải pháp

Khi phát hiện một vấn đề, đừng chỉ dừng lại ở việc chỉ ra nó. Hãy đề xuất giải pháp hoặc thảo luận để tìm ra cách tốt nhất để giải quyết.

3. Sử dụng công cụ tự động

Hãy kết hợp việc sử dụng các công cụ phân tích mã nguồn tự động, chẳng hạn như linters hoặc static analysis tools, để giảm bớt nhiệm vụ cho người review.

3.1. Linters

Khái niệm:

• Linters là công cụ kiểm tra mã nguồn để phát hiện và báo cáo về các vấn đề liên quan đến coding standards, coding style và cú pháp.

Ví dụ về các linters phổ biến:

• ESLint cho JavaScript.

• Pylint cho Python.

• RuboCop cho Ruby.

• Stylelint cho CSS.

Ưu điểm của linters:

• Nhanh chóng và tự động kiểm tra mã nguồn.

• Có thể dễ dàng tùy chỉnh quy tắc linter để phù hợp với chuẩn code của team.

• Giúp đội ngũ lập trình tuân thủ một coding style nhất quán.

• Cảnh báo về các lỗi cú pháp trước khi mã nguồn được chạy.

3.2. Static Analysis Tools

Khái niệm:

• Công cụ này phân tích mã nguồn mà không cần thực thi nó. Mục đích là tìm kiếm các vấn đề tiềm ẩn như lỗi logic, điểm yếu về bảo mật, hoặc vi phạm best practices của ngôn ngữ lập trình.

Ví dụ về các static analysis tools phổ biến:

• SonarQube: Hỗ trợ nhiều ngôn ngữ, giúp phát hiện lỗi và điểm yếu về bảo mật.

• Checkmarx: Tập trung vào phát hiện lỗ hổng bảo mật.

• Coverity: Cung cấp phân tích mã nguồn độ sâu và chi tiết.

Ưu điểm của static analysis tools:

• Phát hiện các lỗi phức tạp mà linters không thể nhận biết.

• Tập trung vào việc tối ưu hóa hiệu suất và bảo mật.

• Cung cấp cái nhìn tổng quát về chất lượng mã nguồn thông qua metrics và báo cáo.

Có thể nói rằng, kết hợp linters và static analysis tools trong quá trình phát triển giúp nâng cao chất lượng mã nguồn và giảm thiểu rủi ro. Khi sử dụng đúng cách, chúng có thể giảm đáng kể số lượng lỗi và vấn đề tiềm ẩn, giúp việc code review trở nên hiệu quả và dễ dàng hơn.

Ngoài ra, chúng ta đã quen thuộc với GitHub, GitLab, Bitbucket - những dịch vụ quản lý mã nguồn phổ biến. Nhưng ngoài việc chỉ quản lý mã nguồn, những dịch vụ này còn hỗ trợ một quy trình code review hiệu quả. Dưới đây là cách mà các công cụ này giúp quản lý và tự động hóa quá trình review:

3.3. Pull/Merge Requests (PR/MR)

• Khi một lập trình viên muốn đưa thay đổi vào mã nguồn chính, họ sẽ tạo ra một PR/MR.

• PR/MR sẽ hiển thị toàn bộ sự khác biệt giữa những thay đổi mới so với mã nguồn gốc.

• Đồng thời, nó cũng là nơi mà các thành viên khác trong đội ngũ có thể bình luận, đặt câu hỏi, và thảo luận về những thay đổi đó.

3.4. Tích hợp Continuous Integration (CI)

• CI là quá trình tự động hóa việc kiểm tra mã nguồn sau mỗi lần thay đổi.

• Với GitHub Actions, GitLab CI/CD, Bitbucket Pipelines,... bạn có thể thiết lập để tự động chạy linters, unit tests, và các kiểm tra khác mỗi khi có PR/MR mới.

• Nhờ đó, nếu có lỗi hay vi phạm chuẩn coding, team có thể biết ngay từ phần feedback của CI trước khi thực hiện review chi tiết.

3.5. Bình luận và Thảo luận

• Trong mỗi PR/MR, người review có thể trực tiếp đặt câu hỏi, bình luận, hoặc đề xuất thay đổi ở mỗi dòng code cụ thể.

• Điều này giúp việc trao đổi thông tin trở nên dễ dàng và rõ ràng.

3.6. Yêu cầu Review từ Các Thành Viên Cụ Thể

• Trong một số trường hợp, bạn có thể chỉ định những người cụ thể để thực hiện review cho PR/MR của mình.

• Điều này giúp đảm bảo rằng những thay đổi được xem xét bởi những người có kiến thức và kinh nghiệm phù hợp.

3.7. Quyền Truy Cập và Phê Duyệt

• Bạn có thể thiết lập quyền truy cập để chỉ cho phép những thay đổi đã được review và phê duyệt mới được hợp nhất vào mã nguồn chính.

• Điều này giúp đảm bảo rằng mỗi thay đổi được đưa vào mã nguồn đều đã được kiểm tra và đảm bảo chất lượng.

• Những dịch vụ quản lý mã nguồn như GitHub, GitLab, và Bitbucket không chỉ giúp quản lý code mà còn cung cấp nền tảng hoàn hảo để thực hiện quy trình code review một cách hiệu quả, minh bạch và dễ dàng hợp tác giữa các thành viên trong team.

4. Tập trung vào chất lượng mã chứ không phải người viết

Đối xử công bằng và không đánh giá cá nhân. Mục tiêu là cải thiện mã, không phải chỉ trích người viết.

5. Review thường xuyên và không quá nhiều code cùng một lúc

Việc review hàng trăm dòng code cùng một lúc có thể gây mệt mỏi và làm giảm hiệu suất. Hãy chia nhỏ và thực hiện review thường xuyên.

6. Khuyến khích việc đặt câu hỏi thay vì chỉ định lỗi

Khi thực hiện code review, việc đặt câu hỏi thay vì chỉ ra lỗi có thể giúp tạo nên một không gian thảo luận hợp tác và tích cực hơn. Dưới đây là một số gợi ý cho những câu hỏi mà bạn có thể sử dụng:

Về Logic và Chức Năng:

• "Có lý do gì khiến bạn lựa chọn cách tiếp cận này cho vấn đề này không?"

• "Làm thế nào mà phần code này xử lý trường hợp khi [điều kiện cụ thể]?"

• "Bạn nghĩ việc thêm kiểm tra cho [trường hợp cụ thể] có cần thiết không?"

Về Hiệu suất:

• "Bạn nghĩ việc tối ưu hóa đoạn code này như thế nào có thể giúp nâng cao hiệu suất?"

• "Có cách nào để giảm độ phức tạp của phần này không?"

Về Đọc hiểu và Rõ ràng:

• "Bạn có thể giải thích mục đích của hàm/đoạn code này giúp mình được không?"

• "Nếu thêm một số bình luận hoặc tài liệu hướng dẫn ở đây, bạn nghĩ sẽ giúp rõ ràng hơn không?"

Về Cấu trúc và Kiến trúc:

• "Tại sao bạn quyết định chia tách chức năng này thành nhiều hàm/phương thức như vậy?"

• "Bạn nghĩ làm thế nào để tái sử dụng code ở phần này sẽ hiệu quả hơn?"

Về Bảo mật:

• "Có cách nào để đảm bảo dữ liệu ở đây được bảo mật không?"

• "Việc xử lý dữ liệu như này có thể gây ra rủi ro về bảo mật không?"

Về Testing:

• "Bạn đã thử nghiệm trường hợp nào cho đoạn code này chưa?"

• "Đoạn code này có ảnh hưởng gì đến các unit tests hiện tại không?"

Nhìn chung, mục tiêu của việc đặt câu hỏi là giúp người viết code suy nghĩ về quyết định của mình và khám phá ra giải pháp tốt nhất, thay vì chỉ đơn thuần nhận phản hồi dạng chỉ trích.

7. Xác định và tuân thủ những quy tắc cụ thể

Team nên có một bộ guidelines cho việc code review để mọi người đều biết họ cần chú ý đến những gì.

Dưới đây là một số yếu tố quan trọng mà một bộ guidelines cho việc code review nên bao gồm:

7.1. Mục tiêu của Code Review:

• Xác định rõ ràng mục tiêu của việc review: ví dụ như phát hiện lỗi, đảm bảo tuân thủ chuẩn coding, tối ưu hóa hiệu suất, hay đảm bảo bảo mật.

7.2. Phạm vi Review:

• Xác định những phần mã nguồn nào nên được review và những phần nào không cần thiết.

• Định nghĩa độ sâu của việc review: liệu team chỉ review logic và chức năng, hay cả coding style và best practices.

7.3. Thời gian Response:

• Đặt ra một khoảng thời gian hợp lý mà người review cần phản hồi lại. Điều này giúp đảm bảo tiến độ của dự án.

7.4. Giao tiếp trong Quá trình Review:

• Khuyến khích việc giao tiếp tích cực, thân thiện và xây dựng.

• Hướng dẫn cách đưa ra phản hồi một cách rõ ràng, khách quan và không gây xúc phạm.

7.5. Cách Xử lý Ý kiến Khác biệt:

• Nếu có sự khác biệt trong quan điểm giữa người viết code và người review, guidelines nên cung cấp một quy trình để giải quyết mâu thuẫn một cách hợp tác và xây dựng.

7.6. Công cụ và Tiêu chuẩn:

• Liệt kê những công cụ hỗ trợ code review mà team sử dụng (như linters, static analysis tools, ...)

• Định nghĩa rõ ràng các tiêu chuẩn và best practices mà team tuân theo.

7. Đào tạo và Phát triển Kỹ năng:

• Khuyến khích việc đào tạo và phát triển kỹ năng review cho các thành viên mới và cả những người có kinh nghiệm.

• Cung cấp tài nguyên, bài giảng, và hướng dẫn về cách thực hiện code review hiệu quả.

• Một bộ guidelines cho việc code review không chỉ giúp đảm bảo chất lượng của mã nguồn, mà còn tạo ra một môi trường làm việc tích cực và hợp tác. Nó giúp mọi người trong team biết họ cần làm gì, chú ý đến điều gì và kỳ vọng gì từ quá trình review.

8. Đảm bảo có sự tham gia của nhiều người

Điều này giúp đảm bảo việc nhận được nhiều góc nhìn và kiến thức chuyên môn khác nhau. Dưới đây là lý do và lợi ích của việc đảm bảo sự tham gia của nhiêu người:

8.1. Phát hiện Lỗi Nhanh Chóng:

• Khi nhiều người cùng review, mỗi người có góc nhìn và kinh nghiệm khác nhau. Họ có thể nhận biết các vấn đề từ các khía cạnh khác nhau, giúp phát hiện lỗi một cách hiệu quả hơn.

8.2. Chia sẻ Kiến thức:

• Thông qua việc thảo luận và phản hồi, các thành viên trong team có cơ hội học hỏi từ nhau. Điều này giúp tăng cường kiến thức chung và kỹ năng lập trình của cả nhóm.

8.3. Tăng Cường Tính Đồng nhất:

• Khi nhiều người tham gia review, sẽ giúp đảm bảo rằng mã nguồn tuân thủ các chuẩn và best practices mà team đã đề ra. Điều này giúp mã nguồn trở nên đồng nhất và dễ bảo trì hơn.

8.4. Giảm thiểu Tập trung Kiến thức:

• Một lợi ích quan trọng khác của việc có nhiều người tham gia review là giảm thiểu việc một số người trong team trở thành "điểm chết" (point of failure) - những người chỉ mình họ biết về một phần nhất định của mã nguồn. Khi họ vắng mặt hoặc rời bỏ dự án, team có thể gặp khó khăn. Sự tham gia của nhiều người giúp kiến thức được phân tán và chia sẻ rộng rãi hơn.

8.5. Xây dựng Văn hóa Hợp tác:

• Khi tạo điều kiện cho nhiều người tham gia vào quá trình review, bạn đang khuyến khích một văn hóa làm việc hợp tác, nơi mọi người cùng nhau đóng góp và giúp đỡ nhau để đạt được mục tiêu chung.

• Đảm bảo sự tham gia của nhiều người trong quá trình code review không chỉ giúp cải thiện chất lượng mã nguồn, mà còn tạo ra một môi trường làm việc hợp tác và tăng cường khả năng bảo trì và phát triển dự án trong tương lai.

9. Tạo điều kiện cho việc thảo luận trực tiếp

Đôi khi, một cuộc thảo luận trực tiếp (qua điện thoại, video call hoặc trực tiếp) sẽ hiệu quả hơn nhiều so với việc bình luận trực tuyến.

10. Coi việc review như một cơ hội học hỏi

Đối với người được review, đây là cơ hội nhận feedback và học hỏi. Đối với người review, đây là cơ hội nâng cao kiến thức và nhận biết các phong cách lập trình khác nhau.

Nhớ rằng, việc thực hiện code review không chỉ là việc tìm và chỉ ra lỗi. Đó còn là một quá trình học hỏi và phát triển chung cho cả team. Hãy coi việc này như một cơ hội để cùng nhau nâng cao chất lượng mã nguồn và tạo ra sản phẩm tốt nhất có thể. Nếu bạn đang tìm kiếm cho mình môi trường tinh thần teamwork cao và có cơ hội tham gia vào các dự án thực tiễn của công ty thì hãy xem xét ứng tuyển tại ITBee Solutions như một sự lựa chọn lý tưởng.