Tại sao phần mềm vẫn được phát hành với các lỗi đã biết? [đóng cửa]

Dường như thường xuyên trong các dự án lớn, phần mềm vẫn được phát hành với trình theo dõi lỗi đầy lỗi. Bây giờ tôi có thể hiểu các yêu cầu tính năng, nhưng nhiều lần tôi đã thấy một số lượng lớn lỗi vẫn chưa được giải quyết, chưa được xem xét hoặc chưa hoàn thành nhưng một bản phát hành vẫn bị đẩy ra.

Tại sao? Tại sao một dự án nguồn mở hoặc một dự án nói chung sẽ được phát hành với các lỗi đã biết ? Tại sao họ không đợi cho đến khi trình theo dõi lỗi có 0 lỗi mở?

Bất kỳ lý do, bao gồm:

1. Công ty đã cam kết với cơ sở người dùng để phát hành tại một thời điểm cụ thể
2. Lỗi không phải là nhiệm vụ quan trọng, hoặc thậm chí là lớn
3. Phát triển tính năng mới được xem là quan trọng hơn (cho dù chính xác hay không)

Ở một mức độ nhỏ, điều này giống như hỏi tại sao bạn làm việc như một lập trình viên mặc dù kiến ​​thức lập trình của bạn không "hoàn chỉnh". Trong hầu hết các dự án phức tạp, sẽ có nhiều, rất nhiều lỗi. Đối phó với chúng trong khi thêm các tính năng mới là một nhiệm vụ khó khăn, phức tạp.

Bởi vì một phần mềm có lỗi tốt hơn là không có phần mềm nào cả.
Cho cùng một lý do:

• Các công ty vận tải bận tâm lên lịch trình, mặc dù luôn luôn có sự chậm trễ.
• Các công ty dược phẩm bán thuốc với các tác dụng phụ đã biết (và hầu hết được ghi nhận).
• Các trường học trên khắp thế giới dạy vật lý Newton, mặc dù nó có những hạn chế đã biết.

Có một giải pháp với những thiếu sót đã biết là tốt hơn nhiều so với việc không có giải pháp, hoặc có một giải pháp với những thiếu sót chưa biết.
IDE yêu thích của tôi có rất nhiều tính năng mới, không ổn định. Chúng ta chỉ nói: Tôi thích, phải làm một cái gì đó bằng tay mỗi lần thứ hai mươi, vì tính năng không thành công, thay vì phải làm tất cả bằng tay.

Hoặc để nói với lời của Voltaire: "Le mieux est l'ennemi du bien."

Cuối cùng, đó là một quyết định kinh doanh, ngay cả đối với phần mềm nguồn mở và miễn phí. Có một điểm mà các lỗi tồn tại có tác động thấp mà tốt hơn là phát hành, đưa phần mềm của bạn vào tay người dùng và nhận phản hồi (bao gồm, nhưng không giới hạn, các yêu cầu tính năng và báo cáo lỗi mới không tìm thấy trong thử nghiệm). Quyết định này được thúc đẩy bởi sự cần thiết phải có được lực kéo trên thị trường phần mềm giữa các đối thủ cạnh tranh. Nếu bạn muốn phần mềm của mình tạo ảnh hưởng, bạn cần đánh bại các đối thủ để tiếp thị với các tính năng hoặc khái niệm mới.

tất cả mọi thứ sôi xuống để phân tích chi phí so với lợi ích. Mỗi sửa lỗi có một số giá trị chi phí liên quan đến nó (thời gian sửa lỗi, rủi ro thực hiện nhiều thay đổi mã hơn X ngày trước khi phát hành ...). Đồng thời, mỗi sửa lỗi rõ ràng mang lại giá trị bổ sung về nhiều tính năng, khả năng sử dụng, v.v.

Vì vậy, đây là câu hỏi mà mọi nhóm phát triển phải đối mặt khi phát hành: 1) là Bug #i có giá trị sửa chữa với chi phí và giá trị bổ sung và 2) lặp lại cho tất cả các lỗi mở từ i = 0 đến N.

Hãy nhớ rằng một sản phẩm phần mềm không được phát hành KHÔNG có giá trị với bất kỳ ai. Sản phẩm phần mềm có 200 lỗi nổi bật nhưng có 90% chức năng hoạt động, có giá trị cho tất cả những người hài lòng với những gì hoạt động tại thời điểm phát hành.

Tôi chưa bao giờ ở bất kỳ công ty nào trên bất kỳ sản phẩm nào được phát hành với 0 lỗi và tôi nghĩ điều đó hoàn toàn bình thường. Tại một số điểm, bạn chỉ cần cắt lỗ và tận dụng những gì hoạt động. Nếu không, bạn sẽ không bao giờ phát hành bất cứ điều gì.

Trong một dự án lớn, bạn không bao giờ ngừng tìm lỗi. Nếu bạn phải đợi cho đến khi tất cả các lỗi được khắc phục và kiểm tra hồi quy sửa lỗi, bạn sẽ không bao giờ phát hành.

Ngoài ra, lưu ý rằng không phải tất cả các lỗi là nội bộ. Mọi chương trình là một phần của một web phức tạp của các phần mềm khác và những thay đổi ở nơi khác có thể tự biểu hiện là "lỗi" trong phần mềm của bạn. Bạn không thể ngăn chặn thế giới.

Ngoài nhiều câu trả lời hay, đôi khi còn có một cuộc đua vào thị trường với một sản phẩm mới. Nếu bạn nghĩ rằng bạn có thể giành được phần lớn thị phần ngay cả với 15% (hoặc một số số khác) các khuyết điểm không quan trọng mở ra, có thể đáng để phát hành sản phẩm để có được lợi thế với các đối thủ cạnh tranh.

Những lỗi này có thể là khá nhỏ. Hãy nhớ rằng phần mềm thương mại cần phải được vận chuyển, và nhấn vào đĩa, và những thứ như vậy. Đáp ứng những ngày phát hành có ý nghĩa tài chính nghiêm trọng và việc trì hoãn một số vấn đề nhỏ không phải là ý nghĩa tài chính - chưa kể đến việc cần phải đưa ra thị trường vì những lý do khác.

Câu trả lời tiềm năng:

• Rất khó có ai gặp phải lỗi này.
• Có cách giải quyết cho các lỗi.
• Phần mềm cần phải được phát hành vào lúc nào đó và sự hoàn hảo khó có thể đạt được.

Tôi chắc chắn lý tưởng là hầu hết các nhà phát triển muốn thấy không có lỗi trong ứng dụng của họ, điều đáng buồn là có thể không cho phép tình trạng không tưởng như vậy.

Tôi muốn tin điều đó bởi vì cơ sở người dùng yêu cầu các tính năng mới và sẵn sàng sử dụng cùng một hoặc nhiều lỗi để thêm chức năng.

Nếu có sự quản lý liên quan, thời hạn cần phải được đáp ứng vì nhiều lý do - lịch quảng cáo, vấn đề sẵn có của nhân viên, tư duy "chúng ta phải là người đầu tiên có chức năng này".

Ít lạc quan hơn trong tâm trí của tôi, có thể vì các nhà phát triển lười biếng?

Cũng cần nhớ rằng trong các cộng đồng nguồn mở, thông thường "ai" muốn nhận những gì yêu cầu lỗi / tính năng / vấn đề - có lẽ không ai muốn giải quyết các vấn đề hiện tại do các vấn đề lớn hơn đằng sau chúng.

Trong bài kiểm tra lập trình đơn giản nhất:

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

Mọi thứ luôn luôn là sự đánh đổi, cho dù đó là sửa lỗi, thời gian / không gian / bộ nhớ hay bảo mật / khả năng sử dụng. Hãy suy nghĩ về tính toán đánh đổi đã được thực hiện. Bạn có thể không đồng ý với nó, nhưng bạn sẽ gặp rắc rối nếu bạn không hiểu nó.

Ngoài ra, hãy suy nghĩ về những tính toán trong một đường cong hình chuông ... một số người sẽ thực hiện những tính toán thực sự xấu cho cả hai bên. Xem Duke Nukem Mãi mãi cho một đầu của đường cong.