Làm thế nào để thuyết phục các thành viên trong nhóm về sự tồn tại của một con bọ cánh cứng

Chúng tôi đang phát triển một ứng dụng; nó bao gồm một thư viện được phát triển bởi một lập trình viên khác, thư viện này giao tiếp với máy chủ thông qua nhiều kết nối mạng và điều này liên quan đến nhiều luồng làm việc cùng nhau. Mã phía máy chủ khá phức tạp và chúng tôi không có quyền truy cập vào mã nguồn.

Gần đây, đôi khi tôi đã phát hiện ra một ứng dụng làm đèn chùm . Tôi có thể sao chép nó một lần và có dấu vết ngăn xếp, vì vậy tôi đã mở một báo cáo lỗi. Bản thân lỗi này rất dễ sửa (ngoại lệ web chưa được phát hiện trong một trong các luồng nền, khiến CLR chấm dứt chương trình).

Vấn đề là nhà phát triển đang từ chối sửa lỗi, bởi vì "anh ta không tin nó tồn tại". Thật không may cho tôi, ông chủ đang đứng về phía anh ta và nói rằng lỗi này không thể sửa được trừ khi tôi tạo ra "trường hợp kiểm tra chắc chắn" để chứng minh sự tồn tại của lỗi và để kiểm tra đơn vị xác minh rằng nó đã biến mất. Điều cơ bản là không thể do bản chất của lỗi.

Có lời khuyên nào không?

Nếu có thể, có thể dành một chút thời gian để kiểm tra xem lỗi này có thể được sao chép hay không bằng cách đặt một số giấc ngủ hoặc chặn trong mã ứng dụng của bạn. Nhưng đừng dành quá nhiều thời gian. Vì vấn đề này là do đa hướng (và cũng như bạn đã quan sát), nó sẽ xảy ra rất hiếm.

Lời khuyên của tôi là đừng đổ mồ hôi quá nhiều. Tiếp tục công việc của bạn. Bất cứ khi nào bạn gặp phải sự cố này, hãy cập nhật báo cáo lỗi của bạn với theo dõi ngăn xếp, nói rằng đây là sự cố lặp lại và thay đổi chủ sở hữu thành nhà phát triển thư viện. Hãy để quản lý / khách hàng tiềm năng quyết định có khắc phục hay không tùy thuộc vào tần suất của nó.

Cũng cố gắng để hiểu tâm lý của nhà phát triển. Bạn đã nói "ngoại lệ web chưa được phát hiện". Nhà phát triển ở giai đoạn này có thể không hoàn toàn chắc chắn những tác động khác của việc nắm bắt điều này . Vì vậy, anh ấy / cô ấy có thể miễn cưỡng chạm vào mã.

Vì vậy, từ những bình luận ít nhiều làm rõ của bạn, tôi đã hiểu theo cách này:

Bạn chắc chắn rằng chỉ có một xử lý ngoại lệ bổ sung đơn giản bị thiếu và bạn đã biết dòng mã nào trong lib có vấn đề và làm thế nào lib có thể được sửa.

Tại sao sau đó bạn không tự mình thêm một vài dòng mã bị thiếu vào lib, hãy yêu cầu nhóm vui lòng kiểm tra lib với những thay đổi đó? Hãy chắc chắn rằng đó là một thay đổi rủi ro thấp, dễ hiểu bởi nhà phát triển chịu trách nhiệm về lib. Điều tồi tệ nhất có thể xảy ra là ai đó phải hoàn nguyên thay đổi đó trong VCS của bạn nếu cách khắc phục của bạn gây ra một số hành vi bất ngờ mới.

Hầu hết mọi người dễ thuyết phục hơn khi công việc đã hoàn thành. Ngoài ra, họ phản ứng tốt hơn về "đây là một giải pháp cải tiến", trái ngược với "mã này là sai, sửa nó bằng cách nào đó".

EDIT: khi nhà phát triển vẫn từ chối thêm thay đổi đó, tùy chọn tốt nhất là cố gắng làm cho mã có vấn đề hoạt động bên trong một khai thác thử nghiệm bị cô lập trong đó bạn mô phỏng lỗi mạng. Làm việc hiệu quả với mã kế thừa mô tả rất nhiều kỹ thuật về cách giải quyết các loại vấn đề như vậy. Ví dụ: bạn có thể tạo phiên bản thử nghiệm của thư viện, chỉ bao gồm các mô-đun và chức năng có vấn đề và tạo một "môi trường giả" xung quanh nó để bạn có thể mô phỏng "ngoại lệ mạng" trong các điều kiện được kiểm soát. Thoạt nhìn có vẻ là quá nhiều nỗ lực, nhưng một khi bạn có một môi trường như vậy, bạn có thể thêm rất nhiều bài kiểm tra bổ sung vào đó (và tôi đoán điều đó sẽ có ý nghĩa, vì khi tác giả của lib từ chối thêm xử lý ngoại lệ ở một nơi,

Đối với một lỗi như thế này, kiểm tra fuzz tự động (còn gọi là kiểm tra ngẫu nhiên) có thể hữu ích trong việc cố gắng tái tạo nó. Điều này tự động hóa quá trình tìm lỗi bằng cách chọn ngẫu nhiên một bộ tham số (hoặc đầu vào) cố định vào thứ bạn đang kiểm tra. Mỗi lần chạy thử, các tham số được ghi vào một tệp nhật ký, bao gồm cả dấu thời gian, v.v. để khi xảy ra sự cố, bạn có thể (về mặt lý thuyết) chỉ cần phát lại thử nghiệm, sử dụng cùng một tham số, để tạo lại nó.

Kể từ khi được tự động hóa, quá trình thử nghiệm có thể chạy nhiều thử nghiệm trong một khoảng thời gian ngắn. Thường thì nó có thể được để lại để chạy qua đêm và vào buổi sáng bạn có thể kiểm tra một tệp nhật ký để xem nó có tái tạo sự cố không.

Advocate của Devil gợi ý một con đường khác.

Các nhà phát triển khác đã tuyên bố, thẳng thừng, rằng không có lỗi ở đó.

Bạn có thể nghĩ ra một cách để giải tỏa địa ngục khỏi lỗi được cho là không tồn tại của anh ấy và khiến nó gặp sự cố thường xuyên hơn không?

Dấu vết ngăn xếp là bằng chứng rõ ràng cho thấy lỗi tồn tại hoặc ít nhất là đã tồn tại trong một bản dựng nhất định. Những gì bạn không có là bằng chứng lỗi đã được sửa. Họ thật ngu ngốc khi bỏ qua nó. Tôi đã gặp lỗi "không thể sao chép" sau hàng trăm ngàn lần thử tự động trên nhiều hệ thống được kích hoạt mỗi lần trên hệ thống của khách hàng.

Tôi nhận được một vài lỗi như vậy mỗi năm, hầu hết không có lợi ích của dấu vết ngăn xếp. Trong hầu hết mọi trường hợp, mặc dù tôi không thể sao chép nó trước đó, tôi có thể dễ dàng thực hiện một thử nghiệm tự động cho nó một khi nó đã được sửa.

Ví dụ, một vài tháng trước tôi đã sửa một lỗi chỉ xảy ra khi người dùng gõ nhanh hơn 96 từ mỗi phút. Trước khi tôi sửa nó, tất cả những gì tôi biết là lỗi đã xảy ra "đôi khi". Nó sẽ không bao giờ xảy ra với tôi để viết một bài kiểm tra đơn vị để gõ nhanh. Tuy nhiên, sau khi tôi biết nguyên nhân gốc rễ, làm một bài kiểm tra cho nó là chuyện nhỏ.

Ngay cả trong những trường hợp hiếm hoi mà lỗi không thể được sao chép ngay cả sau khi được sửa, bạn vẫn có thể đóng nó bằng cách kiểm tra mã.