1. Code Review là gì?
Code Review theo nghĩa tiếng Việt có thể hiểu đơn giản là mã xem lại – đây là một thuật ngữ thuộc nhóm Technology Terms – Công nghệ thông tin. Cụ thể, Code Review sẽ hoạt động nhằm xem xét lại quá trình thực hiện mã code nhằm mục đích là tìm kiếm ra các lỗ hổng, những lỗi mắc phải trong mã tổng thể. Mã tổng thể ở đây có thể là mã tĩnh hoặc mã động. Khi mã được phân tích dựa vào sai sót và lỗi cú pháp thì nó được xem xét mã tĩnh. Còn khi thực thi để so sánh các kết quả thực tế với kết quả mong đợi thì nó được xem là mã năng động.
Các mã này có thể có lỗi về cú pháp giống như một biến undefined hoặc là sử dụng từ khóa không đúng cách, mắc các lỗi về logic, nơi mà cú pháp thích hợp được sử dụng nhưng lại không mang đến kết quả chính xác do 1 lỗ hổng nào đó trong thuật toán. Các lỗi cú pháp có thể được xử lý bằng cachs sử dụng xem xét mã tĩnh, trong khi đó các lỗi logic thì có thể được xử lý bằng việc xem xét các mã năng động.
Đồng thời, mã rà soát được thực hiện thường xuyên trong giai đoạn thiết kế mã. Một cuộc họp kiểm toán là heldto xác định về độ tin cậy các mã và nếu có thể thì sẽ lựa chọn thay thế tốt hơn cho các mã hiện tại. Mã thường được xem xét với an ninh, bảo trì, độ tin cậy, tính linh hoạt, khả năng hội nhập, upgradability,… trong quá trình Code Review.
Tham khảo: Tìm việc làm IT phần mềm tại địa điểm và mức lương mà bạn mong muốn nhanh chóng và đơn giản.
2. Đặc trưng cơ bản của Code Review
Đối với Code Review trong công nghệ thông tin hiện nay thì bao gồm có một số đặc trưng cơ bản cũng chính là các lợi ích mà quá trình này mang lại đó là:
- Đảm bảo về clean code: đây là một trong số những phương pháp cáo thể giữ cho code luôn sạch. Khi nhiều người cùng review cho nhau thì sẽ phát hiện ra các lỗi nhanh và hiệu quả hơn, đồng thời có thể biết được chỗ nào cần áp dụng design pattern hay các chức năng A, module B đang bị lặp lại code quá nhiều lần,… Toàn bộ những vấn đề đó đều rất dễ xảy ra mà ngay cả các lập trình viên giỏi, có kinh nghiệm cũng không thể tránh khỏi.
- Phát hiện ra các lỗi sớm: đã bao giờ bạn tự tin rằng chức năng mà mình phát triển ra luôn hoạt động tốt, test rất nhiều lần nhưng không phát hiện ra lỗi. Tuy nhiên, rất có thể bạn đang test thiếu testcase mà thôi. Và nếu như nhiều người cùng nhìn vào đoạn code thì sẽ nhanh chóng phát hiện ra các lỗi để xử lý kịp thời.
- Nỗ lực đảm bảo chất lượng của code: khi 1 lập trình viên biết rằng đoạn code của mình sẽ bị xem xét lại và bắt lỗi hay thậm chí là bị chỉ trích bởi những người giỏi hơn thì chắc chắn lập trình viên đó sẽ cố gắng trong công việc, đảm bảo đoạn code đó chạy đúng, tối ưu nhất. Điều này đồng nghĩa với việc lập trình viên đang cố gắng để viết code tốt hơn. Ngay cả khi bạn thất bại trong việc viết ra 1 đoạn code chuẩn thì vẫn được hướng dẫn đầy đủ từ chính người review đó và cuối cùng cũng sẽ có đoạn code chuẩn chỉnh nhất đưa vào hệ thống.
- Code Review giúp đảm bảo code có thể dễ đọc hơn: 1 lập trình viên đã có kinh nghiệm chắc chắn sẽ e ngại khi nhìn lại các đoạn code thời sinh viên hay khi mới vào nghề. Bởi code khi đó không theo 1 quy chuẩn nào cụ thể, điều này cũng khiến cho vấn đề bảo trì gặp nhiều khó khăn hơn bởi bạn phải đọc lại rất nhiều lần. Do đó, Code Review sẽ “ép” các lập trình viên phải viết code theo khuôn khổ thích hợp, làm sao để các đoạn code dễ đọc hơn.
- Việc Code Review còn góp phần chia sẻ kiến thức từ những người review đến cho lập trình viên, theo đó họ sẽ có thể học hỏi thêm được nhiều kiến thức mới, Riêng với các reviewer thì đây cũng là cơ hội để ôn luyện lại các kiến thức cần thiết.
- Nâng cao tư duy hệ thống: trong các phiên Code Review hiện nay thì lập trình viên sẽ có nhiều cơ hội để tiếp cận với các thành phần của hệ thống. Điều này sẽ giúp cho họ có được cái nhìn toàn diện nhất về hệ thống cũng như các phương pháp thiết kế được áp dụng ở thực tế đối với quá trình code.
- Làm việc với các quy chuẩn của nhóm: đây vừa là nhiệm vụ và cũng là quyền lợi đối với các tân lập trình viên. Là nhiệm vụ vì tất các các thành viên trong một nhóm đều cần phải tuân thủ theo đúng quy chuẩn để đảm bảo về hiệu suất công việc, nhờ đó họ có thể nâng cao hơn về kỹ năng, phong cách làm việc của mình.
3. Sự khác nhau giữa Code Review và Secure Code Review
Rất nhiều người hiện nay nhầm lẫn giữa Code Review và Secure Code Review. Tuy nhiên, đây lại là 2 khái niệm hoàn toàn khác nhau và sử dụng cho mục đích khác nhau. Code Review là đánh giá về chất lượng của phần mềm, còn Secure Code Review là thực hiện đánh giá về chất lượng mã nguồn.
Cụ thể, mô hình trưởng thành khả năng – mô hình quy trình được công nhận rộng rãi để đo lường về các quy trình phát triển của 1 tổ chức phần mềm. Nó bao gồm có từ cấp độ 1 – nơi các quy trình phát triển là đặc biệt, không ổn định, không thể lặp lại. Tuy nhiên đến cấp độ 5 – nơi các quy trình phát triển được tổ chức tốt và được ghi lại, liên tục cải tiến. Như vậy, giả định rằng các quy trình phát triển của một công ty sẽ bắt đầu ở cấp độ 1 và sẽ trở nên rõ ràng, có thể lặp lại, thường chuyên nghiệp hơn khi tổ chức, cải tiến ở cấp độ 5. Và việc giới thiệu về khả năng thực hiện xem xét mã được đưa vào khi tổ chức đã đạt đến cấp độ 2 hoặc cấp độ 3.
Có thể thấy, Code Review là một sự cải tiến đối với thực tiễn Secure Code Review, trong đó cấu trúc của quá trình xem xét đặt các cân nhắc bảo mật như là tiêu chuẩn bảo mật công ty sẽ ở vị trí hàng đầu trong quá trình đưa ra quyết định. Nhiều quyết định trong số này sẽ được giải thích, cố gắng đảm bảo quá trình xem xét có thể bao gồm các rủi ro bảo mật trong cơ sở mã. Ví dụ như là đảm bảo mã có rủi ro được xem xét kỹ lưỡng, sâu hơn, người đánh giá có bối cảnh bảo mật chính xác khi xem xét các mã và đảm bảo người đánh giá cũng có các kỹ năng cần thiết, đủ kiến thức để mã hóa an toàn các mã code.
Gợi ý: Developer là gì? Cơ hội nào cho lập trình viên chuyên nghiệp?
4. Cách để thực hiện Code Review nhanh chóng, hiệu quả
Để có thể thực hiện Code Review một cách nhanh chóng, hiệu quả thì các lập trình viên cũng như người review cần phải đảm bảo một số yêu cầu như sau:
- Xác định lại các điều kiện để tạo pull request:
+ Đảm bảo rằng code build phải đạt được thành công
+ Cần đọc và chú thích các mã code
+ Cần build và chạy test các đoạn code
+ Toàn bộ code trong phần codebase sẽ đều phải được test
.jpg)
+ Tiến hành lick ticket/issue vào pull request.
+ Không chuyển cho người review khi mà chưa đảm bảo được những điều kiện đã nêu ở trên.
- Trách nhiệm của người được review: mặc dù người review là người cuối cùng có quyền được merge pull request, tuy nhiên với những chỉ dẫn dưới đây thì người được review có thể sẽ giảm bớt những rủi ro lâu dài:
+ Giao tiếp với reviewer và cụ thể là đưa cho họ các yêu cầu về task của bạn và đặt mình ở vị trí của những reviewer để tự hỏi liệu mình làm như thế đã đủ và đúng hay chưa?
+ Tạo các pull request nhỏ để có thể tăng tốc độ review. Cụ thể là việc giữ cho các pull request đủ nhỏ để bạn có thể thực hiện các vòng lặp review – fix comment một cách nhanh chóng, chính xác. Tóm lại, các bạn thực hiện thay đổi code nhỏ sẽ dễ dàng test hơn, đồng thời các reviewer cũng có thể hiểu sâu hơn về cấu trúc và hiểu logic hơn.
+ Tránh thay đổi trong quá trình thực hiện review code bởi các thay đổi lớn về cơ bản sẽ có ảnh hưởng đến quá trình review và có thể sẽ phải review lại từ đầu. Nếu như bạn cần phải thực hiện các thay đổi lớn sau khi submit review thì có thể sẽ phải đưa review hiện có vào cùng với các thay đổi bổ sung. Còn nếu như muốn tạo các thay đổi lớn sau khi bắt đầu quá trình review code thì hãy trao đổi lại với các reviewer để họ xem xét.
+ Thực hiện phản hồi lại tất cả những comment đến từ reviewer, ngay cả khi bạn không thực hiện chúng thì cũng cần giải thích lý do cho họ biết hoặc nếu có gì đó không hiểu thì cần hỏi lại.
+ Review code là những cuộc thảo luận chứ không phải là bắt bẻ hay sai khiến. Bạn có thể nghĩ những comment là các đề xuất và bạn có thể đồng ý thực hiện hoặc không. Tuy nhiên cần phải có lời giải thích thuyết phục cho những comment đó.
- Trách nhiệm của các reviewer:
+ Cần chú ý miêu tả và yêu cầu về các task.
+ Đảm bảo rằng mình có thể hiểu rõ được mã code.
+ Nên phân chia bình luận ra thành 3 loại là bắt buộc, không bắt buộc và tích cực, tránh bình luận quá nhiều lần cùng với 1 nội dung.
+ Cần phải biết được khi nào sẽ tiến hành cuộc thảo luận trực tiếp, sau những comment, tranh luận không có hiệu quả, hãy gửi lời đề nghị về việc nói chuyện trực tiếp để giải quyết vấn đề nhanh hơn.
- Ngoài ra, một số câu hỏi sau cũng sẽ giúp cho lập trình viên có thể cải thiện được quá trình review code của mình:
+ Bạn có gặp khó khăn trong việc hiểu code không?
+ Có phần nào quá phức tạp và cần phải refactor lại hay không?
+ Code này đã được sắp xếp hợp lý theo cấu trúc hay chưa?
+ Class nam có trực quan và đảm bảo đúng với chứng năng chưa?
+ Có class nào là quá lớn hay không?
+ Có phương thức nào bị quá dài hay không?
+…
Hy vọng rằng bài viết trên đây sẽ giúp cho bạn đọc hiểu rõ về Code Review là gì cùng những thông tin liên quan nhé!
Tham gia bình luận ngay!