คุณคิดว่าอะไรคือสาเหตุสำคัญของข้อบกพร่องของซอฟต์แวร์ (และวิธีการย่อให้เล็กสุด) [ปิด]

ฉันกำหนดข้อบกพร่องเป็น:

"สิ่งที่อยู่ในการออกแบบแอปพลิเคชันหรือรหัสที่ป้องกันไม่ให้ทำงานตามข้อกำหนด"

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

สาเหตุสำคัญของความบกพร่องของซอฟต์แวร์คือการตีความ

การตีความคุณสมบัติของลูกค้าแตกต่างจากการตีความของนักออกแบบ

การตีความการออกแบบแตกต่างจากการตีความของโปรแกรมเมอร์

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

การทดสอบสามารถตรวจพบปัญหาได้ แต่เนิ่นๆ แต่ผู้ทดสอบยังเป็นมนุษย์และไม่สามารถทดสอบได้ 100% หากคุณต้องการที่จะปล่อยก่อนที่จักรวาลจะจบลง

ฉันพิจารณาสาเหตุสำคัญของข้อบกพร่องของซอฟต์แวร์ในการเป็นโปรแกรมเมอร์

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

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

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

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

สาเหตุหลักของข้อบกพร่องคือการจัดการที่ไม่ดี ;)

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

นอกจากนี้การจัดการจ้างนักพัฒนาที่ไม่ดียังช่วยเพิ่มจำนวนข้อบกพร่อง

การจัดการที่ไม่ดี

(ข้อจำกัดความรับผิดชอบ: ฉันควรจะจ้างและจัดการผู้พัฒนา)

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

ที่สุดของการพัฒนาที่ผมศึกษาต้มลงไปลดNเพราะความซับซ้อนของโปรแกรมเป็นอย่างน้อยและอาจO(N^2) O(k^N)การกำหนดให้Nถูกทิ้งไว้เป็นแบบฝึกหัดสำหรับผู้อ่าน แต่ฉันคิดถึงสิ่งต่าง ๆ เช่นความซับซ้อนของวัฏจักรที่นี่ ตรรกะการห่อหุ้มและข้อมูลมีผลในการลด N โดยแบ่งปัญหาออกเป็นส่วน ๆ

ความไม่สมบูรณ์ที่จะคิดทุกอย่าง

ไม่สมบูรณ์

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

มารยาททางสังคม สังคมยอมรับไม่ได้ที่จะโทรหาใครบางคนที่ไม่สามารถทำได้

วิ่งเข้าไปในสิ่งต่าง ๆ โดยไม่เข้าใจ การเริ่มต้นเขียนโค้ดโดยไม่เข้าใจข้อกำหนดการใช้งานหรือสถาปัตยกรรมด้านเทคนิคอย่างสมบูรณ์

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

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

กำหนดการกดดันเป็นแหล่งที่แข็งแกร่งอย่างแน่นอน

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

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

เป็นเพราะวิศวกรรมซอฟต์แวร์มีความซับซ้อนโดยเนื้อแท้ เรียงความ "ไม่มีกระสุนเงิน" กล่าวถึงเรื่องนี้

น่าแปลกที่คำตอบอื่น ๆ มากมายที่นี่สัมผัสกับหัวข้อที่ "บังเอิญซับซ้อน" ในภาษาของบทความนั้นในขณะที่ในความเป็นจริงสิ่งที่นักพัฒนาซอฟต์แวร์ส่วนใหญ่ทำคือ "ซับซ้อนเป็นหลัก" ดังนั้นในลักษณะของการสร้าง ซอฟต์แวร์เป็นเรื่องยากซอฟต์แวร์จะมีข้อบกพร่องและงานของเราคือจัดการกับมัน

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

การเขียนโค้ดที่ล้มเหลวแบบเงียบ ๆ กับโค้ดที่รายงานข้อผิดพลาดทั้งหมด

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

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

สาเหตุสำคัญของข้อบกพร่องของซอฟต์แวร์คือการเขียนรหัส

เขียนโค้ดน้อยลงและคุณจะมีข้อบกพร่องน้อยลง ;-)

ในระดับหนึ่งการจัดการ แต่มันไม่ใช่แค่ PHB มันคือการจัดการโค้ดเองซึ่งอาจจะใช่หรือไม่ใช่ภาพสะท้อนของการจัดการองค์กร

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