Làm thế nào để xác định tính hiệu quả của quy trình xem xét mã?

Chúng tôi đã giới thiệu một quy trình xem xét mã trong tổ chức của chúng tôi và nó dường như đang hoạt động tốt. Tuy nhiên, tôi muốn có thể đo lường hiệu quả của quy trình theo thời gian, tức là chúng ta không tìm thấy lỗi vì mã này sạch hay mọi người chỉ không nhận lỗi?

Hiện tại, chúng tôi không có quy trình kiểm tra hoàn toàn tự động hiệu quả. Chúng tôi chủ yếu sử dụng thử nghiệm thủ công, vì vậy chúng tôi không thể dựa vào các lỗi được tìm thấy ở giai đoạn này để đảm bảo rằng quy trình xem xét mã đang hoạt động.

Có ai gặp phải vấn đề này trước đây hoặc có bất kỳ suy nghĩ nào về những gì hoạt động tốt trong việc đo lường đánh giá mã?

Có một số số liệu có thể được thu thập từ các đánh giá mã, một số thậm chí kéo dài trong suốt vòng đời của dự án.

Số liệu đầu tiên mà tôi khuyên bạn nên thu thập là hiệu quả loại bỏ khuyết tật (DRE) . Đối với mọi khiếm khuyết, bạn xác định được khuyết điểm đã được đưa vào và giai đoạn nào đã được loại bỏ. Các kỹ thuật phát hiện khuyết tật khác nhau mà bạn sử dụng đều được đánh giá đồng thời, do đó áp dụng như nhau cho các đánh giá yêu cầu, đánh giá thiết kế, đánh giá mã, kiểm tra đơn vị , và như thế. Bạn sẽ đặc biệt quan tâm đến số lượng lỗi bị bắt trong giai đoạn mã, vì điều này có thể sẽ bao gồm các bài kiểm tra đơn vị của bạn cũng như các đánh giá mã. Nếu nhiều khiếm khuyết từ giai đoạn mã đang chuyển sang giai đoạn thử nghiệm tích hợp hoặc thậm chí là trường, bạn biết rằng bạn nên đánh giá các thực hành sau mã hóa.

Số liệu cuộc họp khác nhau cũng sẽ có liên quan. Chúng bao gồm thời gian chuẩn bị, thời gian họp, dòng mã đọc, lỗi được tìm thấy trong đánh giá, v.v. Một số quan sát có thể được thực hiện từ dữ liệu này. Một ví dụ sẽ là nếu người đánh giá của bạn dành một lượng lớn thời gian để đọc mã để chuẩn bị cho đánh giá, nhưng tìm thấy rất ít vấn đề. Kết hợp với dữ liệu DRE, bạn có thể rút ra kết luận rằng nếu các lỗi đang được kiểm tra trong thử nghiệm tích hợp hoặc trường, thì nhóm của bạn cần tập trung vào các kỹ thuật đánh giá của họ để có thể tìm ra vấn đề. Một lưu ý thú vị khác là các dòng mã (hoặc một số phép đo kích thước khác) được đọc trong một cuộc họp so với thời gian của cuộc họp. Nghiên cứu đã phát hiện ra rằng tốc độ của một đánh giá mã thông thường là 150 dòng mã mỗi giờ.

Với bất kỳ số liệu nào trong số này, điều quan trọng là phải hiểu tác động của chúng đối với quy trình. Phân tích nguyên nhân gốc rễ, sử dụng các kỹ thuật như tại sao - vì , biểu đồ Five Whys hoặc Ishikawa có thể được sử dụng để xác định lý do tại sao đánh giá mã (hoặc bất kỳ kỹ thuật cải tiến chất lượng nào khác) có hiệu quả.

Bạn cũng có thể quan tâm đến bài viết này về các cuộc kiểm tra từ Nhóm Ganssle và một bài viết của Capers Jones trong Crosstalk về khiếm khuyết tiềm năng và DRE .

Mặc dù phần lớn đúng là việc xem xét mã sẽ xử lý các vấn đề khá tiềm ẩn mà việc kiểm tra có thể hoặc không thể nắm bắt được. Tuy nhiên, theo tôi, bạn có thể có một mã thực sự ổn định (thực tế không có lỗi) nhưng vẫn được viết theo cách mà nó cực kỳ không thể đọc được hoặc không hoàn toàn có thể duy trì được. Vì vậy, có thể là xem xét mã có thể KHÔNG tìm thấy lỗi nếu không có vấn đề thực sự trong mã.

Có nói rằng, tôi thực sự sẽ hỏi, tại sao một người muốn thực hiện đánh giá mã? Lý do đơn giản tại sao điều quan trọng là mã phải được cải thiện để dễ đọc hơn, dễ bảo trì và có thể phát triển hơn. Nhiều người sẽ có thể đọc mã sạch hơn và hiểu ý nghĩa của nó. Theo nghĩa đó, mục tiêu đơn giản nhất của quy trình xem xét mã là sản xuất mã sạch. Vì vậy, thước đo hiệu quả là mã bây giờ sạch hơn bao nhiêu.

Như bạn muốn có một hiệu quả có thể đo lường được - đây là những gì tôi muốn đề xuất:

1. Số liệu liên quan đến số lượng làm lại - Số thời gian làm lại được áp dụng trong cùng một mô-đun / đối tượng / mục công việc nhất định là thước đo mức độ kém của mã đó về khả năng duy trì. Khi xem xét mã hiệu quả được áp dụng, tần suất chúng tôi có thể giảm yêu cầu làm việc lại trên cùng một mô-đun?

2. Số liệu liên quan đến số lượng thay đổi mà mọi yêu cầu thay đổi phải chịu. Khi mỗi khi có yêu cầu thay đổi xảy ra - một mã yếu kém sẽ luôn có số lượng mô-đun lớn hơn bị ảnh hưởng. Một biện pháp có thể chỉ ra rằng sau khi xem xét mã - có phải là bất kỳ sự giảm bớt nào về sự thay đổi lan truyền như vậy đối với một yêu cầu thay đổi tương tự trong quá khứ không?

3. Số liệu liên quan đến tốc độ trung bình mà yêu cầu thay đổi có thể được đáp ứng. Khi mã sạch hơn - nhanh hơn và tốt hơn là đáp ứng các thay đổi cần thiết. Sau khi mã được làm sạch trong quá trình xem xét, chúng ta sẽ thấy bất kỳ sự tăng tốc nào trong việc đáp ứng yêu cầu kích thước tương tự.

Tôi không đưa ra các đơn vị đo lường chính xác - có lẽ bạn có thể tạo ra các biện pháp chính xác hơn về phương pháp này từ phương pháp này. Có thể có nhiều chủ nghĩa hình thức mở rộng hơn trong các phương pháp trên về điều này.

Về cơ bản, quan điểm của tôi là thay vì nhìn vào số lỗi mà quy trình xem xét mã xác định; chúng ta nên đo lường hiệu quả về việc xem xét mã có thể mang lại mã để sạch hơn, gọn hơn và dễ bảo trì hay không; do đó, chúng tôi có thể đánh giá hiệu quả đó nếu chúng tôi thấy rằng các yêu cầu thay đổi tương tự trong tương lai sẽ trở nên hiệu quả hơn để được đáp ứng.