โปรแกรมที่ไม่มีข้อผิดพลาดตามหลักวิชา

ฉันได้อ่านบทความมากมายที่ระบุว่ารหัสไม่สามารถปราศจากข้อบกพร่องและพวกเขากำลังพูดถึงทฤษฎีบทเหล่านี้:

• ปัญหาการหยุดชะงัก
• ทฤษฎีความไม่สมบูรณ์ของGödel
• ทฤษฎีบทของข้าว

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

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

และแน่นอนว่าการพูดคุยส่วนใหญ่พูดถึงเครื่องทัวริง สิ่งที่เกี่ยวกับระบบอัตโนมัติเชิงเส้นตรง (คอมพิวเตอร์จริง)?

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

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

พิจารณาฟังก์ชั่นต่อไปนี้:

int add(int a, int b) { return a + b; }

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

LaunchMissiles();

แทน?

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

ฉันรู้ว่าคุณกำลังคิดอะไรอยู่ "แต่ฉันกำลังพูดถึงซอฟต์แวร์ไม่ใช่ฮาร์ดแวร์"

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

ทำไม? เพราะคุณมีสิ่งเหล่านี้เรียกว่าเคสขอบ

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

อ่านเพิ่มเติม
พวกเขาเขียนสิ่งที่ถูกต้อง
The Ariane 5 Explosion

อันดับแรกให้สร้างสิ่งที่บริบทที่คุณต้องการเพื่อหารือเกี่ยวกับเรื่องนี้ใน. โปรแกรมเมอร์ Q & A ที่กองแลกเปลี่ยนแสดงให้เห็นว่าคุณมีความสนใจส่วนใหญ่มีแนวโน้มในโลกแห่งความจริงการดำรงอยู่ของ / เครื่องมือภาษามากกว่าทฤษฎีผลและวิทยาการคอมพิวเตอร์ทฤษฎีบท

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

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

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

การไม่พิสูจน์เป็นส่วนขยายของ Halting Problem ที่ใช้งานง่ายรวมกับข้อมูลการสังเกตของประสบการณ์ในชีวิตประจำวัน

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

สิ่งนี้หมายความว่าทุกโปรแกรมจะมีพฤติกรรมที่ไม่ตั้งใจอย่างน้อยหนึ่งรายการหรือไม่

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

หรือหมายความว่าไม่สามารถเขียนรหัสเพื่อยืนยันได้

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

สำหรับรายละเอียดเต็มไปด้วยเลือดดูCoqเป็นเครื่องมือ / ภาษา / ระบบ

สิ่งที่เกี่ยวกับการตรวจสอบแบบเรียกซ้ำ?

ฉันไม่รู้ ฉันไม่คุ้นเคยกับมันและฉันไม่แน่ใจว่าเป็นปัญหาการคำนวณหรือปัญหาการเพิ่มประสิทธิภาพคอมไพเลอร์

ฉันต้องการถามหมายความว่าทุกรหัสจะมีพฤติกรรมที่ไม่ได้ตั้งใจอย่างน้อยหนึ่งรายการหรือไม่

ไม่โปรแกรมที่ถูกต้องสามารถเป็นและเขียนได้ โปรดทราบว่าโปรแกรมสามารถแก้ไขได้ แต่การดำเนินการอาจล้มเหลวเนื่องจากสภาพแวดล้อมทางกายภาพ (ตามที่ผู้ใช้ Robert Harvey เขียนไว้ในคำตอบของเขาที่นี่ ) แต่นี่เป็นเรื่องที่ชัดเจน: รหัสของโปรแกรมนั้นยังคงถูกต้อง เพื่อให้แม่นยำยิ่งขึ้นความล้มเหลวไม่ได้เกิดจากความผิดพลาดหรือข้อผิดพลาดในตัวโปรแกรมเอง แต่ในเครื่องพื้นฐานที่เรียกใช้งาน (*)

(*) ฉันกำลังยืมคำจำกัดความของความผิดพลาด , ข้อผิดพลาดและความล้มเหลวจากสนามเชื่อถือเป็นตามลำดับข้อบกพร่องคงเป็นรัฐภายในไม่ถูกต้องและไม่ถูกต้องสังเกตพฤติกรรมภายนอกตามข้อกำหนด (ดู <กระดาษจากสนามที่>) .

หรือหมายความว่าฉันไม่สามารถเขียนรหัสได้ซึ่งจะตรวจสอบหรือไม่

อ้างถึงกรณีทั่วไปในคำสั่งด้านบนและคุณถูกต้อง

คุณอาจจะสามารถเขียนโปรแกรมที่ตรวจสอบว่าโปรแกรม X เฉพาะนั้นถูกต้อง ตัวอย่างเช่นหากคุณกำหนดโปรแกรม "hello world" เป็นคำสั่งที่มีสองคำสั่งตามลำดับคือprint("hello world")และexitคุณสามารถเขียนโปรแกรมที่ตรวจสอบว่าอินพุตเป็นโปรแกรมที่ประกอบด้วยคำสั่งสองคำนี้เรียงลำดับหรือไม่ดังนั้นจึงเป็นการรายงานว่าเป็น แก้ไขโปรแกรม "hello world" หรือไม่

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

การรันโปรแกรมสองโปรแกรมขึ้นไปของโปรแกรมเดียวกันเป็นเทคนิคการยอมรับข้อบกพร่องที่รู้จักกันดีเรียกว่าการเขียนโปรแกรม N-variant (หรือ N-version) เป็นการรับรู้ถึงสถานะของบั๊กในซอฟต์แวร์

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

ลิงก์อ่อนสองลิงก์ยังคงอยู่ซึ่งนำไปสู่ข้อบกพร่องโหมดทั่วไป:

• มีสเปคเดียวเท่านั้น
• ระบบการลงคะแนนไม่ซ้ำกันหรือซับซ้อน

โปรแกรมมีข้อมูลจำเพาะและทำงานในบางสภาพแวดล้อม

^{(ตัวอย่างของรังสีคอสมิกในคำตอบอื่น ๆ อาจเปลี่ยนaddไปFireMissilesเป็นส่วนหนึ่งของ "สภาพแวดล้อม")}

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

โดยเฉพาะอย่างยิ่งที่คุณอาจใช้เสียงวิเคราะห์แหล่งคงเหมือนเช่นม่า-C

^{(แต่สถานะปัจจุบันของนักวิเคราะห์ดังกล่าวไม่อนุญาตให้ทำการวิเคราะห์โปรแกรมทั้งหมดและพิสูจน์โปรแกรมขนาดใหญ่เช่นคอมไพเลอร์ GCC หรือเบราว์เซอร์ Firefox หรือเคอร์เนล Linux และความเชื่อของฉันคือการพิสูจน์ดังกล่าวจะไม่เกิดขึ้นในชีวิตของฉัน ฉันเกิดในปี 1959)}

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

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

พูดง่ายๆว่าถ้าหุ่นยนต์ยานอวกาศของคุณพบกับ ET และคุณไม่ได้ระบุว่าจะไม่มีวิธีที่หุ่นยนต์ของคุณจะทำงานเหมือนที่คุณต้องการจริงๆ ....

อ่านยังJ.Pitrat บล็อกรายการ

BTW, ปัญหาการหยุดชะงักหรือทฤษฎีบทของGödelอาจใช้กับสมองมนุษย์หรือแม้แต่เผ่าพันธุ์มนุษย์

สิ่งนี้หมายความว่าทุกโปรแกรมจะมีพฤติกรรมที่ไม่ตั้งใจอย่างน้อยหนึ่งรายการหรือไม่

เลขที่

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

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

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

หมายเหตุ: วิธีการทางการดักคอเป็นไปได้ของรังสีคอสมิกโดดเด่นของตัวประมวลผลและดำเนินการแทนlaunch_missiles() a+bพวกเขาวิเคราะห์โปรแกรมในบริบทของเครื่องนามธรรมแทนที่จะเป็นเครื่องจักรจริงที่ต้องเผชิญกับเหตุการณ์เดียวเช่นรังสีคอสมิกของ Robert Harvey

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

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

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

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

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

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

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

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

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

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

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

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

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

ฉันไม่เชื่อว่าโค้ดนั้นปราศจากข้อผิดพลาด 100% เลยทีเดียวเพราะโค้ดนั้นยังไม่เสร็จสมบูรณ์ คุณสามารถปรับปรุงสิ่งที่คุณเขียนได้ตลอดเวลา

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

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

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