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


9

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

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

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

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

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

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


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

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

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

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


คุณกำลังพูดถึงสิ่งที่เหมือนภาชนะ DI ไม่ตั้งค่าอย่างถูกต้องเพื่อทราบว่าสำหรับ IFoo ใช้ IFooImpl?
แอนดี้

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

2
Come on, "ปัญหาการพึ่งพา" เป็นคำทั่วไปมากและทุกคนที่อ่านสิ่งนี้อาจนึกภาพสิ่งที่แตกต่าง สำหรับ softare โลกแห่งความจริงนี้ขึ้นอยู่กับเทคโนโลยีดังนั้นโปรดยกตัวอย่างจริงสำหรับเทคโนโลยีเฉพาะที่คุณมีในใจ มีปัญหาเกิดขึ้นเนื่องจากส่วนประกอบที่จำเป็นขาดหายไปหรือไม่ หรือเพราะมีรุ่นที่ไม่ถูกต้อง กลไกการแก้ปัญหาการพึ่งพาแบบใดที่มีอยู่แล้ว กรุณาชี้แจง
Doc Brown

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

2
"ฉันไม่สามารถควบคุมวิธีการจัดการการพึ่งพาและไม่สามารถเปลี่ยนรหัสใด ๆ " - คุณสามารถเปลี่ยนแปลงอะไรได้บ้าง หากคุณไม่สามารถเปลี่ยนแปลงอะไรเลยคำถามดูเหมือนไร้ประโยชน์
Doc Brown

คำตอบ:


6

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

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

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


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

2
@ ไทเลอร์: อย่างไรก็ตามฉันคิดว่านี่เป็นคำตอบทั่วไปที่ดีสำหรับคำถามทั่วไป
Doc Brown

1
ฟังดูเหมือน osgi
SpaceTrucker

4

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

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

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

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

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

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


2

ลองคิดดูสิฉันแค่คิดถึงเสียงดังที่นี่ ขึ้นอยู่กับข้อกำหนด / เวลาที่ จำกัด ฉันอาจพิจารณาสิ่งนี้:

1) สร้างรายการส่วนต่อประสานและการนำไปใช้ (ใช้การสะท้อนหากมี)

2) สร้าง wrapper รอบ DI ของคุณ เมื่อมีการขอให้ DI ดำเนินการอย่างเป็นรูปธรรมดูว่ามีกฎ DI อยู่หรือไม่ หากกฎมีอยู่ - เพียงแค่คืนสิ่งที่ DI ของคุณมอบให้; มิฉะนั้นหากมีการใช้อินเทอร์เฟซเดียวและคุณสามารถสร้างอินสแตนซ์ได้ - บันทึกและส่งคืนอินสแตนซ์ มิฉะนั้นเข้าสู่ระบบและล้มเหลว

ขึ้นอยู่กับว่าคุณต้องการมีส่วนร่วมอย่างไรฉันเดาว่า แต่ในที่สุดคุณก็อยากได้รายการที่สมบูรณ์ว่าต้องการอะไร - โซลูชันนี้จะสร้างรายการในที่สุด

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

คุณหมายถึงอะไรเมื่อคุณพูดว่า "การเปลี่ยนแปลงส่วนประกอบต้นน้ำ"


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

2

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

ฉันเดาว่าเมื่อคุณถามเพื่อนร่วมงานว่า 'ฉันจะทำให้มันใช้งานได้อย่างไร' พวกเขาพูดว่า 'คุณต้องมีรายการโมดูลและรุ่น 35 รายการคุณจะไม่รู้ได้อย่างไร'

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

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


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