Có bằng chứng nào cho thấy việc sử dụng tiêm phụ thuộc giúp cải thiện kết quả trong công nghệ phần mềm không?

Mặc dù mức độ phổ biến của nó, có bằng chứng thực nghiệm nào cho thấy Dependency Injection (và / hoặc sử dụng thùng chứa DI) giúp, nói, giảm số lượng lỗi, cải thiện khả năng bảo trì hoặc tăng tốc độ phát triển cho các dự án phần mềm thực tế?

TLD

Các dữ liệu thực nghiệm là không liên quan. Các công cụ và thực hành (như DI) giải quyết các vấn đề cụ thể . Hiểu vấn đề của bạn, tìm hiểu cách sử dụng các công cụ và sẽ trở nên rõ ràng khi một công cụ có giá trị - và bạn sẽ có thể giải thích các kết quả mang tính tiên tri hơn nhiều so với bất kỳ dữ liệu tổng hợp, thực nghiệm nào.

Và bây giờ, với sự dài dòng hơn nhiều ...

Có bằng chứng thực nghiệm?

Chắc chắn, có lẽ. Hoặc ít nhất có thể. Nhưng ai quan tâm chứ? Nó không liên quan.

Một phân tích lợi ích chi phí thống kê của DI có thể thú vị về mặt học thuật, nhưng, nó không nhất thiết dự đoán thành công cá nhân. Kết quả tổng hợp ẩn những thành công và thất bại cá nhân . Và, tôi có thể lập luận rằng dữ liệu liên quan đến thực hành "truyền giáo" là đặc biệt độc hại. Những nguyên tắc này có xu hướng thu hút cả những người quá khích và những kẻ ngốc, cả hai đều che khuất tác động ròng của việc thực hiện "thuần túy", và một trong hai bạn có thể là!

Vì vậy, làm thế nào để chúng ta biết Dependency Injection có giá trị gì cả?

Câu hỏi hay! Câu hỏi TUYỆT VỜI, trên thực tế. Và tôi với bạn - Tôi ghét lãng phí thời gian và nỗ lực tinh thần vào những "thực hành tốt nhất" giáo điều mà không ai có thể biện minh được. Vì vậy, tôi rất vui khi bạn hỏi.

Ừm Nhưng, đây là vấn đề đáng xấu hổ ... Nói chung , bạn không biết. Và, thậm chí đáng xấu hổ hơn, mã của bạn có thể không thực sự trở nên tốt hơn bằng bất kỳ cách nào bằng cách giới thiệu DI.

KHÍ!

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

...

Vì vậy, có lẽ bây giờ bạn đang tự hỏi ...

Tại sao tôi phải bận tâm 'những điều chưa được chứng minh er nuthin'!?

Trước hết, hãy để tất cả - trên mọi khía cạnh của cuộc tranh luận - chỉ cần giải quyết. Tôi có thể đảm bảo với bạn rằng giữa chủ nghĩa giáo điều và chủ nghĩa hoài nghi là một thiên đường đẹp đẽ của lý trí và sự đứng đầu cấp độ. (Và bài đăng SE.SE lập dị thỉnh thoảng.) Và, POAP có thể dẫn bạn đến đó.

... Ý tôi là, Nguyên tắc áp dụng các nguyên tắc :

Nguyên tắc, mô hình và thực hành không phải là mục đích cuối cùng. Do đó, ứng dụng tốt và phù hợp của mỗi người được truyền cảm hứng và hạn chế bởi một mục đích cao cấp hơn, cuối cùng.

Bạn cần hiểu lý do tại sao bạn đang làm những gì bạn đang làm!

(POAP không được miễn trừ khỏi POAP.)

^{(Tôi muốn nói, "nhấn mạnh của tôi", nhưng dù sao nó cũng là từ "blog" của riêng tôi. Vì vậy, tất cả là của tôi!)}

Hãy để tôi nhắc lại ý chính ở đó: Bạn cần hiểu lý do tại sao bạn làm những gì bạn đang làm.

Và có lẽ để làm rõ, thường không có ý nghĩa gì khi sử dụng bất kỳ "thứ gì" (như Dependency Injection), và sử dụng nó mà không hiểu vấn đề mà nó giải quyết - cụ thể là gì. Nếu bạn hiểu vấn đề của mình và "cái gì đó" (như DI) hoạt động như thế nào, thì "phần nào" sẽ hữu ích như thế nào, rất nhiều cho dù dữ liệu tổng hợp, theo kinh nghiệm cho thấy gì.

Nếu sự hữu ích hoặc không có ích của DI đối với bạn là không rõ ràng - hoặc ít nhất là vượt quá khả năng lý luận của bạn - bạn không hiểu DI, hoặc bạn không hiểu vấn đề của chính mình.

Chúng ta hãy xem xét một "ngụ ngôn" trong thế giới thực.

Chúng ta cần xây dựng một hộp. Chúng tôi có gỗ. Chúng tôi có móng tay. Và, chúng tôi có hai công cụ: Một cái búa vuốt tiêu chuẩn và một cái tuốc nơ vít .

Bây giờ, chúng ta có thể có một số dữ liệu thực nghiệm rộng rãi để chỉ ra rằng các hộp được chế tạo bằng tua vít là các hộp mạnh hơn đáng kể về tổng thể, so với các hộp được xây dựng bằng búa. Nhưng, nếu bạn cố gắng vặn những cái đinh đó vào, bạn sẽ không có một cái hộp nào cả. Và, nếu bạn cố gắng đập chúng vào bằng tuốc nơ vít, cuối cùng bạn có thể đưa chúng vào; nhưng, nó sẽ đòi hỏi nhiều thời gian và công sức hơn đáng kể, và kết quả cuối cùng sẽ kém chính xác (và mạnh mẽ) hơn so với việc bạn sử dụng búa.

Và, nếu bạn đã từng thấy ai đó sử dụng một trong hai công cụ trước đây và nếu bạn hiểu hộp trông như thế nào, quyết định là hiển nhiên.

Telekinesis!

Ơ ... ừm ...

Vâng - Vậy, Dependency Injection giải quyết vấn đề gì?

Nó hoạt động để ngăn chặn mã cứng, không thể cấu hình, do đó thường không thể kiểm tra được .

Nó thực hiện điều này bằng cách cho phép gọi mã để quyết định các đối tượng mà mô-đun hoạt động với. Và tôi biết bạn đang nghĩ về điều đó, và bạn đã đúng: Đây thậm chí không phải là một khái niệm mới. Các tham số Phương thức / Hàm đã tồn tại kể từ khi đại số xảy ra.

Chúng tôi bắt đầu truyền giáo thông số cơ bản, gọi đó là "Dependency Injection", một khi chúng tôi tích lũy và kế thừa đủ mã để thấy sự mất cân bằng của chúng tôi. Hàng núi mã chúng tôi đang ngồi trên không thể dễ dàng thay đổi, kiểm tra hoặc thậm chí sử dụng lại , đơn giản chỉ vì sự phụ thuộc đã bị ẩn đi.

Do đó, cuộc thập tự chinh sốt sắng cho tiêm phụ thuộc ...

K. Nhưng, tôi có thể vượt qua các cuộc tranh luận chỉ trong tốt. Tại sao các khung ?

Theo tôi hiểu, các khung DI chủ yếu giải quyết vấn đề tích tụ nồi hơi (do DI quá nhiệt, IMO) - đặc biệt khi có các phụ thuộc "mặc định" tiêu chuẩn cho tất cả các mô-đun yêu cầu chúng. Các khung DI thực hiện những điều kỳ diệu (thậm chí là nghịch ngợm!) Để bỏ qua những phụ thuộc mặc định đó khi chúng không được thông qua rõ ràng tại điểm gọi. (Hiệu ứng tương tự như Trình định vị dịch vụ khi được sử dụng theo cách này, làm phiền bạn!)

Dependency Injection, như một "kỷ luật", thực sự rất khó để có được đúng. Đó không phải là vấn đề sử dụng DI hay không; đó là một vấn đề của biết mà phụ thuộc có thể sẽ thay đổi hoặc cần mocking và tiêm những . Và sau đó, vấn đề là quyết định liệu DI có phù hợp hơn một số thay thế hay không, như Vị trí dịch vụ ...

Nhưng, tôi muốn khuyến khích bạn Google nó , có thể thấy câu trả lời SO này , có thể nói chuyện với một nhà phát triển siêu giàu kinh nghiệm và thành công trong ngành công nghiệp của bạn, và các ví dụ cụ thể đường bưu điện đến CR.SE .

Tôi đã tìm kiếm Google, Google Scholar, ACM và IEEE Đây là những tài liệu tôi có thể tìm thấy:

• Khung phụ thuộc tiêm: một cải tiến để kiểm tra? . Nó lập luận rằng "khả năng kiểm tra" có thể được định nghĩa là "sự gắn kết thấp". Nó nói rằng DI dẫn đến sự gắn kết thấp hơn, sự gắn kết thấp hơn có tương quan với độ bao phủ thử nghiệm cao hơn và phạm vi thử nghiệm cao hơn có tương quan với nhiều lỗi được tìm thấy. Nó nói rằng, dựa trên điều này, DI cải thiện khả năng kiểm tra.

  Tôi không thích điều này vì một vài lý do. Trước hết, nó nói "A tương quan với B, B tương quan với C, vì vậy A gây ra C", đó là một vài bước trong logic mà tôi không thấy được hỗ trợ bởi bài báo. Thứ hai, nó thừa nhận rằng nó chỉ đo lường "các nhánh con của khả năng kiểm tra" và nói chung, "khả năng kiểm tra" nói chung không phải là thứ dễ dàng xác định. Cuối cùng, thước đo khả năng kiểm tra của họ được xác định theo số lượng phụ thuộc được tiêm!

• Ảnh hưởng của tiêm phụ thuộc vào khả năng duy trì . Họ so sánh các dự án sử dụng DI với các dự án không sử dụng DI mà họ tìm thấy trên SourceForge và xem liệu có sự khác biệt nào trong các số liệu về sự gắn kết hay không. Để giảm sự thiên vị, họ đã ghép các dự án sao cho giống nhau nhất có thể. Cuối cùng, họ đã thấy các tín hiệu cho thấy các dự án có nhiều DI được ghép đôi ít hơn so với các dự án chỉ có một chút DI. Tuy nhiên, dường như không có sự khác biệt đáng kể về sự gắn kết giữa các dự án DI và cặp không DI của chúng, vì vậy nó có thể là hậu quả của các miền cụ thể. Họ liệt kê "không tương quan" là kết quả chính của họ và "có thể nó sẽ giúp một chút?" như một chủ đề để nghiên cứu thêm.

• Đánh giá thực nghiệm tác động của việc tiêm phụ thuộc vào sự phát triển của các ứng dụng dịch vụ web . Bản tóm tắt không thực sự giải thích những gì họ đang tìm kiếm. Tôi đã đào lên và đọc một bản in sẵn và theo như tôi có thể nói thực sự về việc công cụ tự động có thể khám phá các dịch vụ tốt như thế nào. Các dịch vụ được viết theo kiểu DI dễ dàng được phát hiện hơn. Ngoài ra, nó trích dẫn nghiên cứu trước đây tôi liệt kê là cung cấp bằng chứng thực nghiệm rằng DI làm giảm sự ghép đôi, điều này trái ngược với những gì bài báo đã tuyên bố.

Đối với ba bài báo này (và cho một nghiên cứu thực nghiệm về sử dụng tiêm phụ thuộc trong Java , chỉ nói về phát hiện) Tôi đã theo dõi tất cả các bài báo trích dẫn chúng, không có bài nào trong số đó là về việc xác định hiệu quả của DI. Với tất cả những điều này, tôi tự tin nói rằng không , chúng tôi chưa có bằng chứng thực nghiệm về việc liệu DI có cải thiện chất lượng phần mềm hay không.