Cách review code

Review Code không phải là nhiệm vụ ở bất kì vị trí nào, dù là Dev hay Senior Dev, Tech Lead đều cần phải thực hiện công việc này, để đảm bảo chất lượng Code.

Review Code hay đánh giá mã nguồn là thuật ngữ thể hiện một quy trình, với sự tham gia của một hoặc hai nhà phát triển thực hiện phấn tích code của các thành viên trong team.

Mục đích của việc này là để xác định các lỗi cú pháp, lỗi logic hay một số trường hợp ngoại lệ đã vô tình bị bỏ qua.

Việc Review Code cũng được xem như một quá trình thảo luận giữa các thành viên trong team về các dòng Code, thông qua đó, đưa ra được những góp ý hữu ích khiến mã lệnh trở nên chất lượng để phục vụ tốt hơn cho công việc.

Tại sao cần thực hiện Review Code?

• Cải thiện hiệu suất hoạt động của Code ở mức cao nhất.
• Giúp người thực hiện Review Code học được cách truyền đạt và góp ý cho người khác.
• Hạn chế số lỗi phát sinh khi chương trình được đưa vào sử dụng chính thức.
• Góp phần tạo ra một sản phẩm có phần thiết kế và triển khai thể hiện sự nhất quán.
• Hỗ trợ việc bảo trì sản phẩm về sau này, từ đó gia tăng thời gian sử dụng cho phần mềm.
• Mang lại một dự án chất lượng và thỏa mãn mọi yêu cầu mà khách hàng đặt ra.
• Giúp người thực hiện học hỏi thêm nhiều kinh nghiệm làm việc và lấp đầy “lỗ hổng” kiến thức cho bản thân.
• Giúp các thành viên trong team nhanh chóng nắm bắt được tiến độ hoạt động của công việc, biết được phần việc đó thuộc trách nhiệm của ai cũng như cách thức họ làm việc như thế nào.

Tiêu chuẩn chung của việc Review Code

Mục đích chung

• Không có khái niệm Code “Perfect” mà chỉ có Code “Better”.
• Đảm bảo tình trạng cho toàn bộ codebase sẽ được cải thiện theo từng mốc thời gian.
• Không có tính chính xác trong công nghệ, mà chỉ là chúng được lựa chọn sử dụng theo sở thích cá nhân của người thực hiện.

Mục đích cá nhân

• Các lỗi đã từng phát hiện cần tránh lặp lại.
• Phải có trách nhiệm với Pull Request đã từng Review.
• Có khả năng học hỏi và tiến bộ với mỗi Pull Request của bản thân.

Phương pháp hỗ trợ Review Code trở nên hiệu quả

Muốn quá trình Review Code trở nên hiệu quả sau mỗi lần thực hiện, bạn cần phải là một người có những đức tính sau:

• Luôn sẵn sàng chia sẻ kiến thức của mình đến mọi người.
• Chỉ đưa ra những ý kiến mang tính xây dựng và hoàn thiện.
• Không mượn việc Review Code cho mục đích công kích người khác.
• Sẵn sàng tiếp thu những ý kiến đóng góp hữu ích từ mọi người, để hoàn thiện khả năng làm việc của mình tốt hơn mỗi ngày.
• Tôn trọng và lắng nghe những ý kiến của các thành viên trong team.
• Biết cách mô tả một vấn đề một cách rõ ràng và chi tiết, giúp người Review Code hiểu rõ về việc chúng ta làm, giúp quá trình đánh giá trở nên thuận lợi và ít tốn thời gian hơn. Để có bài trình bày vấn đề rõ ràng, bạn có thể dựa trên các yếu tố sau:
  • Mục đích của việc tạo vấn đề là gì?
  • Yêu cầu và mong muốn đạt được của vấn đề là gì?
  • Cách xử lý vấn đề ra sao?
  • Cần những tham khảo nào?

Thành công và hạnh phúc nằm trong bạn. Quyết tâm hạnh phúc, và niềm vui sẽ đi cùng bạn để hình thành đạo quân bất khả chiến bại chống lại nghịch cảnh. Luôn rèn luyện khả năng tự học để hiểu biết thêm về lĩnh vực Công Nghệ Thông Tin đầy bí ẩn này.

Review code là công việc sẽ diễn ra ngay sau khi những thao tác kiểm tra tự động đã được thực hiện thành công, nhưng trước khi merge vào nhánh làm việc chính.

Mục đích chính

Khi Review Code, bạn không ngừng đặt những câu hỏi như "Liệu mã này có đúng như ý tưởng của tác giả hay không?" hoặc "Mã được dùng để hoàn thành mục đích này có chính xác chưa?"

Ngoài ra nên nhớ rằng,  Function và class nên tồn tại bởi một lý do nhất định. Vì nếu nó không rõ ràng, đây có thể là một dấu hiệu cho thấy code đang xảy ra vấn đề, cần phải chỉnh sửa hay bổ sung thêm comment hoặc test.

Quy trình thực hiện

Hãy tập trung vào hướng giải quyết vấn đề, sau đó tìm điểm khác biệt, đồng thời xác định những trường hợp khác nhau của mã như chiều dài và chức năng.

Nếu xuất hiện những chỗ cần trừu tượng hóa thì có thể tái sử dụng trong nhiều bối cảnh khác nhau.

Đồng thời, hãy suy nghĩ thêm về các thư viện hoặc code sẵn có. Bởi vì, mỗi khi ai đó tái thực hiện chức năng đó, có thể họ không biết nó đã từng tồn tại hoặc bị sao chép. Đối với trường hợp này, người Review Code cần xác định lại mục đích cũng như nhắc nhở về việc chức năng và thư viện tương tự  đã được xử lý rồi.

Đặc biệt, mọi thay đổi hay chỉnh sửa đều phải chấp hành những pattern mà toàn nhóm đã thống nhất.

Ngoài ra, một phần của sự thay đổi còn phụ thuộc vào thời gian biên dịch. Do, đa phần các Developer đều muốn giữ các sản phẩm ở dạng liên kết "hờ" và lỏng lẻo.

Tính dễ đọc và phong cách sử dụng

Dựa vào vốn kiến thức của chính mình, suy xét về thời gian nắm bắt các khái niệm. Là tên biến và phương thức tiện cho việc theo dõi? Hay việc đặt tên đã nhất quán chưa?

Kiểm tra quy định coding guidelines và coding style của toàn thành phẩm.  Đặc biệt, nó có phù hợp với dự án về style, API conventions hay không? 

Bên cạnh đó, hãy kiểm tra TODO của code, vì nó sẽ chồng chất code và trở nên cũ kĩ theo thời gian. Hãy yêu cầu Developer phụ trách gửi một ticket các vấn đề về GitHub hoặc JIRA và đính kèm số vấn đề vào TODO.

Bảo mật

Hãy chắc chắn là những thông tin như API endpoint, token trùng khớp với bên thứ ba hoặc các cấu hình đặc biệt ... không xuất hiện trong PR.

Bình luận

Hãy đánh giá một cách súc tích, khách quan. Đồng thời, chỉ nên phê bình code, chứ không đụng đến tác giả. Hoặc thắc mắc bất kỳ vấn đề nào, hãy hỏi trực tiếp coder.

Nên tránh những đại từ sở hữu, đặc biệt là kết hợp với nhiều đánh giá độc đoán.

Hãy cố gắng làm rõ cũng như phân biệt giữa các đề xuất, thay đổi bắt buộc và những điểm cần thảo luận để xác minh.

"A little more persistence, a little more effort, and what seemed hopeless failure may turn to glorious success". Đây là châm ngôn tôi yêu thích nhất, để từng ngày nỗ lực theo đuổi ngành công nghệ thông tin.