อันตรายจากการใช้เสาหินขนาดใหญ่


20

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

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

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

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

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

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

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


7
หากดวงอาทิตย์ขึ้นเร็วเกินไปอังกฤษจะลอยออกสู่ทะเล
Maxpm

1
หรือความดันในแกนกลางของโลกเพิ่มขึ้นเล็กน้อย
StuperUser

1
@Maxpm ฉันเห็นสิ่งที่คุณทำที่นั่น ... xkcd.com/687
teto

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

1
@rwong: 1. อุปกรณ์หยุดการอัพเกรด แม้ว่าจะมีการอัปเดตทันที แต่เราไม่ต้องการผลลัพธ์ที่ไม่คาดคิดในกรณีที่การอัปเดตผิดพลาดไม่ว่าด้วยเหตุผลใด 2. Single-core ARM9 พร้อมลินุกซ์ในตัว มีอีกหนึ่งวินาทีที่ดูแลการทำงานของ CPU โดยไม่ใช้ระบบปฏิบัติการตรวจสอบ CPU หลักที่สร้างเอาต์พุตอย่างมีสติ
เอสเอฟ

คำตอบ:


5

ยกเว้นความคิดเห็นเล็ก ๆ ในตอนท้าย (ที่สองการดูแล CPU) คุณสามารถอธิบาย บริษัท ของฉันได้ ใช่เราต้องการอีสเตอร์ด้วย

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

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


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

23

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

คุณบอกว่าตัวเอง - มันค่อนข้างบำรุงรักษาได้ดีแบบแยกส่วน ...

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

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

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

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

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


16

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

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


2
แต่นั่นใช้ได้กับทั้งสถาปัตยกรรมที่เป็นไปได้ ...
SF

3
ใช่มันเป็น ...
Robert Harvey

10
... และดังนั้นคำตอบนี้ไม่ได้เพิ่มอะไรเลยในการสนทนายกเว้นเพื่อส่งเสริมการทดสอบหน่วย
benzado

2
@benzado: ซึ่งในสถานการณ์ของ OP นั้นมีความสำคัญอย่างยิ่ง
Robert Harvey

2
@ironcode: ดูหนังสือเช่น "การทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดก" สิ่งแรกที่เขาพูดในหนังสือเล่มนี้คือ "ถ้าคุณไม่มีชุดทดสอบหน่วยที่มีรหัสครอบคลุมสูงอยู่แล้วให้เขียนก่อนก่อนที่คุณจะทำอะไรอย่างอื่น " ฉันจะบอกว่าคำแนะนำนั้นมีความเกี่ยวข้องมากกว่าที่นี่ เนื่องจาก OP ได้ถามเป็นพิเศษว่า"ฉันมองข้ามอันตรายอื่น ๆ แล้ว"
Robert Harvey

8

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

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

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

การทดสอบเป็นปลาเฮอริ่งแดงที่นี่เนื่องจากปัญหาจะยังคงมีอยู่โดยมีหรือไม่มีการทดสอบ การทดสอบที่ดีกับทางเลือกการออกแบบควรจะสนับสนุนอย่างแน่นอน ฉันคาดหวังว่าการทดสอบนั้นง่ายกว่าด้วยรหัสเสาหิน

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


1
+1, วิศวกรรมเป็นเรื่องเกี่ยวกับการแลกเปลี่ยนไบนารีที่เล็กลงมีค่าใช้จ่ายเช่นกัน
benzado

+1 ฉันเห็นด้วยอย่างสุดใจ ไม่มีเหตุผลเฉพาะที่กำหนดให้รับประกันหลายรายการ การสื่อสารและการประสานงานระหว่างผู้บริหารมีราคา
Erick Robertson

+1: หากยังไม่พังอย่าแก้ไข
Bob Murphy

1

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

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

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

คุณต้องการมีการทดสอบที่ดีในสถานที่แม้ว่า


1

เป็นการดีที่คำตอบคือใช่ การมีหลายไบนารีมีศักยภาพที่จะทำให้มันมีเสถียรภาพมากขึ้น ....

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

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

มันจะสมเหตุสมผลในการก้าวไปข้างหน้าโดยการใส่รหัสใหม่ลงในไบนารีของตนเอง


1

หากคุณใช้กระบวนการเดียวมีโอกาสกว่าตัวชี้ wild จากโมดูลย่อยของคุณจะทำให้หน่วยความจำที่สำคัญเสียหาย (และทำให้เกิดความผิดพลาด)

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

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

การกระจายทุกอย่างในหลาย ๆ กระบวนการจะบังคับให้คุณล้างการออกแบบและหลีกเลี่ยงการที่ทุกโมดูลเริ่มต้นด้วยวิธีการภายในของโมดูลอื่น ๆ

ที่ถูกกล่าวว่ามันอาจเป็นงานที่น่ากลัว

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


คุณสมมติว่าน่ากลัวอย่างมากเกี่ยวกับฮาร์ดแวร์รันไทม์และสภาพแวดล้อมระบบปฏิบัติการโดยเฉพาะอย่างยิ่งเมื่อเกี่ยวข้องกับเฟิร์มแวร์และอุปกรณ์ฝังตัว
Patrick Hughes

0

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

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.