มีหลักฐานว่าการใช้การฉีดพึ่งพาช่วยปรับปรุงผลลัพธ์ในวิศวกรรมซอฟต์แวร์หรือไม่?

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

TLDR

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

และตอนนี้ด้วยความฟุ่มเฟื่อยมากขึ้น ...

มีหลักฐานเชิงประจักษ์หรือไม่?

แน่นอนว่าอาจ หรืออย่างน้อยก็อาจ แต่ใครจะสนล่ะ? มันไม่เกี่ยวข้อง

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

ดังนั้นเราจะรู้ได้อย่างไรว่าการพึ่งพาการฉีดมีค่าเลย?

คำถามที่ดี! คำถามที่ยอดเยี่ยมจริงๆแล้ว และฉันอยู่กับคุณ - ฉันเกลียดการเสียเวลาและความพยายามทางจิตในการ“ ปฏิบัติที่ดีที่สุด” ที่ไร้เหตุผลซึ่งไม่มีใครพิสูจน์ได้ ดังนั้นฉันดีใจที่คุณถาม

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

หอบ!

    ⊙▃⊙     . . .      (╯°□°)╯︵ ┻━┻

...

ดังนั้นบางทีตอนนี้คุณสงสัย ...

ทำไมฉันถึงต้องรำคาญ 'สิ่งที่เกี่ยวกับการแข่งขันที่ไม่ได้รับการพิสูจน์ว่าเป็นจริง'!

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

... โดยที่ฉันหมายถึงหลักการของการประยุกต์ใช้หลักการ :

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

คุณต้องเข้าใจว่าทำไมคุณถึงทำสิ่งที่คุณทำ!

(POAP ไม่ได้รับการยกเว้นจาก POAP)

^{(ฉันบอกว่า "เน้นของฉัน" แต่มาจาก "บล็อก" ของฉันเองอยู่ดีดังนั้นมันเป็นของฉันทั้งหมด !)}

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

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

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

ลองพิจารณาคำอุปมาเรื่องโลกแห่งความจริง

เราจำเป็นต้องสร้างกล่อง เรามีไม้ เรามีเล็บ และเรามีสองเครื่องมือ: กรงเล็บค้อนมาตรฐานและไขควง

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

และถ้าคุณเคยเห็นใครบางคนเคยใช้เครื่องมืออย่างใดอย่างหนึ่งมาก่อนและถ้าคุณเข้าใจว่ากล่องมีลักษณะอย่างไร

จิต!

เอ่อ ... อืม ...

ใช่แล้วการพึ่งพาการฉีดจะแก้ปัญหาอะไรได้บ้าง

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

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

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

ดังนั้นสงครามครูเสดที่กระตือรือร้นสำหรับการฉีดพึ่งพา ...

เค แต่ฉันสามารถผ่านการโต้แย้งได้ดี ทำไมกรอบ ?

ตามที่ฉันเข้าใจแล้ว DI Frameworksส่วนใหญ่จะแก้ปัญหาการสะสมของ boilerplate (เนื่องจาก overzealous DI, IMO) โดยเฉพาะอย่างยิ่งเมื่อมีการพึ่งพา "ค่าเริ่มต้น" มาตรฐานสำหรับโมดูลทั้งหมดที่ต้องการ กรอบ DI ทำสิ่งมหัศจรรย์ (อาจซุกซน!) ที่จะลื่นการพึ่งพาเริ่มต้นเหล่านั้นในเมื่อพวกเขาไม่ได้ผ่านอย่างชัดเจน ณ จุดที่ขอร้อง (มีผลเหมือนกับผู้ให้บริการเมื่อใช้ในลักษณะนี้โปรดทราบ!)

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

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

ฉันค้นหา Google, Google Scholar, ACM และ IEEE นี่คือเอกสารที่ฉันสามารถหาได้:

• กรอบการฉีดพึ่งพา: การปรับปรุงเพื่อทดสอบได้? . มันระบุว่า "testability" สามารถกำหนดเป็น "การทำงานร่วมกันต่ำ" มันระบุว่า DI นำไปสู่การทำงานร่วมกันที่ต่ำกว่าการทำงานร่วมกันที่ต่ำกว่ามีความสัมพันธ์กับการครอบคลุมการทดสอบที่สูงขึ้นและที่ครอบคลุมการทดสอบที่สูงขึ้นมีความสัมพันธ์กับข้อบกพร่องที่พบมากขึ้น มันบอกว่าบนพื้นฐานนี้ DI ปรับปรุงความสามารถในการทดสอบ

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

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

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

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