Trách nhiệm tái tạo lỗi

Tôi đang phát triển một chương trình sử dụng một thư viện được tạo bởi một lập trình viên khác (anh ta làm việc trong cùng một công ty). Gần đây tôi phát hiện ra một rò rỉ trong thư viện, xảy ra trong một số điều kiện mạng sau một vài giờ chạy. Tôi đã gửi một lỗi với mô tả các điều kiện để làm cho rò rỉ này xảy ra. Nhà phát triển đó đã trả lời rằng "điều này là không đủ", "đó không phải là trách nhiệm của anh ta trong việc tái tạo lỗi" và tôi phải tạo ra thử nghiệm đơn vị để tái tạo lỗi này, nếu không anh ta không làm gì cả.

1. Anh ấy có đúng không?
2. Tôi có thể làm gì trong tình huống này? Tạo thử nghiệm đơn vị là không thể, bởi vì nó phụ thuộc vào một số thời gian mạng ngẫu nhiên.

Anh ấy có đúng không có lẽ là một câu hỏi không thể trả lời mà không biết công ty của bạn. Tuy nhiên, anh ta chắc chắn không hữu ích lắm.

Tôi sẽ gây ra lỗi với anh ta (mà bạn đã làm), nếu nó gây ra sự cố với dự án của bạn thì tôi sẽ nêu ra nó như là một trình chặn với người quản lý dự án của bạn và nói rõ rằng bạn đã đưa ra lỗi phù hợp người nhưng nó sẽ ảnh hưởng đến dự án của bạn nếu nó không được sửa chữa kịp thời.

Tôi cũng sẽ đến và nói chuyện với nhà phát triển và giải thích lý do tại sao không thể tạo ra các bài kiểm tra đơn vị nhưng bạn sẽ vui lòng cho anh ấy xem nó trên máy của bạn (giả sử điều đó là khả thi?).

Anh ta có quyền 100% rằng bạn phải cung cấp đủ thông tin để làm cho lỗi có thể tái tạo - nếu không thì không có cơ hội để tìm hiểu xem bất kỳ sửa chữa nào anh ta cung cấp sẽ thực sự hoạt động.

Nhưng - anh ấy đã sai 100% rằng điều này phải ở dạng thử nghiệm đơn vị. Nếu bạn có thể mô tả một kịch bản thử nghiệm theo cách để anh ta có thể tái tạo thất bại (ít nhất là với xác suất cao trong một khoảng thời gian hợp lý hoặc bằng thử nghiệm thủ công), bạn có một bằng chứng cho thấy vấn đề tồn tại - điều này sẽ đặt ra cho đồng nghiệp của bạn trong trách nhiệm sửa chữa nó. Tất nhiên, nếu bạn có thể tạo một kịch bản tái tạo lỗi nhanh hơn, điều đó sẽ hữu ích cho anh ta. Lý tưởng nhất, người ta sẽ thực hiện một bài kiểm tra tự động từ đó, và nó phụ thuộc vào tổ chức của bạn, người chịu trách nhiệm cho việc này.

Cả hai bên nên nỗ lực.

Nhà phát triển thư viện nên đặt một số nỗ lực bổ sung ngay cả khi không có bài kiểm tra đơn vị, vì một số vấn đề không thể được sao chép bằng bài kiểm tra đơn vị. Đôi khi, đó là phần cứng, đôi khi đó là một số hành động chính xác cụ thể từ phần còn lại của chương trình khiến thư viện tạo ra kết quả xấu.

Bạn nên đặt thêm một số nỗ lực, bởi vì sau tất cả, đây không phải là lỗi trong thư viện, nhưng kết quả của các hành động không chính xác từ phần còn lại của chương trình (ví dụ, heap bị hỏng có thể khiến bất kỳ thư viện nào hoạt động kỳ lạ). Vì vậy, sẽ tốt hơn nếu giảm càng nhiều mã thư viện không liên quan đến việc sao chép lỗi. Và bạn có thể sẽ làm điều này nhanh hơn và sạch hơn một người không quen thuộc với mã ứng dụng của bạn.

Nếu tác giả của thư viện không thể sao chép lỗi dựa trên báo cáo của bạn, thì thật vô lý khi hy vọng anh ta dành nhiều thời gian cho nó, chứ đừng nói đến việc sửa nó.

Nhưng bạn cũng có một khoảng thời gian giới hạn dành cho việc làm một sản phẩm ngoại vi theo sở thích của bạn. Thật không may, điều này có thể có nghĩa là lỗi vẫn tiếp tục tồn tại và không có công việc nào được thực hiện để giải quyết nó.

May mắn thay, đây không hẳn là một thảm họa - trong khi trong một thế giới lý tưởng, tất cả các phần mềm sẽ không có lỗi, đó không phải là vấn đề, và vì vậy chúng tôi phải ưu tiên dựa trên các vấn đề mà nó gây ra cho Hoa Kỳ.

Điều này có nghĩa là bạn thực sự có trách nhiệm phát triển một trường hợp thử nghiệm có thể lặp lại NẾU BẠN MUỐN NÓ CỐ ĐỊNH. Bạn có thể không quan tâm liệu nó có được sửa hay không, và trong trường hợp đó, bạn đã làm mọi thứ có thể và nên được mong đợi ở bạn. Bạn có thể muốn nó cố định, nhưng không đủ để dành thời gian để làm cho nó có thể tái tạo tại thời điểm này. Điều đó là hoàn toàn chấp nhận được.

Báo cáo một lỗi với khả năng tốt nhất của bạn trong thời gian bạn phải đối phó với nó đơn giản là quyền công dân tốt, bạn không cần phải vượt qua điều đó trừ khi điều đó là cần thiết cho chương trình của bạn. Và bạn có thể không muốn làm như vậy ngay cả khi đó, có thể có một thư viện khác mà bạn có thể sử dụng, hoặc có thể tự cuộn trong một khoảng thời gian hợp lý. Về cơ bản, tùy thuộc vào bạn để quyết định những gì và loại nỗ lực nào xứng đáng với bạn.

Tôi có khuynh hướng để cho những con chó đang ngủ nói dối bây giờ - bạn đã nêu ra vấn đề và nó được giao cho anh ta. Có lẽ có các quy trình tại chỗ để theo dõi các lỗi nổi bật và đuổi theo chúng?

Nếu bạn muốn chủ động tiến triển vấn đề này hơn nữa, tôi khuyên bạn nên nói chuyện với người quản lý của mình để xem liệu có bất kỳ công cụ kiểm tra nào có thể tái tạo vấn đề một cách đáng tin cậy không.

Từ phía nhà phát triển - sẽ rất nghiêm túc khi họ không làm gì khi bạn cung cấp thông tin cần thiết. Tuy nhiên, có thể họ có khối lượng công việc lớn nên không thể dành thời gian cần thiết để theo dõi vấn đề.

Bạn đã tìm thấy một lỗi, bạn đã báo cáo và anh ta là một kẻ ngốc về nó.

Nếu hai bạn là bạn thân, anh ấy sẽ làm gì đó để giúp đỡ, nhưng anh ấy chỉ muốn đẩy vấn đề trở lại.

Bạn có thể làm nhiều hơn, bằng cách báo cáo thêm chi tiết và cố gắng hỗ trợ cho khiếu nại của mình rằng nó bị rò rỉ bộ nhớ. Tuy nhiên, bạn có trách nhiệm của riêng mình và cần hoàn thành công việc của riêng bạn.

Đăng nhập càng nhiều thông tin vào trình theo dõi lỗi càng tốt và tiếp tục.

Nếu bạn gặp lại người này trong tương lai. Hãy thân thiện, cố gắng nói về những lợi ích chung và hiểu rằng các mối quan hệ tốt là cách hiệu quả hơn nhiều để khiến mọi thứ được cố định, sau đó bất kỳ số lượng sự kiện nào bạn có thể cung cấp để hỗ trợ cho yêu cầu bồi thường.

Thông thường, những gì tôi gặp phải trong các tình huống tương tự là một giả định rằng tất cả các lỗi nên được sửa chữa và trong khi đáng ngưỡng mộ, đó chắc chắn là một mục tiêu tuyệt vời (hãy đối mặt với điều đó chúng tôi không bao giờ đặt ra để viết lỗi!) Cuối cùng là không thực tế bất kỳ dự án nào có kích thước phù hợp để sửa lỗi chỉ vì đó là một lỗi (nếu bạn có thể tìm thấy nó!) Đó là lý do tại sao chúng tôi có phương pháp quản lý dự án và mã hóa, mô hình & thực tiễn, v.v.

Vì vậy, một điều tôi muốn nói trong việc bảo vệ chủ sở hữu thư viện (và đã xảy ra khi tôi làm việc cho một số dự án lớn) là thời gian dành cho nhà phát triển tốn kém tiền bạc và là một nguồn tài nguyên hữu hạn nên quyết định về cách báo cáo được xử lý , người điều tra, những thử nghiệm nào được tạo ra / cần thiết và cuối cùng là nếu (và nếu vậy, khi nào) một bản sửa lỗi được đưa ra hoàn toàn dựa trên tác động kinh doanh. Tác động của việc khởi động lại quá trình chạy dài của bạn thỉnh thoảng là gì nếu nó không thành công và bạn có thể dễ dàng tự động hóa điều đó thay vào đó (và có lẽ bạn không nên là một biện pháp lập trình phòng thủ?) Chỉ là thời gian hay còn nhiều hơn thế ?

Cũng xem xét từ quan điểm của họ, một báo cáo lỗi từ một người dùng về một vấn đề không thể đoán trước trong một đoạn mã rất hiếm khi xảy ra, chỉ kết hợp với mã của họ, có thể chỉ trên một máy và chỉ trong một bộ thời gian bất thường điều kiện sẽ không có lý do chính đáng cho một khối lượng lớn thời gian để tìm và sửa chữa - nếu nó thậm chí có thể. Nhưng nếu đó là một trường hợp kinh doanh đủ mạnh để người dùng đó muốn / cần dành thời gian để điều tra kỹ lưỡng hơn và cung cấp một trường hợp / ứng dụng thử nghiệm đáng tin cậy hoặc mô tả vấn đề chi tiết hơn so với trường hợp ban đầu thì đó có thể là một trò chơi bóng khác .

Đây có lẽ là một vấn đề truyền thông mà chủ sở hữu thư viện đã không cân nhắc khi đưa nó theo cách đó và nếu bạn gặp trường hợp kinh doanh mạnh (chẳng hạn như mã của bạn gây tốn kém cho doanh nghiệp, có yêu cầu tuân thủ pháp lý, lỗ hổng bảo mật hoặc có một số hiệu ứng kích nổ lớn khác) sau đó đã đến lúc đưa nó lên quản lý và để họ chiến đấu với nó.

Bạn đã đề cập rằng 'Tôi đã gửi một lỗi với mô tả các điều kiện để làm cho rò rỉ này xảy ra.'

Nếu bạn chắc chắn rằng mô tả đó thực sự đủ để tái tạo lỗi thì bạn đã biết điều kiện chính xác. Bây giờ, nếu bạn không thể viết kiểm thử đơn vị sau khi biết điều kiện, thì điều đó có nghĩa rõ ràng là bạn không thể chế nhạo một số thành phần liên quan hoặc một số phần của mã được ghép quá chặt để cho phép tạo thử nghiệm đơn vị thực tế.

Bạn nên yêu cầu chủ sở hữu thư viện mã cấu trúc lại để cho phép bạn tạo bài kiểm tra đơn vị. Bạn sẽ phải giải thích rõ ràng những gì trong thư viện đang ngăn bạn tạo bài kiểm tra đơn vị. Anh ta sẽ phải cấu trúc lại mã nếu không thừa nhận rằng kiểm tra đơn vị là không thể với mã hiện tại. Cả hai cách, bạn đều thắng.

Nếu điều này không hoạt động, sau đây là các tùy chọn bạn có:

• Bạn có thể tái tạo lỗi với nhiều bằng chứng hơn.
• Hãy thử liên quan đến thẩm quyền cao hơn và yêu cầu anh ấy / cô ấy đánh giá bằng chứng của bạn.
• Hãy thử sử dụng thư viện trong ứng dụng nguyên mẫu với môi trường giả để chỉ được mã hóa để tái tạo lỗi. Bằng cách đó, bạn sẽ có thể chứng minh ít nhất lỗi đó tồn tại.