Phân cụm lỗi trong mã nguồn

Có nhiều tuyên bố về sự tồn tại của các cụm lỗi hoặc khiếm khuyết. Một tìm kiếm đơn giản cho thấy nhiều kết quả, ví dụ: 1 , 2 , 3 , 4 , 5 .

Tuy nhiên, tất cả các bằng chứng được trích dẫn là giai thoại và tôi không thể tìm thấy bất kỳ dữ liệu cụ thể nào để sao lưu điều này. Mặc dù kinh nghiệm của riêng tôi không mâu thuẫn với những tuyên bố này, mọi người thích xem các mẫu ngay cả khi không có (thậm chí phân phối lỗi đồng đều sẽ tạo ra các cụm và có thể dễ nhớ hơn khi bạn phải sửa 10 lỗi ở một nơi thay vì 10 những thứ không liên quan trên tất cả các cơ sở mã).

Tôi thực sự tò mò nếu hiện tượng này thực sự tồn tại, nhưng tôi không thể tìm thấy bất kỳ nguồn khách quan hay thậm chí bán khách quan nào (như trong thử nghiệm, thử nghiệm, nghiên cứu, v.v.) sẽ cho thấy sự phân cụm khiếm khuyết thực sự xảy ra.

Tất nhiên, tôi ổn với giả định giả thuyết phân cụm lỗi là cách thực hành tốt (ngay cả khi đó là sai, nó sẽ không bị tổn thương quá nhiều). Mặt khác, dữ liệu cụ thể có thể làm sáng tỏ lý do tại sao nó xảy ra. Có phải vì những ngày đó người ta đau đầu khủng khiếp (vì bất cứ lý do gì)? Hoặc có thể vì một số phần của mã chỉ khó và những phần khác thì dễ? Hoặc có lẽ đó là nơi chịu trách nhiệm của hai kỹ sư không thích nhau?

Câu hỏi của tôi: Liệu hiệu ứng cụm khiếm khuyết thực sự tồn tại? Có dữ liệu phi giai thoại cụ thể nào được giải thích tốt nhất bằng giả thuyết này không?

Tôi không có bất kỳ dữ liệu nào trong tay, nhưng tôi khá chắc chắn rằng giả thuyết phân cụm là đúng. Dự đoán tốt nhất của tôi là hai trường hợp xảy ra ít nhiều thường xuyên:

• một đoạn mã hoặc thuật toán rất phức tạp (có thể việc triển khai phức tạp hơn mức cần thiết) và lập trình viên ban đầu không hiểu đầy đủ những gì mã của anh ta có thể làm vì sự phức tạp.

• mã không được kiểm tra tốt

Và - tất nhiên - sự kết hợp của cả hai. Kiểm tra là khó, nhưng kiểm tra mã phức tạp khó hơn nhiều bởi một thứ tự cường độ. Và với sự phức tạp ngày càng tăng, đặc biệt là khi mã không được kiểm tra tốt, theo kinh nghiệm của tôi, số lượng lỗi tiềm ẩn trong một đoạn mã tăng cao không tương xứng.

Vì vậy, nếu bạn tìm thấy một số lỗi trong một đoạn mã nhất định, thì đó rất có thể là một đoạn mã phức tạp, được kiểm tra kém, mang lại cho bạn cơ hội cao để tìm thấy nhiều mã hơn trong cùng một khu vực.

Các nghiên cứu chính thức như thế này hiếm khi tồn tại trong phát triển phần mềm, có lẽ bởi vì lập trình (mặc dù liên kết với máy móc) chủ yếu là nỗ lực của con người, không phải là máy móc.

Hôm qua tôi đã sửa một lỗi trong câu lệnh SQL có liên quan đến hai câu lệnh CHỌN và UNION. Cả hai CHỌN đều trả về cùng một kết quả do một lỗi đơn giản trong THAM GIA. Tuy nhiên, việc khắc phục sự cố đã phát hiện ra một lỗi khác đang bị che dấu bởi lỗi đầu tiên.

Theo kinh nghiệm của tôi:

Phân cụm xảy ra khi công việc bị gián đoạn. Giả sử ai đó bị chuyển khỏi dự án để công việc của anh ta không được kiểm tra đầy đủ hoặc thậm chí có thể hoàn thành và / hoặc kết quả không được hiểu đầy đủ.

Phân cụm cũng xảy ra do vấn đề "lập trình viên xấu". Nói rằng 5 người làm việc về một cái gì đó và một trong số họ là tiêu chuẩn phụ. Các lỗi sẽ được liên kết với công việc của mình.

Nguyên tắc Pareto được áp dụng (còn gọi là quy tắc 80/20). Khoảng 80% các tác động đến từ 20% nguyên nhân. https://en.wikipedia.org/wiki/Pareto_principl Lưu ý quan sát này có từ trước máy tính.

Không có nghịch lý trong phân cụm lỗi. Và thiên kiến ​​nhận thức của chúng tôi quạt ngọn lửa xung quanh.

Theo phân phối bình thường tại bất kỳ thời điểm nào, một số phần của codebase có lỗi nhiều hơn đáng kể so với các phần khác. Bất kỳ lỗi mới có nhiều khả năng được tìm thấy trong phần lỗi.
Vì vậy, một trong những bạn sắp sửa chữa đã cam chịu với một cơ hội tốt để có một công ty.

Nó giống như "những bất hạnh không bao giờ đến đơn lẻ".