Apakah ada bukti bahwa penggunaan injeksi ketergantungan meningkatkan hasil dalam rekayasa perangkat lunak?

Terlepas dari popularitasnya, adakah bukti empiris yang menunjukkan bahwa Dependency Injection (dan / atau menggunakan wadah DI) membantu, katakanlah, mengurangi jumlah bug, meningkatkan rawatan, atau meningkatkan kecepatan pengembangan pada proyek perangkat lunak kehidupan nyata?

TLDR

Data empiris tidak relevan. Alat dan praktik (seperti DI) memecahkan masalah tertentu . Pahami masalah Anda, pelajari cara menggunakan alat, dan itu akan menjadi jelas ketika alat itu berharga - dan Anda akan dapat menjelaskan hasil yang jauh lebih kenabian daripada data empiris yang digeneralisasi, agregat, apa pun.

Dan sekarang, dengan lebih banyak kata-kata ...

Apakah ada bukti empiris?

Tentu, mungkin. Atau setidaknya mungkin. Tapi siapa peduli? Itu tidak relevan.

Analisis statistik biaya-manfaat DI mungkin menarik secara akademis, tetapi, itu tidak selalu memprediksi keberhasilan individu. Hasil agregat menyembunyikan keberhasilan dan kegagalan individu . Dan, saya mungkin berpendapat bahwa data mengenai praktik "evangelikal" sangat beracun. Disiplin ini cenderung menarik baik orang fanatik dan bodoh, yang keduanya mengaburkan dampak bersih dari implementasi "murni", dan salah satu dari yang Anda bisa !

Jadi, bagaimana kita tahu Injeksi Ketergantungan sama sekali berharga ?

Pertanyaan bagus! Sebenarnya pertanyaan HEBAT. Dan aku bersamamu - aku benci membuang waktu dan upaya mental pada "praktik terbaik" dogmatis yang tidak dapat dibenarkan oleh siapa pun. Jadi, saya senang Anda bertanya.

Uhh. Tapi, inilah masalah yang memalukan ... Secara umum , Anda tidak tahu. Dan, yang lebih memalukan lagi, kode Anda mungkin tidak benar-benar menjadi lebih baik dengan cara memperkenalkan DI.

GASP!

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

...

Jadi, mungkin sekarang Anda bertanya-tanya ...

Kenapa aku harus repot-repot tentang hal-hal yang belum terbukti?

Pertama-tama, mari kita semua - di semua sisi debat - tenang saja. Saya dapat meyakinkan Anda bahwa antara dogmatisme dan skeptisisme ada surga nalar yang indah dan berkepala dingin. (Dan posting SE.SE sesekali eksentrik.) Dan, POAP dapat membawa Anda ke sana.

... Maksud saya, Prinsip Menerapkan Prinsip :

Prinsip, pola, dan praktik bukanlah tujuan akhir. Aplikasi yang baik dan tepat dari masing-masing karena itu terinspirasi dan dibatasi oleh tujuan akhir yang lebih unggul.

Anda perlu memahami mengapa Anda melakukan apa yang Anda lakukan!

(POAP tidak dikecualikan dari POAP.)

^{(Aku akan mengatakan, "penekanan," tapi itu dari saya "blog" sendiri pula. Jadi, itu semua milikku!)}

Izinkan saya mengulangi poin utama di sana: Anda perlu memahami mengapa Anda melakukan apa yang Anda lakukan.

Dan mungkin untuk memperjelas, biasanya tidak masuk akal untuk mengambil "sesuatu" yang diberikan (seperti Injeksi Ketergantungan), dan menggunakannya tanpa sudah memahami masalah apa yang dipecahkannya - khusus untuk Anda. Jika Anda memahami masalah Anda dan bagaimana "sesuatu" (seperti DI) bekerja, akan agak "jelas" betapa membantu "sesuatu" itu, sangat terlepas dari apa yang disarankan oleh data umum, agregat, empiris.

Jika DI membantu atau tidak membantu Anda tidak jelas - atau setidaknya di luar kekuatan penalaran Anda - Anda juga tidak mengerti DI, atau Anda tidak mengerti masalah Anda sendiri.

Mari kita pertimbangkan "perumpamaan" dunia nyata.

Kita perlu membangun sebuah kotak. Kami punya kayu. Kami punya kuku. Dan, kami memiliki dua alat: Palu cakar standar dan obeng .

Sekarang, kita mungkin memiliki beberapa data empiris yang luas untuk menunjukkan bahwa kotak yang dibuat dengan obeng secara keseluruhan lebih kuat, dibandingkan dengan yang dibangun dengan palu. Tetapi, jika Anda mencoba untuk mengacaukan kuku-kuku itu, Anda tidak akan berakhir dengan sebuah kotak sama sekali. Dan, jika Anda mencoba untuk memukulnya dengan obeng, Anda mungkin akan mendapatkannya; tetapi, itu akan membutuhkan lebih banyak waktu dan usaha, dan hasil akhirnya akan kurang tepat (dan kuat) daripada Anda hanya menggunakan palu.

Dan, jika Anda pernah melihat seseorang menggunakan alat apa pun sebelumnya, dan jika Anda memahami seperti apa bentuk kotak itu, keputusannya jelas.

Telekinesis!

Err ... hmm ...

Ya-Jadi, masalah apa yang dipecahkan Dependency Injection?

Ia berfungsi untuk mencegah kode yang kaku dan tidak dapat dikonfigurasi, yang karenanya seringkali tidak dapat diuji .

Ia melakukan ini dengan mengizinkan kode pemohon untuk memutuskan objek apa yang beroperasi dengan modul. Dan saya tahu Anda memikirkannya, dan Anda benar: Ini bahkan bukan konsep baru yang jauh. Metode / Parameter fungsi telah ada sejak aljabar terjadi.

Kami mulai menginjili lewat parameter dasar, menyebutnya "Injeksi Ketergantungan", setelah kami mengakumulasikan dan mewarisi kode yang cukup untuk melihat ketidakseimbangan kami. Pegunungan kode yang kami duduki tidak dapat dengan mudah diubah, diuji, atau bahkan digunakan kembali , hanya karena dependensi disembunyikan.

Oleh karena itu, perjuangan keras untuk Injeksi Ketergantungan ...

K. Tapi, saya bisa menyampaikan argumen dengan baik. Mengapa kerangka kerja ?

Seperti yang saya pahami, kerangka kerja DI terutama menyelesaikan masalah penumpukan boilerplate (karena DI yang terlalu bersemangat, IMO) - terutama ketika ada dependensi "default" standar untuk semua modul yang membutuhkannya. Kerangka DI melakukan hal-hal ajaib (mungkin bahkan nakal!) Untuk menyelinap dependensi default mereka ketika mereka tidak secara eksplisit disahkan pada titik doa. (Efek yang sama sebagai Penentu Lokasi Layanan ketika digunakan dengan cara ini, ingat!)

Ketergantungan Injeksi, sebagai "disiplin", sebenarnya sangat sulit untuk dilakukan dengan benar. Ini bukan masalah menggunakan DI atau tidak; itu masalah mengetahui dependensi mana yang cenderung berubah atau perlu mengejek dan menyuntikkan mereka . Dan kemudian, masalah menentukan apakah DI cocok dengan yang lebih baik daripada beberapa alternatif, seperti Lokasi Layanan ...

Tapi, saya akan mendorong Anda untuk Google itu , mungkin melihat jawaban SO ini , mungkin berbicara dengan pengembang super-berpengalaman dan sukses dalam industri Anda, dan contoh-contoh spesifik posting ke CR.SE .

Saya mencari di Google, Google Cendekia, ACM, dan IEEE Inilah beberapa makalah yang saya dapat temukan:

• Kerangka kerja Dependency Injection: peningkatan kemampuan uji? . Ini berpendapat bahwa "testability" dapat didefinisikan sebagai "kohesi rendah". Ini menyatakan bahwa DI mengarah pada kohesi yang lebih rendah, kohesi yang lebih rendah berkorelasi dengan cakupan tes yang lebih tinggi, dan bahwa cakupan tes yang lebih tinggi berkorelasi dengan lebih banyak kesalahan yang ditemukan. Dikatakan bahwa, berdasarkan ini, DI meningkatkan testabilitas.

  Saya tidak suka ini karena beberapa alasan. Pertama-tama, ia mengatakan "A berkorelasi dengan B, B berkorelasi dengan C, jadi A menyebabkan C", yang merupakan beberapa langkah dalam logika yang saya lihat tidak didukung dengan baik oleh kertas. Kedua, ia mengakui bahwa itu hanya mengukur "sub bagian dari testability", dan bahwa 'testability' secara umum bukanlah sesuatu yang mudah didefinisikan. Akhirnya, ukuran testabilitas mereka didefinisikan dalam hal jumlah ketergantungan yang disuntikkan!

• Efek Injeksi Ketergantungan pada Pemeliharaan . Mereka membandingkan proyek yang menggunakan DI dengan proyek yang tidak menggunakan DI yang mereka temukan di SourceForge dan melihat apakah ada perbedaan dalam metrik kohesi. Untuk mengurangi bias, mereka memasangkan proyek agar semirip mungkin. Pada akhirnya, mereka melihat sinyal bahwa proyek dengan banyak DI agak kurang digabungkan daripada proyek dengan hanya sedikit DI. Namun, tampaknya tidak ada perbedaan yang signifikan dalam kohesi antara proyek DI dan pasangan non-DI mereka, jadi itu bisa menjadi konsekuensi dari domain tertentu. Mereka menyebutkan "tidak ada korelasi" sebagai hasil utama mereka dan "mungkin itu sedikit membantu?" sebagai topik untuk studi lebih lanjut.

• Secara empiris menilai dampak injeksi ketergantungan pada pengembangan aplikasi layanan web . Abstrak tidak benar-benar menjelaskan apa yang mereka cari. Saya menggali dan membaca pracetak dan sejauh yang saya tahu itu sebenarnya tentang seberapa baik alat otomatis dapat menemukan layanan. Layanan yang ditulis dengan gaya DI lebih mudah ditemukan. Juga, mengutip penelitian sebelumnya saya terdaftar sebagai memberikan bukti empiris bahwa DI mengurangi kopling, yang merupakan kebalikan dari apa yang diklaim kertas.

Untuk ketiga makalah ini (dan untuk Studi Empiris tentang Penggunaan Injeksi Ketergantungan di Jawa , yang hanya tentang deteksi) saya menindaklanjuti semua makalah yang mengutip mereka, tidak ada yang tentang menentukan efektivitas DI. Mengingat semua ini, saya yakin mengatakan bahwa tidak , kami belum memiliki bukti empiris tentang apakah DI meningkatkan kualitas perangkat lunak atau tidak.