Review code là một phần quan trọng trong phát triển phần mềm, giúp nâng cao chất lượng mã và hỗ trợ đội ngũ. Đối với người mới bắt đầu, nắm vững các bí kíp review code hiệu quả là rất cần thiết. Trong bài viết này, chúng ta sẽ khám phá các bước cơ bản và mẹo hữu ích để thực hiện đánh giá mã nguồn một cách hiệu quả, giúp bạn nhanh chóng làm quen và đóng góp tích cực cho dự án.

1. Review code là review những gì?

Không có câu trả lời nào hoàn toàn đúng cho câu hỏi này, để quyết định xem chúng ta cần review đoạn code nào tuỳ thuộc vào cách làm việc của từng team, chẳng hạn như một số team muốn xem xét lại tất cả những thay đổi nhỏ nhất nhưng có một số team khác chỉ muốn review những thay đổi quan trọng. Việc cân nhắc này liên quan đến việc cân bằng giữa việc đảm bảo chất lượng sản phẩm và tiết kiệm thời gian. Trong một số trường hợp đặc biệt, việc review code là bắt buộc, dù thay đổi đó có nhỏ đến đâu.

Mặc cho bạn là ai, kể cả những người có kinh nghiệm nhất, cũng nên để người khác review lại đoạn code của mình. Việc này giúp:

  • Tìm ra lỗi: Có thể chúng ta vô tình bỏ sót một vài lỗi nhỏ.

  • Học hỏi: Chúng ta có thể học hỏi thêm từ đồng nghiệp và họ cũng vậy.

  • Nâng cao chất lượng chung: Cả nhóm cùng nhau xây dựng một sản phẩm tốt hơn.

2. Khi nào nên review code?

Các bạn nên tiến hành review code sau khi các kiểm tra tự động (kiểm thử, định dạng, và các kiểm tra liên tục khác) hoàn thành thành công, và trước khi code được merge vào nhánh chính của kho lưu trữ. 

Đối với các thay đổi phức tạp cần được merge vào nhánh chính như một đơn vị duy nhất nhưng lại quá lớn để gói gọn trong một CR (Code Review) hợp lý, hãy cân nhắc sử dụng mô hình CR xếp chồng: Tạo một nhánh chính là feature/big-feature và một số nhánh phụ (ví dụ, feature/big-feature-api, feature/big-feature-testing, v.v.) mỗi nhánh bao gồm một phần của chức năng và được review code riêng biệt với nhánh feature/big-feature. Khi tất cả các nhánh phụ đã được merge vào feature/big-feature, tạo một CR để merge nhánh này vào nhánh chính.

3. Cần chuẩn bị gì khi review code?

  • Phạm vi và kích thước: Thay đổi code nên có phạm vi hẹp, được xác định rõ ràng, độc lập và bao quát toàn diện. Ví dụ, một thay đổi có thể là triển khai một tính năng mới hoặc fix bug. Thay đổi ngắn gọn được ưu tiên hơn thay đổi dài. Nếu một yêu cầu code review (CR) thực hiện thay đổi đáng kể đối với hơn khoảng 5 tệp, hoặc mất nhiều hơn 1-2 ngày để viết, hoặc mất nhiều hơn 20 phút để review, hãy cân nhắc chia nhỏ nó thành nhiều CR độc lập. Ví dụ, một developer có thể gửi một thay đổi xác định API cho một tính năng mới dưới dạng giao diện và tài liệu, và một thay đổi thứ hai thêm các triển khai cho các giao diện đó.

  • Chỉ gửi các CR hoàn chỉnh, đã tự xem xét (bằng diff) và tự kiểm thử. Để tiết kiệm thời gian cho người review, hãy kiểm thử các thay đổi đã gửi (tức là chạy bộ kiểm thử) và đảm bảo chúng vượt qua tất cả các bản dựng cũng như tất cả các kiểm thử và kiểm tra chất lượng mã, cả cục bộ và trên máy chủ CI, trước khi giao cho người review.

  • Các thay đổi refactor (tái cấu trúc mã) không nên thay đổi hành vi; ngược lại, các thay đổi làm thay đổi hành vi nên tránh thay đổi refactor và định dạng mã, bởi vì:

    • Thay đổi refactor thường ảnh hưởng đến nhiều dòng và tệp, do đó việc review sẽ ít được chú ý hơn. Các thay đổi hành vi không mong muốn có thể lẫn vào code mà không ai nhận thấy.

    • Các thay đổi refactor lớn làm hỏng việc cherry-picking, rebasing, và các thao tác kiểm soát mã khác. Việc khôi phục lại một thay đổi hành vi đã được đưa vào trong một commit refactor toàn bộ kho lưu trữ là rất khó khăn.

  • Thời gian review nên dành vào logic chương trình hơn là tranh luận về kiểu mã, cú pháp, hoặc định dạng. Các bạn có thể sử dụng các công cụ tự động như Checkstyle, TSLint, Baseline, Prettier, v.v. để giải quyết những vấn đề đó.

4. Commit messages

Dưới đây là văn mẫu về một commit message chuẩn:

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

- Tiêu đề ngắn gọn, rõ ràng (tối đa 80 ký tự)

  • Mô tả chi tiết hơn trong phần nội dung (tối đa 120 ký tự ở mỗi dòng)

  • Có dòng trống giữa tiêu đề và nội dung

- Sử dụng động từ nguyên mẫu: "Sửa lỗi" thay vì "Đã sửa lỗi" hoặc "Đang sửa lỗi" ("Fix bug" thay vì "Fixed bug" hay "Fixing bug.")

  • Các nội dung mô tả tiếp theo theo nên bắt đầu sau một dòng trống.

  • Có thể sử dụng các dấu đầu dòng

Ví dụ:

# Tiêu đề (tối đa 80 ký tự)

Fix bug in login form

# Nội dung

Improve password validation:

*Enforce minimum password length of 8 characters.

*Enhance error message for incorrect passwords.

Hãy cố gắng mô tả cả những thay đổi trong commit và cách thức thực hiện:

#Đừng nên làm thế này:

Make compile again

#Mà hãy làm như này:

Add jcsv dependency to fix IntelliJ compilation

5. Tìm người review

Thông thường, người commit sẽ đề xuất một hoặc hai người review code quen thuộc với codebase. Một trong những người review là lead phụ trách dự án hoặc senior engineer. Các product owner nên cân nhắc đăng ký theo dõi dự án để nhận được thông báo về các yêu cầu review code mới.

Việc review code giữa nhiều hơn ba bên thường không hiệu quả hoặc thậm chí phản tác dụng, vì những người review khác nhau có thể đề xuất những thay đổi mâu thuẫn với nhau. Điều này có thể cho thấy sự bất đồng cơ bản về cách triển khai đúng và nên được giải quyết trực tiếp hoặc trong cuộc họp online với tất cả các bên liên quan.

6. Thực hiện review code

Review code là thời điểm mà các thành viên trong team phải hợp tác và thống nhất ý kiến về các thay đổi code, điều này có thể làm chậm tiến độ công việc. Vì vậy, việc này cần phải được thực hiện nhanh chóng (trong vòng vài giờ, không phải vài ngày), và các thành viên trong team cũng như leader cần phải nhận thức về thời gian cần thiết và ưu tiên thời gian review cho phù hợp. Nếu bạn không nghĩ rằng mình có thể hoàn thành việc review đúng thời gian, hãy thông báo ngay cho người commit để họ có thể tìm người khác.

Khi review code bạn phải xem xét thật kỹ lưỡng để có thể giải thích thay đổi đó với mức độ chi tiết hợp lý cho một lập trình viên khác. Điều này đảm bảo rằng các chi tiết của codebase được biết đến không chỉ bởi một người.

Là người review, bạn có trách nhiệm duy trì các tiêu chuẩn mã hóa và giữ chất lượng code ở mức cao. Việc review code có thể xem là một nghệ thuật hơn là một bộ môn khoa học. Cách duy nhất để học là thực hành; một reviewer có kinh nghiệm nên cân nhắc để các reviewer ít kinh nghiệm hơn xem xét các thay đổi của họ và thực hiện review trước. Đây là danh sách những điều mà người review nên chú ý trong một code review:

6.1. Mục đích

  • Code này có thực hiện đúng mục đích của người đề xuất review code không? Mỗi thay đổi nên có một lý do cụ thể (tính năng mới, tái cấu trúc, sửa lỗi, v.v.). Code được gửi có thực sự đạt được mục đích đó không?

  • Hãy đặt câu hỏi. Các hàm và lớp nên tồn tại vì một lý do. Khi lý do không rõ ràng với người review, điều này có thể cho thấy code cần được viết lại hoặc cần có thêm chú thích hoặc bài test.

6.2. Triển khai

  • Hãy nghĩ về cách bạn sẽ giải quyết vấn đề. Nếu cách bạn làm khác, tại sao lại như vậy? Code của bạn có xử lý nhiều trường hợp ngoại lệ hơn không? Nó có ngắn gọn/hữu ích/nhanh hơn/hoàn toàn an toàn mà vẫn tương đương về mặt chức năng không? Bạn có phát hiện ra pattern nào cơ bản mà code hiện tại chưa thể hiện không?

  • Bạn có thấy tiềm năng cho các abstraction hữu ích không? Code bị trùng lặp thường chỉ ra rằng có thể trích xuất một phần chức năng trừu tượng hơn hoặc tổng quát hơn và sau đó tái sử dụng trong các ngữ cảnh khác nhau.

  • Hãy nghĩ như một khách hàng. Tức là: Hãy cố gắng tìm ra những lỗi hoặc trường hợp đặc biệt mà đoạn code này có thể gặp phải.

  • Hãy nghĩ về các thư viện hoặc mã sản phẩm hiện có. Kiểm tra xem có thư viện nào đã có sẵn chức năng tương tự không, để tránh viết lại code một cách không cần thiết. 

  • Thay đổi có theo các mẫu tiêu chuẩn không? Kiểm tra xem cách viết code này có tuân theo quy tắc chung của dự án. Các cơ sở code đã được thiết lập thường thể hiện các mẫu liên quan đến quy ước đặt tên, phân tách logic chương trình, định nghĩa kiểu dữ liệu, v.v. 

  • Thay đổi có thêm phụ thuộc vào quá trình biên dịch hoặc chạy chương trình không? Đặc biệt là giữa các phần nhỏ của dự án? Thông thường chúng ta sẽ muốn giữ cho sản phẩm của mình càng ít phụ thuộc càng tốt. Vì vậy, các thay đổi liên quan đến phụ thuộc và hệ thống xây dựng cần được kiểm tra kỹ lưỡng.

6.3. Tính dễ đọc và style

  • Hãy nghĩ về trải nghiệm đọc của bạn. Bạn có hiểu được các khái niệm trong một thời gian hợp lý không? Luồng đọc có mạch lạc không và tên biến, phương thức có dễ theo dõi không? Bạn có theo dõi được qua nhiều tệp hoặc hàm không? Bạn có bị làm phiền bởi cách đặt tên không nhất quán không?

  • Mã có tuân theo các hướng dẫn và phong cách mã hóa không? Mã có nhất quán với dự án về mặt phong cách, quy ước API, v.v. không? 

  • Mã này có chứa TODO không? TODO chỉ chất đống trong mã và trở nên lỗi thời theo thời gian. Yêu cầu tác giả gửi một ticket trên GitHub Issues hoặc JIRA và đính kèm số ticket vào TODO. Thay đổi code đề xuất không nên chứa code  bị commented .

6.4. Khả năng bảo trì

Kiểm tra các bài test:

  • Có đủ bài test không? Nếu chưa có bài test nào, cần yêu cầu người viết code bổ sung.

  • Các bài test có đầy đủ và hiệu quả không? Bài test cần bao quát nhiều tình huống khác nhau để đảm bảo code hoạt động đúng.

  • Các bài test có dễ hiểu không? Bài test cần viết rõ ràng để người khác dễ dàng hiểu và sửa chữa.

Kiểm tra tác động của đoạn code mới:

  • Có làm hỏng các phần khác của dự án không? Cần kiểm tra xem đoạn code mới có gây ra lỗi ở các phần code khác, đặc biệt là các phần liên quan đến kiểm thử.

  • Có làm thay đổi cách hoạt động của các tính năng cũ không? Nếu có thay đổi, cần xem xét kỹ lưỡng để đảm bảo không gây ra vấn đề cho người dùng.

Kiểm tra chất lượng code:

  • Code có dễ hiểu, dễ bảo trì không? Code cần được viết rõ ràng, có chú thích đầy đủ để dễ dàng hiểu và sửa chữa sau này.

  • Code có tuân thủ các quy tắc viết code chung không? Code cần tuân thủ các quy tắc đã được định nghĩa trong dự án để đảm bảo tính nhất quán.

Kiểm tra tài liệu: Tài liệu có được cập nhật không? Nếu dự án có các tài liệu như README, CHANGELOG, thì cần cập nhật chúng để phản ánh những thay đổi mới. Tài liệu cũ không chỉ gây hiểu nhầm mà còn tốn kém thời gian để sửa chữa sau này.

Đừng ngại khen ngợi những đoạn code viết tốt, ngắn gọn, dễ hiểu và hiệu quả. Ngược lại, nếu bạn cho rằng một thay đổi là không cần thiết hoặc có vấn đề, hãy thẳng thắn đưa ra ý kiến. Hãy nhớ rằng mục tiêu chung của chúng ta là tạo ra một sản phẩm chất lượng cao.

Hãy tôn trọng ý kiến của người viết code. Mặc dù chúng ta có thể có những quan điểm khác nhau, nhưng hãy cố gắng tìm ra giải pháp tốt nhất cho cả nhóm. Nếu không thể thống nhất, hãy thảo luận trực tiếp hoặc nhờ người khác hỗ trợ.

6.5. Tính bảo mật (Security)

Hãy kiểm tra kỹ xem các điểm kết nối của API có thực hiện việc xác minh và cấp phép truy cập một cách chính xác và nhất quán với phần còn lại của hệ thống không. Bạn cần đảm bảo rằng chỉ những người hoặc ứng dụng có quyền mới được phép truy cập vào dữ liệu, và quá trình kiểm soát này phải được thực hiện một cách nhất quán trên toàn hệ thống.

Lời kết

VietnamWorks inTECH hy vọng những mẹo nhỏ trong bài viết này sẽ giúp bạn tự tin hơn trong quá trình review code và làm việc hiệu quả hơn với các đồng nghiệp, góp phần tạo ra sản phẩm tốt hơn.

Nguồn: Palantir

VietnamWorks inTECH

TẠO TÀI KHOẢN MỚI: XEM FULL “1 TÁCH CODEFEE” - NHẬN SLOT TƯ VẤN CV TỪ CHUYÊN GIA - CƠ HỘI RINH VỀ VOUCHER 200K