เป็นไปได้หรือไม่ที่จะไปถึงสถานะข้อบกพร่องสัมบูรณ์เป็นศูนย์สำหรับซอฟต์แวร์ขนาดใหญ่?


71

ฉันกำลังพูดถึงโค้ดประมาณ 20-30 ล้านบรรทัดซอฟต์แวร์ในระดับและความซับซ้อนของ Autodesk Maya

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

เนื่องจากมีความคิดบางอย่างที่คุณแก้ไขทุกครั้งจะสร้างข้อบกพร่องมากขึ้น แต่ฉันไม่คิดว่าเป็นเรื่องจริง

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


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

51
หากคุณไม่ทราบว่ามีข้อบกพร่องอยู่หรือไม่
Blrfl

5
@Blrf: ที่สำคัญกว่านั้นถ้าผู้ใช้ไม่ทราบว่ามีข้อผิดพลาดมันมีอยู่หรือไม่?
mattnz

40
“ มีสองวิธีในการสร้างการออกแบบซอฟต์แวร์ วิธีหนึ่งคือทำให้ง่ายจนไม่มีข้อบกพร่องอย่างเห็นได้ชัด และวิธีอื่นคือทำให้มันซับซ้อนจนไม่มีข้อบกพร่องที่ชัดเจน” - CAR Hoare
Andrew Lewis

5
เป็น แต่คนจำนวนมากไม่ต้องการความเชื่อพื้นฐานของพวกเขาถาม
Joan Venge

คำตอบ:


92

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

ประเด็นสำคัญคือคุณประเมินความซับซ้อนของซอฟต์แวร์ต่ำเกินไปอย่างมาก

สิ่งแรกสิ่งแรก - คุณไม่สนใจภาพรวมที่ใหญ่กว่าของโปรแกรมของคุณทำงาน มันไม่ได้ทำงานแยกอย่างสมบูรณ์บนระบบที่สมบูรณ์แบบ แม้แต่พื้นฐานที่สุดของโปรแกรม "Hello World" ก็ยังใช้งานได้บนระบบปฏิบัติการดังนั้นแม้แต่โปรแกรมที่ง่ายที่สุดก็อาจมีข้อบกพร่องที่อาจมีอยู่ในระบบปฏิบัติการ

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

จากนั้นมีหัวข้อที่ต้องพิจารณา โปรแกรมขนาดใหญ่ส่วนใหญ่ใช้เธรดทั่วทุกที่ เราพยายามที่จะระมัดระวังและเขียนหัวข้อในลักษณะที่สภาพการแข่งขันและการหยุดชะงักไม่เกิดขึ้น แต่มันเป็นไปไม่ได้ที่จะทดสอบรหัสที่เป็นไปได้ทั้งหมด ในการทดสอบสิ่งนี้อย่างมีประสิทธิภาพคุณจะต้องตรวจสอบทุกคำสั่งที่เป็นไปได้ของคำสั่งผ่าน CPU ฉันยังไม่ได้ทำคณิตศาสตร์ในเกมนี้ แต่ฉันสงสัยว่าการแจกแจงเกมหมากรุกที่เป็นไปได้ทั้งหมดจะง่ายขึ้น

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

บรรทัดล่าง: คุณสามารถเขียน "ซอฟต์แวร์ฟรีที่เป็นข้อบกพร่อง" ได้หรือไม่?

NO

ใครก็ตามที่บอกคุณเป็นอย่างอื่นก็คือไม่เชื่อฟัง

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


แก้ไข: บางคนแสดงความคิดเห็นเกี่ยวกับจุดที่ยอดเยี่ยมที่ฉันมองข้ามอย่างสมบูรณ์: คอมไพเลอร์

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

รายการข้อผิดพลาดใน GCC ซึ่งเป็นหนึ่งในคอมไพเลอร์ที่ใช้กันทั่วไป: http://gcc.gnu.org/bugzilla/buglist.cgi?product=gcc&component=c%2B%2B&resolution=---


8
คำตอบยังคง "ไม่" เพราะจะมี "ข้อบกพร่อง" อยู่เสมอในบางสิ่งที่ใช้งานได้ - ไม่เหมือนกับลูกค้าหรือเจ้าของผลิตภัณฑ์ที่ต้องการให้มันทำงาน พวกเราบางคนอาจเรียกการร้องขอคุณสมบัติเหล่านี้หรือการร้องขอเพื่อเปลี่ยนพฤติกรรมหรือเพิ่มฟังก์ชั่น - แต่สำหรับคนที่ถูกรบกวนด้วย "บั๊ก" ทุกวันสิ่งที่รบกวนพวกเขาคือบั๊ก (นั่นเป็นวิธีที่ยาวในการบอกว่าข้อบกพร่องบางอย่างอยู่ในสายตาของคนดู) BUG FREE CODE เป็นไปไม่ได้ เล็งไปที่โค้ดที่ดีพอที่จะตอบสนองวัตถุประสงค์ที่ต้องการ
quick_now

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

11
@ JohnR.Strohm ฉันไม่แน่ใจว่าทำไมคุณคิดว่าโปรแกรม 'message flow modulator' ซึ่งเป็นโปรแกรมที่มีรหัส 556 บรรทัดมีคำถามอะไรเกี่ยวกับระบบ 20 ล้านบรรทัดในทางทฤษฎี ยกเว้นบางทีเพื่อแสดงให้เห็นว่าอย่างไรก็ตามยากที่จะพิสูจน์ความถูกต้องของโปรแกรมเล็ก ๆ มันจะยากในทางดาราศาสตร์ที่จะพิสูจน์ความถูกต้องของโปรแกรมขนาดใหญ่
Eric King เมื่อ

9
ในขณะที่คำถามดั้งเดิมไม่ได้ทำเช่นนั้นฉันอยากจะชี้ให้เห็นว่ามีความแตกต่างขนาดมหึมาระหว่าง ในขณะที่ฐานรหัส 20 ล้านบรรทัดที่ไม่มีข้อบกพร่องเป็นไปได้ทางทฤษฎีที่เป็นไปได้ แต่ก็เป็นไปไม่ได้ในทางปฏิบัติในตลาดปัจจุบัน ใครจะรู้ว่าอนาคตจะมีใคร
Eric King

4
@ JohnR.Strohm คุณควรอ่านกระดาษให้ละเอียดยิ่งขึ้น พวกเขาบอกว่าตัวเอง: It is important to note, however, that even all of these steps provide no guarantee of absolute security. It is tempting to believe that a formally specified and proved program should be absolutely correct, but there are several reasons why a proved program may not behave exactly as expected.- ความหมายมันไม่สามารถพิสูจน์ได้ว่าเป็นข้อบกพร่องฟรี แต่มีโอกาสน้อยกว่าที่จะมีข้อบกพร่อง ค่อนข้างชอบ TDD
Izkata

27

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

จวนพูดในระบบการทำงานของขนาดและขอบเขตที่คุณกำลังพูดถึงนี้เป็นไปไม่ได้ อาจใช้เวลา 1,000 ปีในการเขียนระบบ 'ปราศจากข้อผิดพลาด' และการเขียนระบบเพื่อพิสูจน์ว่าต้องใช้เวลามากขึ้นในการอธิบาย: คุณจะต้องมีทุกกรณีการใช้งานที่เป็นไปได้และเขียนระบบที่จะทดสอบแต่ละ ข้อหนึ่ง - และฉันไม่เชื่อว่ามีวิธีการพิจารณาว่าคุณได้ครอบคลุมทุกกรณีการใช้งานจริงในระบบที่มีขนาดและขอบเขตที่คุณกำลังพูดถึงในสิ่งที่มีลักษณะคล้ายกันกับจำนวนเวลาที่เหมาะสม

IMO คำถามของคุณผิดไปนิดหน่อย: เป้าหมายของเราในฐานะนักพัฒนาไม่ได้เขียนซอฟต์แวร์ 'ไร้ข้อบกพร่อง' เป้าหมายของเราคือการเขียนที่ใช้งานได้ยืดหยุ่นได้อย่างง่ายดาย maintainableซอฟแวร์

ใช้งานได้:ระบบปฏิบัติตามข้อกำหนดที่จำเป็นที่ออกแบบมา อาจมีข้อบกพร่อง - แต่พวกมันจะอยู่ใน 'edge edge' - ค่าผิดปกติหรือความน่ารำคาญไม่ใช่ข้อบกพร่องที่ทำให้ความรู้พื้นฐานของระบบแข็งแกร่งขึ้น

การบำรุงรักษา:บักสามารถแยกและแก้ไขได้ง่ายและไม่สร้างบั๊กใหม่

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

การออกแบบที่ดี, การปฏิบัติที่ดีการควบคุมการทำงานเป็นทีมที่ดีนักพัฒนาที่ขยันขันแข็ง - นั่นคือสูตรสำหรับซอฟต์แวร์ที่ดี (ไม่ใช่ที่สมบูรณ์แบบ - แต่ดีมาก )


3
"การพิสูจน์มันอาจเป็นไปได้ทางคณิตศาสตร์ด้วยการออกแบบระบบทดสอบที่จะใช้รหัสทุกบรรทัดในทุกวิถีทาง - ทุกกรณีการใช้งานที่เป็นไปได้": โปรแกรมดังกล่าวไม่มีอยู่ทั่วไป (และสิ่งนี้สามารถพิสูจน์ได้!) ดังนั้นอัลกอริทึมทั่วไปสำหรับการพิสูจน์ความถูกต้องจึงไม่มีอยู่
Giorgio

3
การแก้ไข: ซอฟต์แวร์ที่ปราศจากข้อผิดพลาดเสร็จสิ้นด้วยหลักฐานทางคณิตศาสตร์อย่างเป็นทางการที่ได้รับความสำเร็จ มันทำในปี 1982 Google "โมเดอเรเตอร์การไหลของข้อความ"
John R. Strohm

6
@ JohnR.Strohm: ไม่จริง นี่เป็นเพียงคำพูดเดียว - มีเอกสารหลายฉบับและอีกหลายแห่งที่พวกเขาพูดถึงความกังวลที่คล้ายกัน: "คำถามที่เกิดขึ้นบ่อยครั้งคือ" คุณตรวจสอบตัวยืนยันแล้วหรือยัง? "บางทีก็น่าแปลกใจที่คำถามวิศวกรคณิตศาสตร์ นักวิชาการแน่นอนว่าถ้าเครื่องจักรตอบคำถามที่ว่า "คุณเคยโกหกบ้างไหม?" คำตอบนั้นจะไม่มีข้อมูลมากไปกว่าตอนที่มนุษย์ตอบคำถาม "
เวกเตอร์

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

1
@Giorgio - IMO ดังนั้นการทำตามแนวทางการออกแบบที่ดีมีความสำคัญมากกว่าการคำนึงถึงความถูกต้องทางคณิตศาสตร์ของคุณ: ออกแบบรหัสของคุณเพื่อให้แน่ใจว่าสามารถบูรณาการและสอดคล้องกับสิ่งที่มีอยู่แล้ว - และแข็งแกร่งพอที่จะจัดการข้อบกพร่องได้ง่าย มาแสง (ซึ่งพวกเขาจะ)
เวกเตอร์

27

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

การอัพเกรดซอฟต์แวร์เพื่ออนุญาตให้รถรับส่งนำทางด้วยดาวเทียม Global Positioning Satell ส่งผลกระทบเพียง 1.5% ของโปรแกรมหรือโค้ด 6,366 บรรทัด รายละเอียดสำหรับการเปลี่ยนแปลงหนึ่งครั้งนั้นมี 2,500 หน้า รายละเอียดของโปรแกรมโดยรวมนั้นเต็ม 30 เล่มและวิ่ง 40,000 หน้าหรือเฉลี่ยสิบบรรทัดของรหัสต่อหน้าของสเป็ค

งบประมาณไม่ใช่ปัญหา - ที่ $ 35 พันล้านต่อปีพวกเขาสามารถทำสิ่งที่ถูกต้องได้


25
ตรวจพบข้อผิดพลาดหนึ่งข้อ ใครจะรู้ว่ามีข้อผิดพลาดที่ตรวจไม่พบจำนวนมากใคร :)
Andres F.

8
"ข้อผิดพลาดครั้งเดียว" นั้นเป็นกรณีพิเศษ เดิม Shuttle ได้รับการออกแบบและระบุซอฟต์แวร์สำหรับแขนหุ่นยนต์สองตัว "ข้อผิดพลาด" คือยังมีรหัสอยู่ในนั้นเพื่อรองรับแขนที่สอง
John R. Strohm

4
+1 วิ่งโดยไม่มีข้อผิดพลาดสำหรับ 135 ภารกิจตั้งแต่ 1981 ถึง 2011
MarkJ

5
@ MarkJ: เราอาจไม่รู้ว่า Space Shuttle ไม่มีข้อผิดพลาดหรือไม่ ทุกภารกิจกระสวยอวกาศมีการตรวจสอบอย่างต่อเนื่องโดยคนหลายร้อยคนและข้อผิดพลาดใด ๆ ในการเข้ารหัสจะได้รับการแก้ไข / แทนที่ด้วยตนเอง
Lie Ryan

2
@LieRyan ซึ่งแสดงคุณสมบัติที่ยอดเยี่ยมอย่างหนึ่งของระบบที่แข็งแกร่ง - หากพวกเขาไม่ได้ล้มเหลวอย่างหายนะและอนุญาตให้ทำการปรับเปลี่ยนด้วยตนเองคุณสามารถใช้ระบบที่ซ้ำซ้อน (เช่นระบบที่ศูนย์ควบคุม) เพื่อทำงานแทน แน่นอนว่ามันสมเหตุสมผลถ้าคุณมีระบบซ้ำซ้อนและถ้าคุณสามารถมั่นใจได้ว่าถูกต้องและสม่ำเสมอ ในแอปพลิเคชันทางธุรกิจทั่วไปความผิดพลาดมักจะดีกว่าในการใช้งานในสภาวะที่ไม่สอดคล้องกัน - เป็นความแตกต่างระหว่างความน่ารำคาญและการพูดการส่งเงินไปให้คนผิด หรือรับเงินโดยไม่ได้ถูกส่ง ...
Luaan

15

เป็นหลักไม่ แต่คุณควรทำอย่างดีที่สุด ฉันจะอธิบายว่าทำไม (หรือข้ามไปยังข้อสรุปหากคุณไม่มีความอดทนเพียงพอ)

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

มีข้อบกพร่องกี่ตัวที่เราสามารถคาดหวังว่าโปรแกรมขนาดใหญ่จะมีอยู่แล้ว? หมายเลขหนึ่งที่ฉันพบคือ "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 ที่ฉันแก้ไขนั่นไม่ใช่เหตุผลที่ถูกต้องเพื่อหยุดแก้ไขข้อบกพร่อง ในความเป็นจริงมันเป็นเหตุผลที่ดีที่จะให้แก้ไขข้อบกพร่อง

ข้อบกพร่องที่คุณแก้ไขน้อยลงข้อบกพร่องที่น้อยลงจะกลับมาที่คุณอีกในอนาคต

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

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

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

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

สรุป:

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

+1: ฉันกำลังมองหาตัวอย่างการค้นหาแบบไบนารีตัวเองถูกทุบตีมัน) ถ้า 20 บรรทัดที่มีการพูดคุยกันอย่างกว้างขวางและรหัสที่หมุนเวียนกันถือเป็นจุดบกพร่องเป็นเวลา 20 ปีคุณต้องใช้เวลานานแค่ไหนในการใช้ codebase 20 ล้านเส้น คนไม่กี่โหลที่ยุ่งมากที่สุดจะเคยดู?
scrwtp

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

1
@JoanVenge ฉันยกตัวอย่างที่แสดงให้เห็นว่าข้อบกพร่องที่ยุ่งยากสามารถที่จะหา ในกรณีนี้การคัดลอกการวางเป็นจริงสิ่งที่ถูกต้องเนื่องจากได้รับการพิสูจน์แล้วว่าถูกต้องและการนำไปใช้ตั้งแต่เริ่มต้นจะมีข้อบกพร่องมากขึ้น เครื่องมือและวิธีปฏิบัติที่เราใช้ในอุตสาหกรรมโดยทั่วไปนั้นไม่เหมาะสม แนวปฏิบัติที่ดีที่สุดนั้นง่ายต่อการเพิกเฉยและนิสัยที่ไม่ดีนั้นง่ายต่อการรักษา ในท้ายที่สุดข้อบกพร่องจะมีอยู่เสมอเพราะมนุษย์ไม่ได้สมบูรณ์แบบ แต่เราสามารถลดจำนวนข้อบกพร่องด้วยการพยายามอย่างดีที่สุดและยืนยันในการศึกษาที่มีคุณภาพสูง
luiscubal

7
ฉันคิดว่าข้อผิดพลาดในรหัสการค้นหาแบบไบนารีแสดงให้เห็นว่าคำถามนี้ซับซ้อนแค่ไหน ข้อผิดพลาดพื้นฐานในการค้นหาเป็นจำนวนเต็มเกินที่เป็นไปได้ในการเพิ่ม "ข้อผิดพลาด" นั้นเป็นที่แพร่หลายเพราะชาวบ้านส่วนใหญ่พึ่งพาข้อสันนิษฐาน (และบางครั้งไม่ถูกต้อง) โดยปริยายว่าอินพุตจะไม่ใหญ่พอที่จะทำให้เกิดการไหลล้น เป็นข้อผิดพลาดจริง ๆ หรือเป็นเพียงสัญญาส่วนต่อประสานที่มีการบันทึกไว้ไม่ดีหรือไม่? เมื่อใดที่ครั้งสุดท้ายที่คุณพิสัยการตรวจสอบการสรุปในการเพิ่มจำนวนเต็มหรือตรวจสอบการล้นหลังจากข้อเท็จจริง?
Charles E. Grant

4
เซิร์ฟเวอร์ตัวอย่างของคุณเพื่อเน้นการสังเกตอย่างชัดเจนเกี่ยวกับภาษาการเขียนโปรแกรมและคุณภาพของเครื่องมือ คอมไพเลอร์คุณภาพการผลิตสำหรับภาษาที่มีประสิทธิภาพควรปฏิเสธที่จะคอมไพล์ตัวอย่างแรกของคุณโดยส่งคืนข้อผิดพลาดการคอมไพล์ร้ายแรงแทน มันเป็นไปได้ที่จะรวบรวมสิ่งที่น่ารังเกียจดังกล่าวซึ่งจะบอกทุกสิ่งที่คุณจำเป็นต้องรู้เกี่ยวกับคุณภาพของเครื่องมือเหล่านั้นและความเป็นไปได้ในการใช้งานสำหรับการส่งมอบซอฟต์แวร์ที่ปราศจากข้อบกพร่อง
John R. Strohm

12

เหตุผลที่ไม่เขียนโปรแกรมที่ไม่มีบั๊กส่วนใหญ่จะประหยัด

มีเป็นวิธีการทางคณิตศาสตร์เพื่อพิสูจน์ความถูกต้องของโปรแกรม ในหลักสูตรวิทยาการคอมพิวเตอร์ที่มีคุณภาพสูงพวกเขาจะได้รับการกล่าวถึง มีภาษาโปรแกรมที่คิดค้นขึ้นโดยเฉพาะเพื่อจุดประสงค์นี้ ในทางทฤษฎีการเขียนโปรแกรมโดยไม่มีข้อบกพร่องเป็นไปได้

ใช่มีฮาร์ดแวร์ที่ไม่สมบูรณ์ซึ่งบางครั้งอาจเปลี่ยนค่าบิตเนื่องจากนิวตริโนยิงจากซูเปอร์โนวาที่ห่างไกลหลายล้านปีก่อนเพิ่งเกิดขึ้นเพื่อโจมตีโปรเซสเซอร์ของคุณในสถานที่ที่เหมาะสม เอาล่ะทุกทฤษฎีมีสมมติฐานและนามธรรม แต่สมมติว่าตัวประมวลผลทำงานตามที่โฆษณาไว้มีเครื่องมือทางคณิตศาสตร์เพื่อให้แน่ใจว่าโปรแกรมทำงานได้อย่างถูกต้องเช่นกัน

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

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

ปัญหาแทนคือ:

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

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

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

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

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

การให้เหตุผลทางเศรษฐกิจก็โอเค เราอาศัยอยู่ในโลกที่เงินและเวลามีความสำคัญ แต่เพียงเพราะเราไม่ได้ทำอะไรเพื่อเหตุผลทางเศรษฐกิจเราไม่ควรพูดไร้สาระเกี่ยวกับวิธีที่ไม่สามารถทำได้แม้ในทางทฤษฎี ใครจะรู้ ... บางทีในไม่กี่ปีเราจะมีบางภาษาโปรแกรมและเครื่องมือใหม่ ๆ ซึ่งจะทำให้ถูกต้องพิสูจน์ง่าย


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

1
"แพง" เป็นญาติ เปรียบเทียบค่าใช้จ่ายในการค้นหาและแก้ไขข้อบกพร่องด้วยค่าใช้จ่ายเช่นเครื่องรังสีรักษาซึ่งฆ่าคนไข้หลายราย (Google "Therac 25")
John R. Strohm

6

เลขที่

David Hilbertเสนอปัญหาที่สองของเขาคณิตศาสตร์ใน 1,900 ที่เป็นหลักขอให้โลกพิสูจน์ว่าเลขคณิตทำงานตามที่ตั้งใจ. หลังจากนั้นเขาได้ประกอบฉาก " Entscheidungsproblem " ซึ่งถามอะไรบางอย่างที่คล้ายกันในแง่ตรรกะ Kurt_Gödelของ " ทฤษฎีบทความไม่สมบูรณ์ครั้งแรก " พิสูจน์แล้วในปี 1931 ว่าไม่มีทฤษฎีคณิตศาสตร์ระดับประถมศึกษาที่สามารถเป็นได้ทั้งที่สอดคล้องและสมบูรณ์ การเป็นตัวแทนของอลันทัวริงของ Entscheidungsproblem ในขณะที่ " ปัญหาการหยุดชะงัก " ทำให้เกิดปัญหาตรงกับหัวใจของคำถามนี้ซึ่งเขาได้พิสูจน์ว่ามันเป็นไปไม่ได้ที่จะพิสูจน์ว่าโปรแกรมจะทำงานให้เสร็จหรือไม่ ระบุว่าไม่น่าเชื่อถือมันเป็นไปไม่ได้ที่จะพิสูจน์ว่าโปรแกรมนั้นมีข้อบกพร่องหรือไม่

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


9
ความสามารถในการ undecidability โดยทั่วไปนั้นมีโปรแกรมที่คุณสามารถพิสูจน์ได้ว่าไม่ถูกต้องหรือไม่ถูกต้อง แต่สำหรับโปรแกรมเฉพาะที่ระบุความถูกต้อง (หรือบ่อยกว่า: ความไม่ถูกต้อง) สามารถพิสูจน์ได้ นี่เป็นการสมมติว่าคุณมีข้อกำหนดภาษาอย่างเป็นทางการและคอมไพเลอร์ที่ถูกต้องที่พิสูจน์ได้ - ภาษาหลังไม่มีสำหรับภาษาการเขียนโปรแกรมระดับสูงใด ๆ แม้ว่า CompCert จะเข้ามาใกล้
Daniel

+1 สำหรับการอ้างอิงพื้นหลังทางทฤษฎีที่เกี่ยวข้อง ฉันยังไม่รู้ว่า "Entscheidungsproblem" เรียกว่าเป็นภาษาอังกฤษเหมือนกับในเยอรมัน!
Peopleware

5
เห็นด้วยกับแดเนียล ความท้าทายเกี่ยวกับอินสแตนซ์เดียว ปัญหาการหยุดทำงานเกี่ยวข้องกับอินสแตนซ์ที่เป็นไปได้ทั้งหมด int main() { return 0; } หยุดชะงักเล็กน้อยและไม่มีข้อบกพร่อง
MSalters

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

6

ความผิดพลาดของมนุษย์คือ

แม้ว่าคุณจะเขียนโค้ดด้วยภาษาทางการเช่นB-methodที่คุณสามารถใช้ในการพิสูจน์ทางคณิตศาสตร์ได้ว่าตรงตามข้อกำหนด

แม้ว่าคุณจะใช้ภาษาสเปคอย่างเป็นทางการ

มีขั้นตอนที่เป็นมนุษย์อยู่เสมอในการแยกความต้องการของผู้ใช้จากสมองหนึ่งหรือหลายตัวไปยังคอมพิวเตอร์

ขั้นตอนของมนุษย์นี้ผิดพลาดง่ายและหนอนอยู่ในแอปเปิ้ล


1
มันยังคงเป็นข้อผิดพลาดเมื่อโปรแกรมทำสิ่งที่ถูกถามแทนที่จะเป็นสิ่งที่ตั้งใจหรือไม่
MSalters

ฉันคิดว่ามัน ..
Joan Venge

4
@MSalters - แน่นอนมันเป็น ไม่ใช่จากมุมมองของสัญญา แต่ในที่สุดลูกค้าก็ไม่ได้แก้ปัญหาของเขา คุณจะบินบนเครื่องบินที่คอมพิวเตอร์ทำในสิ่งที่ถาม แต่ไม่ใช่สิ่งที่ตั้งใจหรือไม่
mouviciel

3

สัดส่วนที่เป็นธรรมของ "บั๊ก" ที่ฉันได้พบอาจอธิบายได้อย่างถูกต้องว่าเป็นข้อผิดพลาดระหว่างการออกแบบระบบและความคาดหวังของลูกค้า

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

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

ในระยะสั้น:

เลขที่


+1 นักพัฒนาและลูกค้าอาจมีมุมมองที่แตกต่างกันอย่างมากเกี่ยวกับสิ่งที่นิยาม 'ข้อบกพร่อง'
GrandmasterB

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

2

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


1

ฉันพบว่าส่วนของจิมชอร์ไม่มีข้อบกพร่องการอ่านที่มีประโยชน์มากในหัวข้อนี้ รูปแบบย่อ: เป็นไปไม่ได้ที่จะพัฒนาโดยไม่สร้างข้อบกพร่อง - แต่เราสามารถทำงานในลักษณะที่เราตรวจพบได้โดยเร็วที่สุด

ในระหว่างการผลิตรหัสนั้นเอง ตัวอย่างเช่นโดยการเขียนและเรียกใช้การทดสอบหน่วยบ่อยครั้งในระหว่างการพัฒนาเรามั่นใจอย่างต่อเนื่องว่ารหัสทำในสิ่งที่ควรทำ นอกจากนี้ยังมีประโยชน์ในการเขียนโค้ดที่มีอยู่ใหม่อย่างต่อเนื่องในลักษณะที่มันแสดงพฤติกรรมของระบบได้อย่างชัดเจนที่สุด

อย่างไรก็ตามในกรณีของคุณคุณกำลังพูดถึง codebase ที่มีอยู่แล้วกับโค้ดหลายล้านบรรทัด ถ้าคุณต้องการที่จะได้รับข้อผิดพลาดของระบบดังกล่าวคุณต้องรู้ก่อนว่า "ข้อผิดพลาด" คืออะไรสำหรับระบบนี้ คุณสามารถเขียนชุดทดสอบการโพสต์เฉพาะกิจเพื่อให้แน่ใจว่าการทำงานของระบบ (ถ้ายังไม่มี) เว็บของการทดสอบเหล่านั้นอาจใช้เป็นคำจำกัดความโดยประมาณสำหรับพฤติกรรมของระบบที่ถูกต้อง แต่ยิ่งคุณมีรหัสมากเท่าไหร่ก็ยิ่งมีความพยายามมากขึ้นในการฝึกหัดดังกล่าว ดังนั้น บริษัท ส่วนใหญ่มักจะประนีประนอม: พวกเขาอาศัยอยู่กับความไม่สมบูรณ์การทำงานกับรายการข้อผิดพลาดและการบำรุงรักษาเพื่อกำจัดข้อผิดพลาดที่น่ารำคาญที่สุดออกจากระบบ


1

เกี่ยวกับการตรวจสอบด้วยชิ้นส่วนคอมพิวเตอร์

มีสองวิธีในการตรวจสอบโปรแกรมโดยใช้คอมพิวเตอร์ หนึ่งคือการทดสอบอื่น ๆ ที่ใช้ระบบพิสูจน์

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

ในการใช้ระบบพิสูจน์คุณเริ่มต้นจากข้อกำหนดที่เป็นทางการ (และพวกเขาอาจมีข้อบกพร่องหวังว่าภาษาที่ใช้สำหรับข้อกำหนดจะเหมาะสมกว่าที่จะโน้มน้าวใจตัวเองว่าไม่มีข้อผิดพลาดมากกว่าภาษาโปรแกรม) และสร้าง / พิสูจน์ด้วย ความช่วยเหลือของระบบพิสูจน์ว่าโปรแกรมนั้นไม่มีข้อบกพร่อง (และมีคำถามเกี่ยวกับข้อบกพร่องในระบบพิสูจน์ แต่พวกเขาพิสูจน์ตัวเองถูกต้อง) สถานะปัจจุบันของศิลปะเป็นคอมไพเลอร์สำหรับเซตย่อย C (และเซตย่อยไม่ใช่เชิงวิชาการ "CompCert สนับสนุนชุดย่อยMISRA-C 2004 ทั้งหมดของ C รวมถึงคุณสมบัติมากมายที่แยกออกจาก MISRA")


โดนัลด์ที่จะพูดนู (จากหน่วยความจำ): คุณสามารถพิสูจน์ได้ว่าโปรแกรมที่เป็นข้อผิดพลาดฟรี แต่ไม่ได้หมายความว่ามันไม่มีข้อบกพร่อง :-)
gnasher729

1

ไม่เพราะคอมพิวเตอร์และสภาพแวดล้อมซอฟต์แวร์ที่แอปพลิเคชันทำงานนั้นจะยังคงมีการเปลี่ยนแปลงแม้ว่ารหัสจะถูกตรึง ระบบปฏิบัติการยังคงพัฒนาต่อไปด้วยแพทช์และแก้ไขรวมถึงอุปกรณ์และไดรเวอร์ เมื่อคุณคิดว่าคุณถึงจุดที่ไม่มีบั๊กแล้ว AMD หรือ nVidia จะปล่อยการอัปเดตไดรเวอร์วิดีโอที่ส่งผลกระทบต่อวิธีการที่คุณโต้ตอบกับระบบย่อยวิดีโอ ขณะนี้แอปพลิเคชันของคุณมีข้อบกพร่องทางสายตา (เช่นกระพริบกะพริบหรือลดอัตราเฟรม) สำหรับลูกค้าที่มีการ์ดแสดงผลหรือการกำหนดค่า (SLI? LOL)

นอกเหนือจากฮาร์ดแวร์และระบบปฏิบัติการแล้วยังมีผลิตภัณฑ์มิดเดิลแวร์จำนวนมากภายใต้แอพที่สำคัญที่สุดที่จะพัฒนานอกเหนือการควบคุมของคุณและเช่นเดียวกับที่คุณได้รับรหัสของคุณไปยังศูนย์ข้อบกพร่องชั้นที่อยู่ด้านล่างคุณได้รับ EOL'ed

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

ไม่ในบางจุดธุรกิจจะมองหาทีมพัฒนาที่ยืดหยุ่นมากขึ้นซึ่งรองรับความต้องการที่จะก้าวไปข้างหน้าด้วยความเร็วของเทคโนโลยี นี่เป็นปัญหาพื้นฐานที่ทีมพัฒนาที่ทันสมัยเผชิญอยู่


0

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

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


-2

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

แต่การทำเช่นนี้คุณไม่ได้ตั้งใจสร้างระบบ 20 MLOC หากการเขียนโค้ดที่ไม่มีข้อบกพร่องไม่ใช่เป้าหมายของคุณไม่ควรสร้างระบบ MLOC จำนวนมาก

เหตุผลของฉันมีดังนี้:

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

บุคคลที่มีงบประมาณจะจ่ายเงินให้บางคน (อาจเหมือนกันหรืออาจแตกต่างกัน) เรียกว่าโปรแกรมเมอร์ดังนั้นโปรแกรมเมอร์เหล่านี้จะเปลี่ยนบางส่วนตามระยะเวลาที่ตกลงกันไว้ในซอฟต์แวร์เพื่อตอบสนองความต้องการ

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

สิ่งนี้มีความเกี่ยวข้องกับคำถามของคุณดังต่อไปนี้:

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

มันคือทั้งหมดที่เกี่ยวกับเงินและถูกต้องดังนั้น


-2

ใช่.

แต่อย่างที่คุณรู้มันต้องใช้ความพยายามมากเกินไปที่จะคุ้มค่า

ก่อนที่ฉันจะสามารถปกป้องคำตอบของฉันได้เราต้องกำหนดว่าข้อบกพร่องคืออะไร:

  • ข้อผิดพลาดเป็นพฤติกรรมที่ขัดต่อข้อกำหนด
  • อย่างไรก็ตามข้อบกพร่องในข้อกำหนด (เช่นกฎข้อที่ 0 ของหุ่นยนต์) จะไม่นับรวมเป็นข้อบกพร่องของซอฟต์แวร์
  • คุณสมบัติพิเศษจะไม่นับรวมเป็นข้อผิดพลาด
  • เพื่อประโยชน์ในการโต้แย้งความขัดแย้งภายในข้อกำหนดไม่ถือเป็นข้อบกพร่องของซอฟต์แวร์เช่นกัน

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

"แต่เดี๋ยวก่อน!" ฉันได้ยินคุณประท้วง "เกิดอะไรขึ้นถ้าพฤติกรรมที่ไม่คาดคิด (แต่ถูกต้อง) ของโมดูลหนึ่งทำให้เกิดข้อผิดพลาดในอีกโมดูล" จากนั้นบั๊กจะอยู่ในโมดูลที่สอง โมดูลที่ไม่มีข้อบกพร่องนั้นสามารถใช้เป็น API และ API ดังที่คุณทราบต้องการการดูแลอย่างถูกต้อง

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

"แต่ให้สถานที่ตั้งแก่ฉันและฉันจะย้ายโลก" - อาร์คิมีดีส


มันต้องใช้ความพยายาม แต่สิ่งที่จ่ายคืน
Laurent LA RIZZA

1
หากคุณปล่อยข้อผิดพลาดสเปคออกจากสมการซอฟต์แวร์ทั้งหมดของคุณจะไร้ประโยชน์: ข้อมูลจำเพาะเป็นเพียงเครื่องมือในการจดบันทึกความต้องการของผู้ใช้ในแบบที่ค่อนข้างเป็นทางการ แต่ในที่สุดผู้ใช้จะต้องพึงพอใจ และการสร้างสเปคนั้นเป็นส่วนหนึ่งของการพัฒนาซอฟต์แวร์เช่นเดียวกับการเขียนโค้ด ท้ายที่สุดสเป็คอย่างเป็นทางการที่สมบูรณ์จะอธิบายพฤติกรรมของระบบเช่นเดียวกับรหัสสุดท้ายไม่สเป็คนั้นไม่สามารถดำเนินการได้อย่างมีประสิทธิภาพ
cmaster
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.