เพราะเหตุใดซอฟต์แวร์จึงยังมีข้อบกพร่องที่ทราบ [ปิด]

ดูเหมือนว่าบ่อยครั้งในโครงการขนาดใหญ่ซอฟต์แวร์ยังคงเปิดตัวพร้อมตัวติดตามบั๊กที่เต็มไปด้วยข้อบกพร่อง ตอนนี้ฉันสามารถเข้าใจการร้องขอคุณสมบัติได้หลายครั้งที่ฉันเห็นข้อบกพร่องจำนวนมากยังไม่ได้รับการแก้ไขไม่ได้ตรวจสอบหรือไม่เสร็จ แต่ยังปล่อยออกมา

ทำไม? เหตุใดโครงการโอเพนซอร์ซหรือโครงการโดยทั่วไปจึงได้รับการเผยแพร่พร้อมข้อบกพร่องที่รู้จัก เหตุใดพวกเขาจะไม่รอจนกว่าเครื่องมือติดตามบั๊กจะมีข้อบกพร่องที่เปิด 0

ด้วยเหตุผลใดก็ได้รวมถึง:

1. บริษัท ได้ให้คำมั่นสัญญากับฐานผู้ใช้ในการเผยแพร่ในช่วงเวลาหนึ่ง
2. ข้อบกพร่องไม่ได้เป็นภารกิจที่สำคัญหรือแม้กระทั่งที่สำคัญ
3. การพัฒนาคุณสมบัติใหม่นั้นมีความสำคัญมากกว่า (ไม่ว่าจะถูกต้องหรือไม่ก็ตาม)

ในระดับเล็กน้อยนี่เป็นการถามว่าทำไมคุณถึงทำงานเป็นโปรแกรมเมอร์แม้ว่าความรู้ด้านการเขียนโปรแกรมของคุณจะไม่ "สมบูรณ์" ในโครงการที่ซับซ้อนที่สุดจะมีข้อบกพร่องมากมาย การจัดการกับมันในขณะที่เพิ่มคุณสมบัติใหม่นั้นเป็นงานที่ยากและซับซ้อน

เพราะซอฟต์แวร์ที่มีข้อบกพร่องนั้นดีกว่าซอฟต์แวร์เลย
ด้วยเหตุผลเดียวกัน:

• บริษัท ขนส่งกังวลกับการกำหนดตารางเวลาแม้ว่าจะมีความล่าช้าอยู่เสมอ
• บริษัท ยาขายยาที่มีผลข้างเคียงที่รู้จักกันดี
• โรงเรียนทั่วโลกสอนวิชาฟิสิกส์ของนิวตันแม้ว่ามันจะมีข้อ จำกัด ก็ตาม

การมีวิธีแก้ปัญหาที่มีข้อบกพร่องที่รู้จักกันดีกว่าไม่มีวิธีแก้ปัญหาหรือมีวิธีแก้ปัญหาที่มีข้อบกพร่องที่ไม่รู้จัก
IDE รายการโปรดของฉันมีคุณสมบัติใหม่ ๆ มากมายซึ่งอยู่ไกลจากความเสถียร สมมติว่าฉันต้องการทำบางสิ่งด้วยมือทุกครั้งที่ยี่สิบเพราะคุณสมบัติล้มเหลวแทนที่จะต้องทำด้วยมือทั้งหมด

หรือจะพูดด้วยคำของ Voltaire: "Le mieux est l'ennemi du bien"

ในที่สุดมันเป็นการตัดสินใจทางธุรกิจแม้สำหรับซอฟต์แวร์โอเพนซอร์สและฟรี มีจุดที่ข้อบกพร่องที่มีอยู่มีผลกระทบต่ำซึ่งดีกว่าที่จะปล่อยให้ใช้ซอฟต์แวร์ของคุณอยู่ในมือของผู้ใช้และรับข้อเสนอแนะ (รวมถึง แต่ไม่ จำกัด เพียงการร้องขอคุณสมบัติและรายงานข้อบกพร่องใหม่ที่ไม่พบ กำลังทดสอบ) การตัดสินใจครั้งนี้ได้แรงหนุนจากความต้องการที่จะได้รับแรงฉุดในตลาดสำหรับซอฟต์แวร์ของคู่แข่ง หากคุณต้องการให้ซอฟต์แวร์ของคุณสร้างผลกระทบคุณจะต้องเอาชนะคู่แข่งของคุณเพื่อทำการตลาดด้วยฟีเจอร์หรือแนวคิดใหม่ ๆ

ทุกอย่างเดือดลงถึงราคาและการวิเคราะห์ผลประโยชน์ การแก้ไขข้อบกพร่องแต่ละรายการมีค่าใช้จ่ายที่เกี่ยวข้อง (ชั่วโมงการแก้ไข, ความเสี่ยงของการเปลี่ยนแปลงรหัสเพิ่มเติม X วันก่อนการเปิดตัว ... ) ในขณะเดียวกันการแก้ไขข้อผิดพลาดแต่ละครั้งจะนำคุณค่าเพิ่มเติมในแง่ของคุณสมบัติเพิ่มเติมการใช้งานและอื่น ๆ อย่างชัดเจน

ดังนั้นคำถามนี้ทีมพัฒนาทุกคนต้องเผชิญเมื่อมีการปล่อย: 1) คือ Bug #i เป็นค่าคงที่ที่กำหนดค่าใช้จ่ายและมูลค่าเพิ่มเติมและ 2) ทำซ้ำสำหรับบั๊กที่เปิดทั้งหมดจาก i = 0 ถึง N

โปรดทราบว่าผลิตภัณฑ์ซอฟต์แวร์ที่ไม่ได้เปิดตัวนั้นไม่มีค่าสำหรับใคร ผลิตภัณฑ์ซอฟต์แวร์ที่มีข้อบกพร่องที่โดดเด่น 200 ข้อ แต่มี 90% ของฟังก์ชันการทำงานมีคุณค่าสำหรับทุกคนที่มีความสุขกับสิ่งที่ใช้งานได้ในช่วงเวลาของการเปิดตัว

ฉันไม่เคยอยู่ใน บริษัท ใด ๆ เกี่ยวกับผลิตภัณฑ์ใด ๆ ที่เปิดตัวด้วย 0 ข้อบกพร่องและฉันคิดว่ามันเป็นเรื่องปกติอย่างสมบูรณ์ ในบางจุดคุณเพียงแค่ลดความสูญเสียและใช้ประโยชน์จากสิ่งที่ได้ผล มิฉะนั้นคุณจะไม่ปล่อยอะไรเลย

ในโครงการขนาดใหญ่คุณจะไม่หยุดที่จะหาจุดบกพร่อง หากคุณต้องรอจนกว่าข้อบกพร่องทั้งหมดได้รับการแก้ไขและทดสอบการถดถอยการแก้ไขคุณจะไม่ปล่อย

นอกจากนี้โปรดทราบว่าไม่ใช่ข้อบกพร่องทั้งหมดที่อยู่ภายใน ทุกโปรแกรมเป็นส่วนหนึ่งของเว็บที่ซับซ้อนของซอฟต์แวร์อื่น ๆ และการเปลี่ยนแปลงที่อื่นสามารถแสดงให้เห็นว่าตัวเองเป็น "โรคจิต" ในซอฟต์แวร์ของคุณ คุณไม่สามารถหยุดโลกได้

นอกจากคำตอบที่ดีมากมายบางครั้งก็มีการแข่งขันในตลาดด้วยผลิตภัณฑ์ใหม่ หากคุณคิดว่าคุณสามารถได้รับส่วนแบ่งการตลาดเป็นส่วนใหญ่แม้จะมีข้อบกพร่องที่ไม่สำคัญถึง 15% (หรือตัวเลขอื่น ๆ ) มันอาจคุ้มค่าที่จะเปิดตัวผลิตภัณฑ์เพื่อให้ได้เปรียบคู่แข่ง

ข้อบกพร่องเหล่านี้อาจจะเล็กน้อย โปรดจำไว้ว่าซอฟต์แวร์เชิงพาณิชย์จะต้องมีการจัดส่งและกดบนแผ่นดิสก์และสิ่งต่าง ๆ การประชุมวันที่รีลีสนั้นมีผลกระทบทางการเงินอย่างรุนแรงและการล่าช้าสำหรับปัญหาเล็กน้อยบางอย่างนั้นไม่ใช่ความรู้สึกทางการเงิน - ไม่ต้องพูดถึงความจำเป็นในการออกสู่ตลาดด้วยเหตุผลอื่น

คำตอบที่เป็นไปได้:

• มันไม่น่าเป็นไปได้สูงที่ทุกคนจะพบข้อผิดพลาด
• มีวิธีแก้ไขสำหรับข้อบกพร่อง
• ซอฟต์แวร์จำเป็นต้องมีการเปิดตัวในบางครั้งและความสมบูรณ์แบบไม่น่าจะเกิดขึ้นได้

ฉันแน่ใจว่านักพัฒนาซอฟต์แวร์ส่วนใหญ่ต้องการเห็นข้อบกพร่องเป็นศูนย์ในแอปพลิเคชันของพวกเขาเงื่อนไขที่น่าเศร้าอาจไม่อนุญาตให้มีสถานะของยูโทเปีย

ฉันอยากจะเชื่อว่าเป็นเพราะฐานผู้ใช้ต้องการคุณสมบัติใหม่และยินดีที่จะรับข้อผิดพลาดเดียวกันหรือมากกว่าสำหรับการใช้งานที่เพิ่มขึ้น

หากมีการจัดการที่เกี่ยวข้องกำหนดเวลาจะต้องมีเหตุผลหลายประการเช่นตารางการโฆษณาปัญหาความพร้อมใช้งานของพนักงานเพิ่มเติมความคิดของ "เราต้องเป็นคนแรกที่มีฟังก์ชั่นนี้"

มองในแง่ดีน้อยลงในใจของฉันอาจเป็นเพราะนักพัฒนาขี้เกียจ?

โปรดจำไว้ว่าในชุมชนโอเพนซอร์สนั้นมักจะเป็น "คน" ที่ต้องการดำเนินการเกี่ยวกับคำขอบั๊ก / คุณสมบัติ / ปัญหา - บางทีอาจไม่มีใครต้องการจัดการกับปัญหาที่เกิดขึ้นเนื่องจากปัญหาใหญ่กว่าอยู่ข้างหลัง

ในการทดสอบทางโปรแกรมที่ง่ายที่สุด:

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

ทุกอย่างเป็นการแลกเปลี่ยนไม่ว่าจะเป็นการแก้ไขข้อบกพร่องเวลา / พื้นที่ / หน่วยความจำหรือความปลอดภัย / การใช้งาน คิดเกี่ยวกับการคำนวณการแลกเปลี่ยนที่เกิดขึ้น คุณอาจไม่เห็นด้วย แต่คุณมีปัญหาหากคุณไม่เข้าใจ

ลองนึกถึงการคำนวณในรูปโค้งระฆัง ... บางคนอาจทำให้คนที่ไม่ดีทั้งสองข้างได้ ดู Duke Nukem Forever สำหรับปลายด้านหนึ่งของโค้ง