Các quy trình đánh giá mã nguồn giúp cải thiện chất lượng mã nguồn và giúp các lập trình viên phát triển một cách chuyên nghiệp.

Năm 1988, Hewlett-Packard (HP) đã tiến hành đánh giá nội bộ các quy trình phát triển phần mềm của họ và đặt mục tiêu cải thiện chất lượng mã nguồn lên gấp 10 lần. Để đạt được mục tiêu đầy tham vọng này, họ đã thử nghiệm một số phương pháp tiếp cận. Cuối cùng, họ kết luận rằng việc kết hợp các bước đánh giá mã nguồn vào chu trình phát triển sẽ tiết kiệm được nhiều chi phí hơn so với việc giải quyết các khiếm khuyết sau khi khách hàng phản ánh chúng.

Đánh giá mã nguồn là gì

Code review (đánh giá mã nguồn) hay còn được gọi là peer code review (đánh giá mã ngang hàng) là một quy trình trong đó một hoặc hai nhà phát triển phân tích mã nguồn của đồng đội, xác định các lỗi cú pháp, lỗi logic hay các trường hợp ngoại lệ đã bị bỏ qua.

Khi HP thực hiện điều này, các phương pháp phát triển phần mềm chưa được xác định rõ ràng và hoàn thiện như ngày nay. Tuy nhiên, các tổ chức từ lâu đã nhận ra rằng việc đánh giá mã nguồn là một phần trong vòng đời phát triển phần mềm của họ và có thể mang lại những kết quả tích cực.

Ngày nay – hơn ba thập kỷ sau đó – ngành phát triển phần mềm vẫn đang khám phá những lợi ích của việc đánh giá mã nguồn. Theo khảo sát của Smartbear năm 2020, những người tham gia đã lựa chọn đánh giá mã nguồn là phương pháp tốt nhất để nâng cao và cải thiện chất lượng mã.

Dưới đây là năm thực hành hay nhất trong việc đánh giá để tối đa hóa giá trị của mã nguồn, bằng cách xác định các lỗi và các mẫu thiết kế kém nhằm đảm bảo mọi tính năng hoặc sản phẩm mới đều được tạo ra từ mã nguồn có chất lượng cao.

1. Tạo một checklist

Checklist (danh sách kiểm tra) khi đánh giá mã nguồn là một tập hợp các câu hỏi và quy tắc được xác định trước mà nhóm của bạn sẽ tuân theo trong quá trình đánh giá. Đây là một cách tiếp cận có cấu trúc để giúp nhóm phát triển kiểm tra chất lượng mã nguồn trước khi phê duyệt.

Checklist đánh giá mã nguồn thường bao gồm:

• Tính dễ đọc: Có bất kỳ comment nào dư thừa hay không?
• Tính bảo mật: Mã có khả năng khiến hệ thống bị tấn công mạng hay không?
• Phạm vi kiểm tra: Có cần kiểm tra trên nhiều trường hợp hơn không?
• Kiến trúc: Mã có áp dụng phương pháp đóng gói và mô-đun hóa để tách biệt cách thành phần không?
• Khả năng tái sử dụng: Có thể tái sử dụng cách thành phần hay chức năng trong mã hay không?

2. Các chỉ số đánh giá mã nguồn

Bạn không thể nâng cao chất lượng mã nguồn của một ai đó mà không đo lường chất lượng của mã đó. Các chỉ số khách quan giúp xác định hiệu quả của các phương pháp đánh giá, phân tích tác động của sự thay đổi đối với quy trình và dự đoán số giờ cần thiết để hoàn thành một dự án.

Một vài chỉ số thường được sử dụng là:

• Tốc độ kiểm tra: Tốc độ nhóm của bạn đánh giá một mã nguồn cụ thể, được tính bằng cách chia số lượng dòng mã cho số giờ kiểm tra. Nếu bạn mất nhiều thời gian để đánh giá mã, trong mã nguồn ấy có thể tồn tại các vấn đề về tính dễ đọc cần được giải quyết.
• Tỷ lệ lỗi: Tần suất bạn xác định được lỗi, được tính bằng cách chia số lỗi cho số giờ kiểm tra. Số liệu này giúp bạn xác định hiệu quả của quy trình thử nghiệm. Ví dụ, nếu các nhà phát triển của bạn chậm tìm ra lỗi, bạn có thể cần đến các công cụ kiểm tra hỗ trợ.
• Mật độ khiếm khuyết: Số lượng khiếm khuyết bạn xác định được trong một lượng mã nguồn cụ thể, được tính bằng số lượng khiếm khuyết trên mỗi một nghìn dòng mã. Mật độ khiếm khuyết giúp xác định thành phần nào dễ bị lỗi hơn các thành phần khác để phân bổ cho nó nhiều tài nguyên hơn. Ví dụ, nếu một trong các ứng dụng web của bạn có nhiều khiếm khuyết hơn đáng kể so với các ứng dụng khác trong cùng một dự án, bạn có thể cần chỉ định các nhà phát triển có kinh nghiệm hơn làm việc với nó.

3. Đảm bảo phản hồi của bạn xác minh lập trường của bạn

Khi đánh giá mã nguồn, đừng chỉ đề xuất những gì cần sửa hoặc cần cải thiện – hãy giải thích lý do tại sao nhà phát triển nên thực hiện thay đổi đó.

Trong quá trình phát triển, bạn hầu như sẽ gặp các vấn đề có thể được giải quyết bằng nhiều giải pháp. Các nhận xét bạn đưa vào mã nguồn là kết quả đúc kết từ kiến thức và kinh nghiệm của bạn. Bạn có thể có xu hướng giải quyết vấn đề theo một cách cụ thể nào đó, khác với cách tiếp cận của tác giả mã nguồn. Do đó, bạn nên trình bày các lý do của mình để làm rõ lập trường của bản thân.

Hãy lấy ví dụ khi bạn đánh giá một đoạn mã là không cần xử lý đa luồng. Thay vì chỉ đơn giản khuyên nhà phát triển không nên sử dụng các luồng, hãy giải thích rằng mô hình đa luồng không mang lại bất kỳ lợi thế hiệu suất nào cho kịch bản của sản phẩm, do đó họ nên chỉnh sửa mã nguồn thành đơn luồng.

Có hai lợi ích trong cách tiếp cận này. Đầu tiên, tác giả mã nguồn sẽ biết được lý do tại sao họ nên thực hiện một thay đổi cụ thể, điều này sẽ giúp họ giải quyết các vấn đề tương tự trong tương lai. Thứ hai, vì bạn đã giải thích cho nhận xét của mình, họ sẽ không cần phải để ý hay hỏi bạn để tìm ra lý do đằng sau nhận xét ấy, tiết kiệm thời gian cho cả đôi bên.

4. Không đánh giá hơn 200-400 dòng mã cùng một lúc

Việc đánh giá hơn 400 dòng mã có thể gây tác động xấu đến khả năng tìm lỗi của bạn. Trên thực tế, hầu hết các lỗi được tìm thấy trong 200 dòng đầu tiên. Hạn chế này ảnh hưởng đến thực tiễn ngành sau khi Cisco xác định nó trong một nghiên cứu toàn diện về đánh giá mã.

Nghiên cứu cho thấy rằng khả năng xác định các khiếm khuyết của nhà phát triển sẽ suy yếu khi họ đánh giá hơn 200 dòng mã (xem biểu đồ dưới đây).

5. Nâng cao các thực hành hay nhất với tự động hóa

Nếu bạn sử dụng Bitbucket làm giải pháp git của mình, hãy nâng cao quy trình quản lý mã nguồn bằng một ứng dụng như Workzone. Ứng dụng này giúp bạn lập kế hoạch về cách thức và thời điểm để push các thay đổi, cũng như cách thêm nhóm và người đánh giá các pull request mới. Bạn cũng có thể xác định các nhóm và người đánh giá pull request mặc định cho mỗi nhánh. Bằng cách này, các tổ chức có thể thực hiện quy trình quản lý mã nguồn một cách đơn giản và thân thiện với người dùng.

Một ứng dụng Bitbucket khác có thể giúp bạn tự động hóa việc đánh giá mã nguồn chính là Code Owners for Bitbucket. Công cụ này giúp bạn quyết định xem người dùng nào trong Bitbucket nên đánh giá các pull request bằng một khái niệm là code owners. Code owners là những cá nhân có kiến thức và kinh nghiệm trong một lĩnh vực mã hóa cụ thể (chẳng hạn như: phát triển ứng dụng trong Sprint Boot). Hãy sử dụng tính năng code owners để đảm bảo rằng các nhà phát triển có kinh nghiệm trong lĩnh vực đã kiểm tra mã nguồn trước khi chúng được phê duyệt.

Đánh giá mã nguồn là một cơ hội để phát triển, không phải để chỉ trích

Khi xây dựng văn hóa đánh giá mã nguồn, hãy đảm bảo rằng các nhà phát triển của bạn không bị đe dọa bởi quá trình này. Hãy tránh đánh giá hiệu suất của họ bằng cách xem xét các khiếm khuyết xác định được trong quá trình đánh giá mã. Nếu điều này trở thành tiêu chuẩn để thăng chức hoặc xử phạt, các nhà phát triển của bạn có thể cảm thấy bị đe dọa và dần có cảm giác thù địch với quy trình này.

Thay vào đó, hãy sử dụng các quy trình đánh giá như một cơ hội để các nhà phát triển cấp dưới học hỏi từ các đồng nghiệp cấp cao hơn của họ. Bạn sẽ phát hiện ra các lỗi sớm hơn, khi chi phí sửa chúng rẻ hơn, đồng thời có thể cải thiện việc tuân thủ các tiêu chuẩn viết mã và nâng cao chất lượng tổng thể cho mã nguồn của mình. Tiếp cận các quy trình đánh giá mã nguồn theo cách này tạo cơ hội cho cả nhóm phát triển cùng nâng cao kỹ năng, giúp công việc trơn tru và hiệu quả hơn trong các dự án tương lai.

Theo Atlassian Blog