ซอฟต์แวร์ที่ซับซ้อนควรใช้ความซ้ำซ้อน / ความทนทานมากเพียงใด

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

คำจำกัดความของซอฟต์แวร์ที่ซับซ้อน:

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

แก้ไข:อะไรซับซ้อน โปรดดูมีความแตกต่างใหญ่ระหว่างที่ซับซ้อนและมีความซับซ้อนเป็น (ลิงก์โดยตรง)

คำจำกัดความของความซ้ำซ้อน / ความทนทาน ภายในคำถามนี้ :
(เพิ่มความทนทานตามความคิดเห็น)

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

ตัวอย่างของซอฟต์แวร์ดังกล่าว:

• การย้ายฐานข้อมูล
  • ฐานข้อมูลธุรกิจ
  • ฐานข้อมูลการควบคุมแหล่งที่มา ฯลฯ
• รุ่นที่แปลงระหว่างเอกสาร Word และเอกสาร OpenOffice, PowerPoint และ OpenOffice Draw เป็นต้น
• แปลอัตโนมัติทั้งเว็บไซต์
• การวิเคราะห์อัตโนมัติของซอฟต์แวร์สำเร็จรูปเช่น Doxygen แต่การวิเคราะห์นั้นจะต้องเชื่อถือได้มากกว่า (เช่นไม่ใช่เครื่องมือเอกสาร)
• การสื่อสารผ่านเครือข่ายซึ่งอาจทำให้แพ็กเก็ตสูญหายและคาดว่าจะมีการลองซ้ำหลายครั้ง

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

อาจเกี่ยวข้อง:

• วิธีจัดการกับรหัสที่ซับซ้อนในโครงการขนาดใหญ่
• ผู้คนสามารถเขียนและบำรุงรักษาโค้ดที่ซับซ้อนและอ่านยากได้อย่างไร

นี่เป็นคำถามทางธุรกิจไม่ใช่คำถามทางเทคนิค

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

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

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

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

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

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

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

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

สำหรับ B) พารามิเตอร์พิเศษที่ไม่เกิดร่วมกันแสดงถึงโครงสร้างที่ไม่ดี ควรจะมีสองคลาสหนึ่งซึ่งจัดการหนึ่งกรณีและอื่นที่จัดการในอีกทางหนึ่ง การดำเนินการทั่วไปทั้งหมดสามารถทำได้ในคลาสฐานเดียวเพื่อหลีกเลี่ยงความซ้ำซ้อน

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

ซอฟต์แวร์ควรให้อภัยความผิดพลาดของผู้ใช้และความผิดพลาดอย่างสมบูรณ์ของโปรแกรมเมอร์

ความหมายซอฟต์แวร์ควรมีความแข็งแกร่งและอนุญาตการกู้คืนที่ราบรื่นสำหรับสิ่งต่าง ๆ เช่นข้อผิดพลาดของผู้ใช้และข้อผิดพลาดในการกำหนดค่าระบบ อย่างน้อยที่สุดข้อความแสดงข้อผิดพลาดที่เป็นมิตรระบุว่าเกิดข้อผิดพลาดขึ้นที่ใด (กล่องอินพุตไฟล์ config อาร์กิวเมนต์บรรทัดคำสั่ง ฯลฯ ... ) และข้อ จำกัด ใดที่ถูกละเมิด ("ต้องน้อยกว่าอักขระ X" "ตัวเลือกที่ถูกต้องคือ [X , Y, Z] ", ฯลฯ ... ) เพื่อความทนทานเพิ่มเติมซอฟต์แวร์สามารถแนะนำทางเลือกอื่นหรือใช้ค่าเริ่มต้นที่สมเหตุสมผล (แต่ควรระบุเสมอว่าไม่ได้ใช้ตามที่ผู้ใช้ระบุ)

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

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

 int A(int x)
 {
   if (x==0) return -1
   ...
 }
 int B(int x)
 {
   if (x==0) return -1
   err = A(x)
   if (err) return err;
   ...
 }
 // and so on and so on....

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

มันเป็นสิ่งที่ต้องการ

มีข้อกำหนดสำหรับความแข็งแกร่งหรือไม่?

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

ควรมีกรณีการใช้งานสำหรับการกู้คืนข้อผิดพลาด (มิฉะนั้นคุณจะรู้ได้อย่างไรว่ามันจะเกิดขึ้นได้อย่างไร)

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

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

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