การแยกแอพพลิเคชั่นแบบเสาหินออกเป็นส่วนเล็ก ๆ หลาย ๆ อันช่วยป้องกันข้อผิดพลาดหรือไม่? [ปิด]

วิธีการถามนี้ก็คือ; ทำไมโปรแกรมมีแนวโน้มที่จะเป็นเสาหิน?

ฉันกำลังคิดถึงบางสิ่งเช่นแพ็คเกจอนิเมชั่นเช่น Maya ซึ่งผู้คนใช้สำหรับเวิร์กโฟลว์ต่างๆ

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

ใช่. โดยทั่วไปแล้วแอปพลิเคชั่นที่มีความซับซ้อนน้อยสองตัวที่เล็กลงนั้นง่ายต่อการดูแลรักษามากกว่าแอพพลิเคชั่นขนาดใหญ่

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

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

การแยกแอพพลิเคชั่นที่เป็นหินใหญ่ออกเป็นสองส่วนเล็ก ๆ ช่วยป้องกันข้อบกพร่อง

สิ่งต่าง ๆ ที่ไม่ค่อยเรียบง่ายในความเป็นจริง

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

อย่างไรก็ตาม

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

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

สิ่งนี้ขึ้นอยู่กับว่าแอพขนาดใหญ่สามารถแยกส่วนประกอบเป็นอย่างไรและอินเทอร์เฟซแบบกว้างระหว่างส่วนประกอบนั้นเป็นอย่างไรและวิธีการใช้อินเตอร์เฟสเหล่านั้น

กล่าวโดยย่อนี่มักเป็นการแลกเปลี่ยนและไม่มีคำตอบที่ "ใช่" หรือ "ไม่" ถูกต้องโดยทั่วไป

เหตุใดโปรแกรมจึงมีแนวโน้มเป็นแบบเสาหิน

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

พวกเขาจะไม่ง่ายกว่าที่จะรักษา

"การบำรุงรักษาที่ง่ายขึ้น" ที่นี่มักมาจากความจริงที่ว่าส่วนต่าง ๆ ของแอปพลิเคชันสามารถพัฒนาได้ง่ายขึ้นโดยทีมที่แตกต่างกันดังนั้นการกระจายภาระงานที่ดีขึ้นทีมงานเฉพาะทางที่มีจุดเน้นที่ชัดเจน

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

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

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

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

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

สิ่งสำคัญคือต้องจำไว้ว่าความสัมพันธ์ไม่ได้เป็นสาเหตุ

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

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

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

ในการอ้างอิง CAR Hoare:

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

ถ้าเป็นเช่นนั้นทำไมทุกคนจะสร้างวิธีแก้ปัญหาที่ซับซ้อนหรือเสาหินโดยไม่จำเป็น? Hoare ให้คำตอบในประโยคถัดไป:

วิธีแรกยากกว่ามาก

และต่อมาในแหล่งเดียวกัน (การบรรยายรางวัลทัวริง 1980):

ราคาของความน่าเชื่อถือคือการแสวงหาความเรียบง่ายสูงสุด มันเป็นราคาที่คนรวยหายากที่สุดที่จะจ่าย

นี่ไม่ใช่คำถามที่มีคำตอบใช่หรือไม่ใช่ คำถามไม่ได้เป็นเพียงการบำรุงรักษาง่าย แต่ยังเป็นคำถามที่ใช้ทักษะอย่างมีประสิทธิภาพ

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

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

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

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

ไม่ มันไม่ได้ทำให้ง่ายต่อการบำรุงรักษา หากสิ่งใดยินดีต้อนรับสู่ปัญหามากขึ้น

ทำไม?

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

• ตอนนี้คุณมีสองผลิตภัณฑ์ที่ต้องการ:

  • รูปแบบ UI ทั่วไปกลไกการโต้ตอบ ฯลฯ ... ดังนั้นตอนนี้คุณมีปัญหาการออกแบบ (ทีมพัฒนากำลังสื่อสารกันอีกครั้งอย่างไร)
  • ความเข้ากันได้ย้อนหลัง (modeller v1 สามารถนำเข้าสู่ Animator v3 ได้หรือไม่)
  • การรวมระบบคลาวด์ / เครือข่าย (หากมีคุณสมบัติ) จะต้องได้รับการอัปเดตเป็นสองเท่าของผลิตภัณฑ์จำนวนมาก

• ตอนนี้คุณมีตลาดผู้บริโภคสามแห่ง: Modellers, Animators และ Modeller Animators

  • พวกเขาจะมีลำดับความสำคัญที่ขัดแย้งกัน
  • พวกเขาจะมีความต้องการการสนับสนุนที่ขัดแย้งกัน
  • พวกเขาจะมีรูปแบบการใช้งานที่ขัดแย้งกัน
• Modeller Animators ต้องเปิดแอพพลิเคชั่นสองตัวแยกกันเพื่อทำงานกับไฟล์เดียวกันหรือไม่? มีแอปพลิเคชั่นที่สามที่มีทั้งฟังก์ชั่นหรือไม่แอปพลิเคชั่นหนึ่งโหลดฟังก์ชั่นของอีกอันหรือไม่?
• ฯลฯ ...

การที่รหัสฐานขนาดเล็กนั้นง่ายกว่าที่จะรักษาระดับแอปพลิเคชั่นคุณจะไม่ได้รับอาหารกลางวันฟรี นี่เป็นปัญหาเดียวกันที่เป็นหัวใจของ Micro-Service / Any-Modular-Architecture มันไม่ใช่ยาครอบจักรวาล, ความยากลำบากในการบำรุงรักษาในระดับแอปพลิเคชันมีการแลกเปลี่ยนสำหรับความยากลำบากในการบำรุงรักษาในระดับ orchestration ปัญหาเหล่านั้นยังคงเป็นปัญหาอยู่พวกเขาไม่ได้อยู่ในฐานรหัสอีกต่อไปพวกเขาจะต้องหลีกเลี่ยงหรือแก้ไข

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

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

มีคำตอบที่ดีมากมาย แต่เนื่องจากมีรอยแตกเกือบตายฉันจะโยนหมวกของฉันใส่ห่วง

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

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

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

สำหรับแอป UI นั้นไม่น่าจะลดจำนวนบั๊กโดยรวมได้ แต่จะเปลี่ยนความสมดุลของบั๊กผสมไปสู่ปัญหาที่เกิดจากการสื่อสาร

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

หากหน่วยของข้อมูลที่โปรแกรมเกี่ยวข้องนั้นมีขนาดใหญ่ (เช่นรูปภาพ) ความล่าช้าข้ามกระบวนการใด ๆ จะนานและยากที่จะกำจัด - บางอย่างเช่น "ใช้การแปลงเป็นภาพ 10mb" จะได้รับ + ​​20mb จากดิสก์ / เครือข่าย IO ทันที เป็น 2 การแปลงจากรูปแบบในหน่วยความจำไปเป็นรูปแบบ serializabe และย้อนกลับ มีไม่มากที่คุณสามารถทำได้เพื่อซ่อนเวลาที่ต้องทำจากผู้ใช้

นอกจากนี้การสื่อสารใด ๆ และโดยเฉพาะอย่างยิ่งดิสก์ IO จะต้องผ่านการตรวจสอบ AntiVirus / Firewall - สิ่งนี้จะเพิ่มเลเยอร์ยากอีกขั้นในการสร้างข้อบกพร่องและความล่าช้ามากยิ่งขึ้น

การแยก "โปรแกรม" แบบเสาหินส่องสว่างในกรณีที่การสื่อสารล่าช้าไม่สำคัญหรือหลีกเลี่ยงไม่ได้

• การประมวลผลข้อมูลจำนวนมากแบบขนานซึ่งคุณสามารถแลกเปลี่ยนความล่าช้าพิเศษขนาดเล็กเพื่อการปรับปรุงที่สำคัญของแต่ละขั้นตอน (บางครั้งไม่จำเป็นต้องใช้ส่วนประกอบที่กำหนดเองโดยใช้ off-the-shelf หนึ่งครั้ง) ตัวอย่างขั้นตอนขนาดเล็กสำหรับแต่ละบุคคลอาจช่วยให้คุณใช้เครื่องจักรที่ราคาถูกกว่าแทนการใช้เครื่องเดียวที่มีราคาแพง
• แยกการบริการแบบ monolithic เข้ากับบริการไมโครคู่ที่น้อยกว่า - การเรียกบริการหลาย ๆ ตัวในแบบคู่ขนานแทนที่จะเป็นบริการที่มีแนวโน้มมากที่สุดจะไม่เพิ่มความล่าช้าพิเศษ (อาจลดเวลาโดยรวมหากแต่ละคนเร็วกว่าและไม่มีการพึ่งพา)
• กำลังย้ายการดำเนินการที่ผู้ใช้คาดหวังว่าจะใช้เวลานาน - แสดงฉาก / ภาพยนตร์ 3 มิติที่ซับซ้อนคำนวณคอมพิวเตอร์ที่ซับซ้อนเกี่ยวกับข้อมูล ...
• "auto-complete", "spell-check" และอุปกรณ์เสริมอื่น ๆ สามารถทำภายนอกได้บ่อยครั้งตัวอย่างที่เห็นได้ชัดที่สุดคือ url ของเบราว์เซอร์ที่แนะนำอัตโนมัติที่อินพุตของคุณส่งไปยังบริการภายนอก (เครื่องมือค้นหา) ตลอดเวลา .

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

[มัน] ช่วยป้องกันข้อผิดพลาดหรือไม่?

ป้องกันไม่ให้? อืมไม่ไม่จริง

• มันจะช่วยให้ตรวจสอบข้อบกพร่อง
  คือข้อบกพร่องทั้งหมดที่คุณไม่เคยรู้มาก่อนว่าคุณจะค้นพบเมื่อคุณพยายามแยกความยุ่งเหยิงนั้นออกเป็นส่วนเล็ก ๆ ดังนั้นวิธีหนึ่งก็ป้องกันไม่ให้ข้อบกพร่องเหล่านั้นปรากฏในการผลิต - แต่ข้อบกพร่องมีอยู่แล้ว
• มันจะช่วยลดผลกระทบจากข้อบกพร่อง
  บั๊กในแอพพลิเคชั่นแบบเสาหินมีศักยภาพที่จะทำให้ระบบทั้งหมดแย่ลงและป้องกันไม่ให้ผู้ใช้โต้ตอบกับแอพพลิเคชั่นของคุณเลย หากคุณแยกแอปพลิเคชันนั้นออกเป็นส่วนประกอบข้อบกพร่องส่วนใหญ่จะ - โดยการออกแบบ - มีผลกับหนึ่งในองค์ประกอบเท่านั้น
• มันจะสร้างสถานการณ์หาใหม่ข้อบกพร่อง
  หากคุณต้องการให้ประสบการณ์ของผู้ใช้คงเดิมคุณจะต้องรวมตรรกะใหม่สำหรับส่วนประกอบเหล่านั้นทั้งหมดเพื่อสื่อสาร (ผ่านบริการ REST ผ่านการเรียกใช้ระบบปฏิบัติการสิ่งที่คุณมี) เพื่อให้พวกเขาสามารถโต้ตอบได้อย่างราบรื่นจาก POV ของผู้ใช้
  ตัวอย่างง่ายๆ: แอพพลิเคชั่นเสาหินของคุณช่วยให้ผู้ใช้สร้างแบบจำลองและสร้างภาพเคลื่อนไหวโดยไม่ต้องออกจากแอพ คุณแบ่งแอปออกเป็นสององค์ประกอบ: การสร้างแบบจำลองและแอนิเมชั่น ตอนนี้ผู้ใช้ของคุณต้องส่งออกโมเดลของแอพจำลองไปยังไฟล์แล้วค้นหาไฟล์แล้วเปิดด้วยแอนิเมชั่นแอนิเมชั่น ... มาเจอกันผู้ใช้บางคนจะไม่ชอบแบบนั้นดังนั้นคุณต้องรวมตรรกะใหม่สำหรับ แอพพลิเคชั่นสร้างโมเดลเพื่อส่งออกไฟล์และเปิดแอปแอนิเมชั่นโดยอัตโนมัติและทำให้เปิดไฟล์ และตรรกะใหม่นี้ง่ายอย่างที่มันอาจเป็นไปได้มีข้อบกพร่องหลายประการเกี่ยวกับการจัดลำดับข้อมูลการเข้าถึงไฟล์และการอนุญาตผู้ใช้เปลี่ยนเส้นทางการติดตั้งของแอพ ฯลฯ
• มันเป็นข้อแก้ตัวที่สมบูรณ์แบบที่จะใช้การปรับโครงสร้างซ้ำที่จำเป็นมาก
  เมื่อคุณตัดสินใจที่จะแยกแอพแบบเสาหินออกเป็นส่วนย่อย ๆ คุณหวังว่าจะทำเช่นนั้นด้วยความรู้และประสบการณ์เกี่ยวกับระบบมากกว่าตอนที่มันถูกออกแบบมาครั้งแรกและขอบคุณที่คุณสามารถใช้จำนวน refactors เพื่อสร้างรหัส สะอาด, เรียบง่าย, มีประสิทธิภาพมากขึ้น, ยืดหยุ่นมากขึ้น, ปลอดภัยยิ่งขึ้น และการปรับโครงสร้างนี้สามารถช่วยป้องกันข้อบกพร่องได้ แน่นอนว่าคุณสามารถใช้ refactoring เดียวกันกับแอพเสาหินเพื่อป้องกันข้อผิดพลาดเหมือนกัน แต่คุณทำไม่ได้เพราะมันเป็นเสาหินที่คุณกลัวที่จะสัมผัสอะไรบางอย่างใน UI และทำลายตรรกะทางธุรกิจ¯ \ _ (ツ) _ / ¯

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