เป็นหลักไม่ แต่คุณควรทำอย่างดีที่สุด ฉันจะอธิบายว่าทำไม (หรือข้ามไปยังข้อสรุปหากคุณไม่มีความอดทนเพียงพอ)
พิจารณาปัญหาที่ไม่สำคัญเท่ากับการใช้การค้นหาแบบไบนารี การใช้งานที่ได้รับความนิยมอย่างมากมีข้อผิดพลาดที่ตรวจไม่พบมานานกว่าสองทศวรรษ หากยี่สิบบรรทัดใช้เวลายี่สิบปีในการได้รับการใช้งานอย่างไม่มีข้อบกพร่องและได้รับการพิสูจน์แล้วว่าถูกต้องเราสามารถคาดหวังให้โปรแกรมขนาดใหญ่ปราศจากข้อผิดพลาดได้หรือไม่?
มีข้อบกพร่องกี่ตัวที่เราสามารถคาดหวังว่าโปรแกรมขนาดใหญ่จะมีอยู่แล้ว? หมายเลขหนึ่งที่ฉันพบคือ "10 ข้อบกพร่องต่อ 1,000 บรรทัด" (รหัสสมบูรณ์ฉบับที่ 2, หน้า 517 - ใช้เพียงตัวอย่างไม่อ้างอิงข้อมูลใด ๆ ) ที่ทำให้เรามีข้อบกพร่องประมาณ 200,000 ถึง 300,000 ในซอฟต์แวร์ของคุณ โชคดีที่เรามีวิธีในการปรับปรุงคุณภาพของโปรแกรม การทดสอบหน่วยการตรวจสอบรหัสและการทดสอบด้วยตนเองแบบปกตินั้นเป็นที่ทราบกันดีว่าลดจำนวนข้อผิดพลาด ถึงกระนั้นตัวเลขก็ยังคงสูง
ถ้าเราสามารถแก้ไขข้อผิดพลาดได้ทั้งหมด 95% ที่น่าเหลือเชื่อ และถึงกระนั้นเรายังคงมีข้อผิดพลาดในซอฟต์แวร์ถึง 10,000 ถึง 15,000 ข้อ
โชคดีเนื่องจากมีการใช้ซอฟต์แวร์อย่างกว้างขวาง (และดังนั้นการทดสอบอย่างกว้างขวาง) ข้อผิดพลาดที่จะพบ ดังนั้นเราจะค่อยๆได้รับข้อบกพร่องน้อยลง อย่างไรก็ตามข้อผิดพลาดที่น้อยลงก็หมายความว่าสิ่งที่เหลืออยู่นั้นหายากดังนั้นอย่าคาดหวังว่าเส้นโค้งเชิงเส้นในการแก้ไขข้อบกพร่อง ข้อผิดพลาดไม่กี่ข้อสุดท้ายจะยุ่งยากมากในการค้นหาและสามารถหลบหนีการตรวจจับเป็นเวลาหลายปี (สมมติว่าพวกเขาเคยพบ)
คุณดูเหมือนจะเข้าใจผิดคิดว่าหากซอฟต์แวร์ไม่เปลี่ยนแปลงจะไม่มีข้อบกพร่องใหม่เกิดขึ้น หากซอฟต์แวร์ขึ้นอยู่กับไลบรารี่ของบุคคลที่สามเวอร์ชันใหม่อาจทำลายคุณสมบัติบางประการ - แนะนำบั๊กใหม่แม้ว่ารหัสของแอปพลิเคชันจะยังคงเหมือนเดิม ระบบปฏิบัติการใหม่สามารถแบ่งแอปพลิเคชันที่ทำงานได้อย่างสมบูรณ์แบบก่อนหน้านี้ (ดู Windows Vista สำหรับตัวอย่างที่เป็นที่นิยม) พิจารณาข้อผิดพลาดคอมไพเลอร์ ฯลฯ
มันไม่ชัดเจนว่าเครื่องมือพิสูจน์รหัสสามารถแก้ปัญหาของซอฟต์แวร์ buggy ได้จริงหรือไม่ แน่นอนว่ามันเป็นไปไม่ได้ที่จะแก้ปัญหาการหยุดชะงักของโปรแกรมใด ๆ แต่มันอาจเป็นไปได้ที่จะพิสูจน์ว่าโปรแกรมทำงานตามที่ระบุไว้ ... แต่แล้วอะไรล่ะ? บางทีโปรแกรมพิสูจน์ข้อผิดพลาด บางทีสเปคนั้นอาจมีข้อผิดพลาด
เห็นได้ชัดว่าเราสามารถลดจำนวนข้อบกพร่องได้อย่างมาก แต่ไม่น่าเป็นไปได้ที่เราจะได้ศูนย์
เนื่องจากมีความคิดบางอย่างที่คุณแก้ไขทุกครั้งจะสร้างข้อบกพร่องมากขึ้น แต่ฉันไม่คิดว่าเป็นเรื่องจริง
(เน้นเพิ่ม)
คุณถูก. คำสั่งนี้ผิด นี่คือตัวอย่าง:
int main() {
int x[10];
x[10] = 8; //Buffer overflow here
return 0;
}
ตอนนี้เรามาแก้ไขข้อผิดพลาดนี้:
int main() {
int x[11];
x[10] = 8; //No buffer overflow here
return 0;
}
ดู? เราแก้ไขข้อผิดพลาดและไม่แนะนำสิ่งใหม่
อย่างไรก็ตามมันถูกต้องแน่นอนว่าทุกครั้งที่คุณแก้ไขข้อผิดพลาดที่คุณมีความเสี่ยงในการสร้างขึ้นใหม่ถึงแม้ว่าความเสี่ยงนี้สามารถลดลงได้ (เช่นกับการทดสอบหน่วย)
สมมติว่าสำหรับทุก ๆ 100 ข้อบกพร่องที่ฉันแก้ไขฉันตั้งใจแนะนำใหม่ ดังนั้นถ้าฉันแก้ไขข้อผิดพลาด 10,000 ข้อฉันแนะนำข้อบกพร่องใหม่ 100 ข้อ และถ้าฉันแก้ไขบั๊กใหม่เหล่านั้นฉันจะแนะนำบั๊กตัวหนึ่ง แต่อะไรนะ ตอนนี้โปรแกรมมีข้อผิดพลาดน้อยลง 999 รายการดังนั้นจึงน่าจะดีกว่าเดิม (สมมติว่าข้อผิดพลาดใหม่ไม่เลวร้ายที่สุดครั้งที่แล้ว 10,000 เท่า)
นอกจากนี้การแก้ไขข้อผิดพลาดสามารถเปิดเผยสิ่งใหม่ได้ แต่ข้อผิดพลาดเหล่านั้นสามารถแก้ไขได้เช่นกัน หากคุณทำสิ่งที่ถูกต้องในที่สุดซอฟต์แวร์จะอยู่ในสถานะที่ดีขึ้นกว่าที่เคยเป็นมา
ฉันแก่แล้วโดยโปรแกรมเมอร์ระดับสูงไม่กี่คนที่ดีกว่าที่จะไม่แก้ไขข้อผิดพลาดมากมายเนื่องจากความคิดที่ฉันพูดถึงใน OP
พฤติกรรมนี้ไม่ประมาท หากมีข้อบกพร่องและคุณสามารถแก้ไขได้ ทำมัน. แน่นอนคุณควรทำอย่างดีที่สุดเพื่อป้องกันการเพิ่มใหม่ แต่ถ้าฉันแนะนำหนึ่งข้อบกพร่องเล็ก ๆ สำหรับทุกข้อบกพร่องร้ายแรง 10 ที่ฉันแก้ไขนั่นไม่ใช่เหตุผลที่ถูกต้องเพื่อหยุดแก้ไขข้อบกพร่อง ในความเป็นจริงมันเป็นเหตุผลที่ดีที่จะให้แก้ไขข้อบกพร่อง
ข้อบกพร่องที่คุณแก้ไขน้อยลงข้อบกพร่องที่น้อยลงจะกลับมาที่คุณอีกในอนาคต
ยิ่งบั๊กที่คุณแก้ไขน้อยลงเท่าไหร่ก็ยิ่งมีข้อบกพร่องมากขึ้นในซอฟต์แวร์ของคุณ แน่นอนพวกเขาจะไม่ "กลับมาหาคุณอีกในอนาคต" พวกเขาจะไม่กลับมาเพราะพวกเขาไม่เคยทิ้งตั้งแต่แรก ความคิดของ "กลับมา" เกี่ยวข้องกับความถดถอย อีกครั้งเป็นไปได้ที่จะลดความเสี่ยงของการถดถอย
ข้อผิดพลาดบางอย่างไม่สามารถแก้ไขได้เนื่องจากพวกเขาใช้กันอย่างแพร่หลายจนผู้คนเริ่มพึ่งพาพวกเขาและการแก้ไขข้อผิดพลาดจะทำให้โปรแกรมสำหรับผู้ใช้เหล่านั้นพัง มันเกิดขึ้น. อย่างไรก็ตามพวกเขาจะได้รับการพิจารณาข้อบกพร่องในกรณีนั้นจริง ๆ หรือไม่?
ความคิด "แก้ไขข้อผิดพลาดสร้างข้อผิดพลาด" อาจเกี่ยวข้องกับสัตว์ประหลาดที่น่ากลัวนั่น - รหัสที่อ่านไม่ได้และไม่สามารถที่จะสัมผัสได้เพียงแค่สร้างมันขึ้นมา หากคุณมีสัตว์ประหลาดในฐานรหัสของคุณคุณอาจต้องยกเลิกการทำให้เป็นสัตว์ประหลาดก่อนที่จะทำอะไรให้เสร็จ
ในที่สุดหากคุณเป็นโปรแกรมเมอร์ที่น่ากลัวมีความเสี่ยงที่สิ่งใดก็ตามที่คุณสัมผัสจะสร้างข้อบกพร่องใหม่ สิ่งนี้จะทำให้โปรแกรมเมอร์อาวุโสรู้สึกประหม่า อย่างไรก็ตามการพูดว่า "อย่าทำอะไรอย่าแตะอะไรเลยอย่าแม้แต่จะหายใจ" อาจไม่ใช่วิธีที่ถูกต้องในการสร้างสภาพแวดล้อมการทำงานที่ดี การศึกษาดีกว่า
สรุป:
- ซอฟต์แวร์ที่ได้รับฟีเจอร์ใหม่ ๆ มากมาย แต่ไม่มีการแก้ไขข้อผิดพลาดอย่างเด็ดขาด
- ซอฟต์แวร์ที่ได้รับคุณสมบัติใหม่จำนวนปานกลาง แต่การแก้ไขข้อบกพร่องมีโอกาสที่ดีกว่าในการใช้งาน
- ผู้ที่พยายามมีข้อบกพร่องเล็กน้อยมีข้อผิดพลาดน้อยลง (โดยเฉลี่ย) กว่าผู้ที่ไม่สนใจ
- ไม่มีเหตุผลที่จะคาดหวังว่าโปรแกรมจะปราศจากข้อผิดพลาดในที่สุด
- โปรแกรมเมอร์อาวุโสไม่จำเป็นต้องมีความสามารถ
- แก้ไขข้อบกพร่องของคุณ
- ใช้ระเบียบวิธีที่ช่วยปรับปรุงคุณภาพซอฟต์แวร์ของคุณ