Tôi đã thấy nhiều API liệt kê chi tiết về các vấn đề đã biết? Nếu có sự cố đã biết, hãy giải phóng vấn đề trước khi sửa chúng?Nếu có "sự cố đã biết", tại sao lại phát hành?
Lý do là gì? Đường chết? Hoặc sửa chữa có thể phá vỡ cái gì khác?
Lưu ý: Tôi không chắc liệu câu hỏi này có thuộc về đây hay không. Vì vậy, cảm thấy tự do để đóng nếu đây không phải là một câu hỏi hợp lệ.
Phần mềm không hoàn hảo và chờ đợi cho đến khi mọi vấn đề được khắc phục để phát hành điều gì đó sẽ dẫn đến thế giới phần mềm.
Chính xác. –
Vâng, tôi sẽ không đi xa đến thế. Có rất nhiều lý do tốt để phát hành phần mềm có vấn đề đã biết, nhưng nói chung là lười biếng và nói rằng tất cả các phần mềm có lỗi không phải là một trong số đó. Mặc dù đúng là hầu như tất cả các phần mềm đều có lỗi, nhưng nó phải được xem như là một VẤN ĐỀ với tình trạng kỹ nghệ phần mềm trong ngày và tuổi tác, và không phải là một kết luận bỏ qua. –
Bạn có thấy nó như là một vấn đề mà mỗi tòa nhà từng được xây dựng có sai sót và không hoàn hảo, các vết nứt và các cấu trúc lệch không? Sự thật là hầu như không thể viết phần mềm của bất kỳ kích thước đáng kể nào không có bất kỳ sai sót nào. Có sự khác biệt lớn giữa "khả thi về mặt kỹ thuật" và "khả thi về mặt thương mại". –
Lý do chính là thời gian để thị
vấn đề đã biết thường ảnh hưởng đến một số ít người sử dụng, và tất cả mọi người khác có thể thực sự sử dụng những cải tiến trong phiên bản mới. Hơn nữa, các vấn đề tương tự có thể tồn tại với phiên bản hiện tại, trong trường hợp này, không có lỗi mới (đã biết) nào được cung cấp cho người dùng. Vì vậy, nó thực sự là một chiến thắng.
Một số vấn đề cũng có thể mất nhiều thời gian để khắc phục.
Bởi vì phần mềm có thể sử dụng được và hữu ích, ngay cả với các vấn đề và vì người dùng muốn có nó sớm hơn là đợi bản phát hành. Bởi vì các nhà phát triển của nó muốn các phản hồi phát hành nó sớm sẽ cung cấp.
Có luôn sự cố đã biết. Nếu bạn không phát hành cho đến khi không có vấn đề gì được biết đến nhiều hơn, bạn sẽ không bao giờ phát hành. Đôi khi tốt hơn là nên có một phiên bản chủ yếu làm việc ra khỏi cửa với các cảnh báo về một số vấn đề không quan trọng.
Thường thì phần mềm mới hơn vẫn tốt hơn các phiên bản trước đó, ngay cả với các sự cố đã biết. Đặc biệt là khi giao dịch với các thư viện, khách hàng thường muốn có mã được phân phối sớm hơn mà có vấn đề hơn là chờ đợi các vấn đề mà họ không quan tâm để cố định.
Đôi khi lợi ích của việc phát hành nội dung nào đó hoạt động quan trọng hơn các vấn đề chỉ một số người dùng sẽ bị tấn công.
Lỗi có thể rất nhỏ hoặc quan trọng: S
Đôi khi bạn không thể khắc phục những vấn đề đó.
Hãy tưởng tượng rằng bạn có tập lệnh JS và một số lỗi trong trình duyệt mà bạn không thể tránh. Sau đó, bạn sẽ không phát hành thư viện của mình cho đến khi trình duyệt đó được sửa, phải không? Hoặc bạn có thể chỉ cần thêm một "vấn đề đã biết" lưu ý về một vấn đề trình duyệt và phát hành nó.
Lợi nhuận.
Phần mềm thế giới thực của bất kỳ sự phức tạp nào sẽ không bao giờ trở nên hoàn hảo. Tuy nhiên, có một điểm nhất định là "đủ tốt", và đó là lúc đến lúc giao hàng.
Cuộc tranh luận thực sự xảy ra khi quyết định mức chất lượng nào đáp ứng thanh "đủ tốt".
Nếu tác động thấp (ảnh hưởng đến ít người dùng hoặc có thể là nội bộ) thì đó có thể là một lý do. Những người khác có thể là những bộ tóc giả lớn muốn thứ ra và trên thị trường càng sớm càng tốt, vì vậy đôi khi mọi thứ phải được để lại không đầy đủ dựa trên một số yếu tố.
Đặc biệt với các dự án nguồn mở, điều này cho phép phần lớn người dùng lấy sản phẩm mà không gặp sự cố và cũng nâng cao nhận thức về lỗi để người dùng có thể đóng góp vào mã.
Nếu không bạn sẽ không bao giờ được thả.
Sự cố đã biết là tốt. Đó là sự cố không rõ gây ra sự cố.
Nếu sự cố đã biết chỉ ảnh hưởng đến một tỷ lệ phần trăm nhỏ người dùng tiềm năng, thì điều đó có thể đáng giá.
API là hợp đồng giữa người triển khai API và lập trình viên sử dụng API. Ngay cả khi việc triển khai đã có các vấn đề đã biết, tốt nhất là phát hành tài liệu API, để các lập trình viên có thể bắt đầu phát triển mã có thể tận dụng API. Điều này được hiểu rằng các nhà cung cấp của việc thực hiện sẽ (cuối cùng) thực hiện kết thúc hợp đồng của họ, đưa việc thực hiện vào sự phù hợp hoàn toàn với API. Nếu API chỉ được phát hành khi triển khai hoàn hảo, thì các nhà phát triển ứng dụng sẽ bị buộc phải lãng phí một lượng thời gian phát triển khổng lồ mà họ có thể làm việc hiệu quả, ngay cả khi chỉ dựa trên tài liệu API và họ không thể thực sự kiểm tra mã.
Vì phần mềm là ổn định. Nếu có một vài vấn đề đã biết không ảnh hưởng trực tiếp đến việc sử dụng phần mềm hàng ngày và có thể được sửa trong các bản vá, thì tại sao không phát hành nó?
Cộng với thời hạn và chi phí cần xem xét, nhưng rõ ràng sau này không thực sự áp dụng cho Nguồn mở.
"Cam kết".
Điều đó quan trọng hơn.
Sau khi ngày giao hàng được hoàn thành (Cam kết), sản phẩm phải được phát hành nếu nó ở mức "Có thể chấp nhận". Sự khác biệt giữa "Perfection" và "Chấp nhận" là "Vấn đề được Biết"
Hầu hết các công ty có một tiêu chí đưa ra mà có thể trông như-
Phần mềm phát hành có thể có một số lỗi nhỏ mà đếm được đặt thành một giới hạn - Các vấn đề như vậy có thể là các vấn đề giao diện người dùng phụ.
Bản phát hành phần mềm có thể có một số lỗi lớn có số lượng được đặt thành giới hạn - Nỗ lực được thực hiện để làm cho bản phát hành không bị lỗi, nhưng nếu chúng vẫn thoát (do các lý do khác nhau) thì chúng không được phá vỡ sản phẩm và có một số công việc xung quanh có sẵn để có được xung quanh họ.
Phát hành phần mềm không có bất kỳ lỗi nghiêm trọng nào - Phần mềm sẽ không được chuyển nếu có bất kỳ lỗi nghiêm trọng nào được tìm thấy. Những lỗi như vậy phá vỡ sản phẩm mà không có cách giải quyết nào.
Một lần nữa, các phân loại được đề cập ở trên có thể nằm ngoài mục tiêu và phụ thuộc vào công ty và quy trình của chúng có liên quan.
cổ vũ
Xem lợi ích của chính sách phát hành sớm/phát hành thường xuyên, ví dụ: phản hồi vô giá của người dùng của bạn.
Thời gian và thủy triều chờ đợi không có người đàn ông. – maxaposteriori
$$$$$$$$$$$$$$$$$$$$$$$$ – Troggy
Giống như chọn đối tác - khi hoàn hảo, đến cuối – peterchen