แจ้งให้ทราบว่าฉันเป็นแฟนตัวยงของการฉีด (DI) และการทดสอบอัตโนมัติ ฉันสามารถพูดได้ทั้งวันเกี่ยวกับเรื่องนี้

พื้นหลัง

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

ความต้านทาน

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

ย้ายของฉัน

สิ่งนี้อาจฟังดูแปลก แต่ห้องสมุดบุคคลที่สามมักไม่ได้รับการอนุมัติจากทีมสถาปนิกของเรา (คิดว่า: "อย่าพูดถึงUnity , Ninject , NHibernate , MoqหรือNUnitเพื่อมิให้ฉันตัดนิ้ว" ดังนั้นแทนที่จะใช้คอนเทนเนอร์ DI ที่สร้างไว้ฉันจึงเขียนคอนเทนเนอร์ที่แสนง่าย โดยทั่วไปจะเชื่อมโยงการพึ่งพาทั้งหมดของคุณเมื่อเริ่มต้นใช้งานฉีดการพึ่งพาใด ๆ (คอนสตรัคเตอร์ / คุณสมบัติ) และกำจัดวัตถุที่ใช้แล้วทิ้งใด ๆ ที่ส่วนท้ายของคำขอเว็บ มันเบามากและทำในสิ่งที่เราต้องการ จากนั้นฉันก็ขอให้พวกเขาทบทวนมัน

การตอบสนอง

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

ในที่สุดคำถามของฉัน

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

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

ปรับปรุง

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

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

การโต้แย้งคู่กัน:

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

"มันไม่เหมือนเราจะเสียบปลั๊กในส่วนประกอบต่าง ๆ "

สิ่งที่คุณต้องการสำหรับระบบที่จะทดสอบได้ เพื่อให้สามารถทดสอบได้ง่ายคุณจะต้องดูที่การจำลองเลเยอร์ต่างๆของโครงการ (ฐานข้อมูลการสื่อสาร ฯลฯ ) และในกรณีนี้คุณจะต้องเสียบปลั๊กในส่วนประกอบที่แตกต่างกัน

ขาย DI เกี่ยวกับประโยชน์การทดสอบที่จะให้คุณ ถ้าโครงการซับซ้อนคุณต้องทำการทดสอบหน่วยที่ดี

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

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

"เราต้องการ X, Y และ Z"

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

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

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

เมื่อคุณถามฉันจะพาทีมของคุณสู้กับ DI

กรณีต่อต้านการฉีดพึ่งพา

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

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

ดังนั้นจึงเป็นการยากที่จะพิสูจน์ว่าโปรแกรมนั้นถูกต้องเมื่อใช้ DI ผู้คนจำนวนมากยืนยันว่าโปรแกรมใช้ DI จะง่ายต่อการทดสอบแต่การทดสอบโปรแกรมไม่สามารถพิสูจน์ได้ว่ากรณีที่ไม่มีข้อบกพร่อง (โปรดทราบว่ากระดาษที่เชื่อมโยงนั้นมีอายุประมาณ 40 ปีและมีการอ้างอิงที่เป็นความลับบางอย่างและอ้างถึงแนวปฏิบัติที่ล้าสมัย แต่ข้อความพื้นฐานหลายฉบับยังคงเป็นจริงโดยเฉพาะอย่างยิ่ง P <= p ^ n ที่ P ความน่าจะเป็นที่ระบบไม่มีข้อบกพร่องคือ p ความน่าจะเป็นที่ส่วนประกอบของระบบเป็นอิสระจากข้อบกพร่องและ n คือจำนวนส่วนประกอบแน่นอนว่าสมการนี้มีความซับซ้อนมาก แต่ชี้ไปที่ความจริงที่สำคัญ) ความผิดพลาดของ NASDAQ ระหว่างการเสนอขายหุ้น IPO ของ Facebook เป็นตัวอย่างล่าสุดพวกเขาอ้างว่าใช้เวลา 1,000 ชั่วโมงในการทดสอบโค้ดและยังไม่ได้เปิดเผยข้อบกพร่องที่ทำให้เกิดการขัดข้อง 1,000 ชั่วโมงครึ่งปีต่อคนดังนั้นจึงไม่เหมือนกับการทดสอบ

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

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

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

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

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

• "มันเป็นปัญหาของคนเสมอ"
• "การเปลี่ยนแปลงน่ากลัว"

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

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

หากคุณพบว่าวัฒนธรรมของ บริษัท ในปัจจุบันไม่ได้ทำงานกับคุณอย่างน้อยคุณก็รู้ว่ามีอีกเรื่องที่ต้องถามในการสัมภาษณ์งานครั้งต่อไป ;-)

อย่าใช้ DI ลืมมันไปเถอะ

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

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

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

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

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

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

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

มีบางสถานที่ที่เหมาะสมที่จะใช้ DI:

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

ขอให้นักพัฒนาแต่ละคนรู้ว่าไฟล์การกำหนดค่า DI นั้นอยู่ที่ใด (ฉันรู้ว่าคอนเทนเนอร์สามารถสร้างอินสแตนซ์ผ่านโค้ดได้ โอ้ฉันเห็นว่ามี IRegExCompiler, DefaultRegExCompiler และ SuperAwesomeRegExCompiler ยังไม่มีที่ไหนในรหัสฉันสามารถทำการวิเคราะห์เพื่อดูว่ามีการใช้ค่าเริ่มต้นที่ไหนและใช้ SuperAwesome

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

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

DI ไม่จำเป็นต้องใช้ Inversion Inversion of Control container หรือเยาะเย้ยกรอบงาน คุณสามารถแยกรหัสและอนุญาตให้ DI ผ่านการออกแบบที่เรียบง่าย คุณสามารถทำการทดสอบหน่วยผ่านความสามารถใน Visual Studio ในตัว

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

เพียงจำไว้ว่าการประนีประนอมเป็นสิ่งจำเป็นในสถานการณ์เหล่านี้

ฉันไม่คิดว่าคุณจะขาย DI ได้อีกต่อไปเพราะนี่เป็นการตัดสินใจที่ไร้เหตุผล (หรือตามที่ @Spoike เรียกว่าสุภาพมากขึ้นการเมือง )

ในสถานการณ์นี้การโต้เถียงกับแนวทางปฏิบัติที่ดีที่สุดที่ยอมรับกันอย่างกว้างขวางเช่นหลักการออกแบบ SOLIDเป็นไปไม่ได้อีกต่อไป

คนที่มีอำนาจทางการเมืองมากกว่าที่คุณตัดสินใจ (อาจผิด) ที่จะไม่ใช้ DI

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

การวิเคราะห์

ในความคิดของฉัน DI ที่ไม่มีการพัฒนาทดสอบ (TDD) และการทดสอบหน่วยไม่มีประโยชน์อย่างมีนัยสำคัญที่เทียบกับค่าใช้จ่ายเพิ่มเติมเริ่มต้น

ปัญหานี้เกี่ยวกับจริงๆหรือ

• เราไม่ต้องการ DI ?

หรือนี่คือเพิ่มเติมเกี่ยวกับ

• tdd / unittesting เป็นการสิ้นเปลืองทรัพยากรหรือไม่

[Update]

หากคุณเห็นโครงการของคุณจากความผิดพลาดแบบคลาสสิกในมุมมองการจัดการโครงการคุณจะเห็น

#12: Politics placed over substance.
#21: Inadequate design. 
#22: Shortchanged quality assurance.
#27: Code-like-hell programming.

ในขณะที่คนอื่นเห็น

#3: Uncontrolled problem employees. 
#30: Developer gold-plating. 
#32: Research-oriented development. 
#34: Overestimated savings from new tools or methods. 

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

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

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

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

แต่พูดแทนคุณมีการแก้ไขข้อบกพร่องที่ปกติได้รับ IFDEF'ed ออกมา และทุกครั้งที่ผู้ใช้มีปัญหาทีมสนับสนุนของคุณต้องส่งบิลด์ debug ให้พวกเขาเพื่อให้พวกเขาสามารถรับเอาท์พุทบันทึกได้ คุณสามารถใช้ DI ที่นี่เพื่อให้ลูกค้าสามารถสลับระหว่างไดรเวอร์การบันทึก - LogConsoleสำหรับนักพัฒนาLogNullสำหรับลูกค้าและLogNetworkสำหรับลูกค้าที่มีปัญหา บิลด์เดียวที่รวมเป็นหนึ่งสามารถกำหนดค่าได้

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

เมื่อคุณขายความคิดอย่างถูกต้องผู้คนจะไม่ทราบว่าคุณเชื่อในสิ่งใด

แน่นอนว่าการพลิกกลับของการควบคุม (IoC) มีประโยชน์มากมาย: มันทำให้รหัสง่ายขึ้นเพิ่มความมหัศจรรย์ที่ทำหน้าที่ทั่วไป ฯลฯ

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

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

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

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

4. การใช้งาน IoC โดยปกติจะไม่จบลงด้วยการพึ่งพาการฉีดมันจะจบลงด้วยพร็อกซีนับไม่ถ้วนและคุณจะได้รับการติดตามสแต็กนับหลายร้อยบรรทัด 90% ซึ่งเป็นพร็อกซี่และเรียกผ่านสะท้อน มันซับซ้อนมากในการวิเคราะห์การติดตามสแต็ค

ดังนั้นฉันจึงเป็นแฟนตัวยงของ Spring และ IoC เมื่อเร็ว ๆ นี้ฉันต้องทบทวนคำถามข้างต้นอีกครั้ง เพื่อนร่วมงานของฉันบางคนเป็นนักพัฒนาเว็บที่ดำเนินการในโลก Java จากโลกของเว็บที่ปกครองโดย Python และ PHP และสิ่งที่ชัดเจนสำหรับสิ่ง javaist นั้นเป็นอะไรที่ชัดเจนกว่าสำหรับพวกเขา เพื่อนร่วมงานอื่นของฉันบางคนกำลังใช้อุบาย (แน่นอนไม่มีเอกสาร) ซึ่งทำให้เกิดข้อผิดพลาดได้ยากมาก แน่นอนการหลอกลวง IoC ทำให้สิ่งที่เบาสำหรับพวกเขา;)

คำแนะนำของฉันหากคุณบังคับให้มีการใช้งาน IoC ในงานของคุณคุณจะต้องรับผิดชอบต่อการใช้ข้อมูลที่ผิดที่คนอื่นจะทำ;)

ฉันคิดว่า ChrisF เป็นสิ่งที่ถูกต้อง อย่าขาย DI ในตัวมันเอง แต่ขายความคิดเกี่ยวกับหน่วยทดสอบรหัส

วิธีการหนึ่งในการรับคอนเทนเนอร์ DI เข้ากับสถาปัตยกรรมอาจเป็นการปล่อยให้การทดสอบช้าลงผลักดันการปรับใช้ให้เป็นสิ่งที่เหมาะสมกับสถาปัตยกรรมนั้น เช่นสมมติว่าคุณกำลังทำงานกับคอนโทรลเลอร์ในแอปพลิเคชัน ASP.NET MVC สมมติว่าคุณเขียนชั้นเรียนเช่นนี้:

public class UserController {
    public UserController() : this (new UserRepository()) {}

    public UserController(IUserRepository userRepository) {
        ...
    }

    ...
}

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

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

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

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

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

ดังนั้นคำแนะนำของฉันคือการทดสอบหน่วยแชมป์เปี้ยนครั้งแรกและการปรับสภาพใหม่ในเวลาต่อมาแนะนำภาชนะ DI และในที่สุด DI

ฉันได้ยิน noos ใหญ่จากทีมของคุณที่นี่:

• "ไม่มีห้องสมุดบุคคลที่สาม" - AKA "ไม่ได้คิดค้นที่นี่" หรือ "NIH" ความกลัวคือการใช้ไลบรารี่ของบุคคลที่สามและทำให้โค้ดเบสขึ้นอยู่กับว่าไลบรารีนั้นมีบั๊กหรือรูโหว่หรือแม้กระทั่งข้อ จำกัด ที่คุณต้องเอาชนะ บุคคลที่จะแก้ไขห้องสมุดของพวกเขาเพื่อให้รหัสของคุณทำงาน ในขณะเดียวกันเนื่องจากโปรแกรม "ของคุณ" ที่ล้มเหลวอย่างงดงามหรือถูกแฮ็กหรือไม่ได้ทำตามที่พวกเขาร้องขอคุณยังคงต้องรับผิดชอบ (และ devs บุคคลที่สามจะบอกว่าเครื่องมือของพวกเขาเป็น "ตามที่เป็นอยู่" "ใช้ความเสี่ยงของคุณเอง)

  ข้อโต้แย้งคือว่ารหัสที่แก้ปัญหามีอยู่แล้วในห้องสมุดบุคคลที่สาม คุณกำลังสร้างคอมพิวเตอร์ของคุณจากศูนย์? คุณเขียน Visual Studio หรือไม่ คุณละทิ้งไลบรารีที่มีอยู่แล้วใน. NET หรือไม่ ไม่คุณมีระดับความน่าเชื่อถือใน Intel / AMD และ Microsoft และพวกเขาพบข้อบกพร่องตลอดเวลา (และไม่แก้ไขได้อย่างรวดเร็วเสมอ) การเพิ่มห้องสมุดบุคคลที่สามช่วยให้คุณสามารถใช้งานฐานข้อมูลโค้ดที่สามารถบำรุงรักษาได้อย่างรวดเร็วโดยไม่ต้องเปลี่ยนรูปแบบล้อ และทนายของ Microsoft จะหัวเราะในหน้าของคุณเมื่อคุณบอกพวกเขาว่าข้อผิดพลาดในไลบรารีการเข้ารหัส. NET ทำให้พวกเขาต้องรับผิดชอบต่อเหตุการณ์แฮ็คที่ลูกค้าของคุณประสบเมื่อใช้โปรแกรม. NET ของคุณ ในขณะที่ Microsoft จะข้ามไปแก้ไขช่องโหว่ด้านความปลอดภัย "ศูนย์" ในผลิตภัณฑ์ใด ๆ ของ บริษัท อย่างแน่นอน

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

• "DI is taboo" - WTF หรือไม่ DI เป็นวิธีปฏิบัติที่ดีที่สุดที่ยอมรับได้ในภาษา O / O ใด ๆ ที่มีการสร้างรหัส "ส่วนต่อประสาน" ทีมของคุณปฏิบัติตามวิธีการออกแบบ GRASP หรือ SOLID อย่างไรหากพวกเขาไม่ได้มีความสัมพันธ์ที่พึ่งพาระหว่างวัตถุอย่างอิสระ หากพวกเขาไม่ได้รบกวนพวกเขาก็จะขยายโรงงานสปาเก็ตตี้ที่ทำให้ผลิตภัณฑ์มีความซับซ้อน ตอนนี้ DI เพิ่มความซับซ้อนด้วยการเพิ่มจำนวนวัตถุและในขณะที่ทำให้การใช้งานที่แตกต่างง่ายขึ้น แต่การเปลี่ยนส่วนต่อประสานนั้นทำได้ยากขึ้น (โดยการเพิ่มเลเยอร์พิเศษของรหัสวัตถุที่ต้องเปลี่ยน)

• "เราไม่จำเป็นต้องเพิ่มความซับซ้อนของเลเยอร์นี้ในโครงการที่ซับซ้อนอยู่แล้ว" - พวกเขาอาจมีประเด็น สิ่งสำคัญที่ควรพิจารณาในการพัฒนาโค้ดคือ YAGNI "คุณไม่ต้องการมัน" การออกแบบที่ได้รับการออกแบบทางวิศวกรรมตั้งแต่ต้นคือการออกแบบที่ทำขึ้นเพื่อ "บนศรัทธา" SOLID; คุณไม่รู้ว่าคุณต้องการความง่ายดายในการเปลี่ยนแปลงหรือไม่ที่ SOLID ออกแบบให้ แต่คุณมีลางสังหรณ์ ในขณะที่คุณอาจถูกคุณอาจผิดมาก การออกแบบที่เป็นของแข็งมากอาจถูกมองว่าเป็น "รหัสลาซานญ่า" หรือ "รหัสราวีโอลี่" ซึ่งมีหลายชั้นหรือชิ้นขนาดกัดที่ทำให้การเปลี่ยนแปลงเล็กน้อยดูเหมือนจะยากเพราะคุณต้องขุดผ่านหลายชั้นและ / หรือติดตามผ่าน เช่น call stack ที่ซับซ้อน

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

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

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

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

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

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

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

MyClassConstructor()
{
    MyClassConstructor(new Dependency)
    Property = New Dependent Property
}

MyClassConstructor(Dependency)
{
    _Dependency = Dependency
}

ฉันคิดว่าหนึ่งในความกังวลที่ยิ่งใหญ่ที่สุดของพวกเขาคืออันที่จริงตรงกันข้าม: DI ไม่ได้ทำให้โครงการซับซ้อน ในกรณีส่วนใหญ่จะลดความซับซ้อนมากมาย

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

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

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

ดังนั้น DI ไม่ได้ทำให้โครงการซับซ้อนมันทำให้มันง่ายขึ้นโดยการทำให้ส่วนประกอบง่ายขึ้น

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

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

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

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

ให้พวกเขาลองเขียนบททดสอบโดยใช้กรอบ DI และไลบรารี่จำลองพวกเขาจะเรียนรู้ที่จะรัก

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

แม้ว่าหนึ่งในสิ่งที่ส่งเสริม DI คือการทดสอบหน่วย แต่ฉันเชื่อว่ามันเพิ่มชั้นของความซับซ้อนในบางกรณี

• ดีกว่าที่จะมีรถยากในการทดสอบ แต่ง่ายในการซ่อมกว่ารถง่ายในการทดสอบและยากในการซ่อม

• สำหรับฉันแล้วดูเหมือนว่ากลุ่มที่ผลักดัน DI กำลังนำเสนอความคิดของพวกเขาผ่านการมีอิทธิพลต่อวิธีการออกแบบที่มีอยู่แล้วบางอย่างที่ไม่ดี

• ถ้าเรามีวิธีการทำ 5 หน้าที่แตกต่างกัน

  DI-People กล่าวว่า:

  • ไม่มีการแยกความกังวล [ปัญหาของสิ่งนั้นคืออะไร? พวกเขากำลังพยายามทำให้มันดูแย่ซึ่งในทางตรรกะและการเขียนโปรแกรมมันจะดีกว่ามากที่จะรู้ว่าสิ่งที่คนอื่นทำอย่างใกล้ชิดเพื่อหลีกเลี่ยงความขัดแย้งและความคาดหวังที่ผิดพลาดและเพื่อดูผลกระทบของการเปลี่ยนแปลงรหัสได้ง่าย วัตถุที่ไม่เกี่ยวข้องกัน 100% หรืออย่างน้อยเราไม่สามารถรับประกัน {นี้ได้นอกจากว่าเหตุใดการทดสอบการถดถอยจึงมีความสำคัญ?}]
  • ซับซ้อน [พวกเขาต้องการลดความซับซ้อนโดยเพิ่มคลาสเพิ่มเติมอีกห้าคลาสเพื่อจัดการหนึ่งฟังก์ชันและคลาสเพิ่มเติม (คอนเทนเนอร์) เพื่อสร้างคลาสสำหรับฟังก์ชันที่ต้องการตอนนี้ตามการตั้งค่า (XML หรือพจนานุกรม) เพิ่มเติมจากปรัชญา "เพื่อให้เป็นค่าเริ่มต้น / หรือไม่ใช่ "การอภิปราย, ... ] จากนั้นพวกเขาย้ายความซับซ้อนไปยังที่เก็บและไปยังโครงสร้าง, [สำหรับฉันดูเหมือนว่าจะย้ายความซับซ้อนจากที่หนึ่งไปยังอีกที่สองด้วยความซับซ้อนของภาษาเฉพาะเพื่อจัดการสิ่งนี้ ]

ฉันเชื่อว่ามันเป็นการดีกว่าที่จะสร้างรูปแบบการออกแบบของเราเองที่เหมาะสมกับความต้องการทางธุรกิจมากกว่าที่จะได้รับอิทธิพลจาก DI

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