Bagaimana menghadapi rasa takut mengambil ketergantungan

54

Tim yang saya tangani membuat komponen yang dapat digunakan oleh mitra perusahaan untuk berintegrasi dengan platform kami.

Karena itu, saya setuju bahwa kita harus sangat berhati-hati ketika memperkenalkan dependensi (pihak ketiga). Saat ini kami tidak memiliki dependensi pihak ketiga dan kami harus tetap pada level API terendah dari framework.

Beberapa contoh:

  • Kami dipaksa untuk tetap berada pada level API terendah dari framework (.NET Standard). Alasan di balik ini adalah bahwa suatu hari platform baru bisa tiba yang hanya mendukung tingkat API yang sangat rendah.
  • Kami telah mengimplementasikan komponen kami sendiri untuk (menonaktifkan) serialisasi JSON dan sedang dalam proses melakukan hal yang sama untuk JWT. Ini tersedia di tingkat yang lebih tinggi dari kerangka API.
  • Kami telah menerapkan pembungkus di sekitar kerangka HTTP dari pustaka standar, karena kami tidak ingin bergantung pada implementasi HTTP dari pustaka standar.
  • Semua kode untuk pemetaan ke / dari XML ditulis "dengan tangan", sekali lagi untuk alasan yang sama.

Saya merasa kami mengambilnya terlalu jauh. Saya ingin tahu bagaimana menghadapi ini karena ini saya pikir ini sangat mempengaruhi kecepatan kami.

architecture .net dependencies third-party-libraries code-ownership Bertus
sumber
20
Apakah ada pembenaran untuk ini (misalnya, persyaratan eksternal) atau apakah itu dilakukan karena ketidaktahuan?
Blrfl
6
Lakukan percobaan dengan beberapa bagian kecil basis kode, buat layer isolasi yang tidak mencoba menjadi pustaka generik, tetapi tentukan antarmuka abstrak yang memodelkan kebutuhan Anda; kemudian letakkan implementasi Anda sendiri dan ketergantungan pihak ke-3 di belakangnya, dan bandingkan cara kerja dua versi. Timbang pro dan kontra, nilai seberapa mudah (atau seberapa sulit) pertukaran implementasi, lalu buat keputusan. Pendeknya, ujilah dengan cara yang relatif berisiko rendah, lihat apa yang terjadi, lalu putuskan.
Filip Milovanović
73
"Saat ini kami tidak memiliki ketergantungan pihak ketiga" Ini selalu membuatku tertawa ketika orang mengklaim ini. Tentu saja Anda lakukan. Anda belum menulis kompiler, IDE, implementasi pustaka standar Anda sendiri. Anda belum menulis sembarang benda lumbung yang Anda gunakan secara tidak langsung (atau langsung). Ketika Anda menyadari betapa banyak perangkat lunak dan pustaka pihak ke-3 yang Anda andalkan, Anda dapat menghapus ide "dependency is bad", dan hanya menikmati tidak menciptakan kembali roda. Saya hanya akan menandai dependensi yang Anda miliki, dan kemudian bertanya mengapa mereka dapat diterima, tetapi parsing json tidak.
UKMonkey
8
Yang mengatakan ada alternatif menarik, seperti tidak pernah menyelesaikan proyek. Tapi itu mempromosikan pekerjaan perangkat lunak dan pekerjaan :)
marshal craft
5
Anda benar bahwa Anda membuang-buang upaya dengan menciptakan kembali perangkat lunak komoditas. Anda salah karena ini tidak mendekati "menghindari semua ketergantungan". Tim Excel di Microsoft pernah menulis kompiler C mereka sendiri untuk menghindari ketergantungan pada tim C di Microsoft . Anda mengambil ketergantungan yang sangat besar pada sistem operasi, kerangka kerja tingkat tinggi, dan sebagainya.
Eric Lippert

Jawaban:

94

... Kami dipaksa untuk tetap pada level API terendah dari kerangka kerja (.NET Standard) ...

Ini bagi saya menyoroti fakta bahwa, tidak hanya Anda berpotensi membatasi diri terlalu banyak, Anda juga mungkin menuju kejatuhan yang buruk dengan pendekatan Anda.

.NET Standard bukan, dan tidak akan pernah menjadi " level API terendah dari kerangka kerja ". Set API yang paling ketat untuk .NET dicapai dengan membuat perpustakaan kelas portabel yang menargetkan Windows Phone dan Silverlight.

Bergantung pada versi .NET Standard yang Anda targetkan, Anda dapat berakhir dengan serangkaian API yang sangat kaya yang kompatibel dengan .NET Framework, .NET Core , Mono , dan Xamarin . Dan ada banyak pustaka pihak ketiga yang kompatibel .NET Standard yang akan bekerja pada semua platform ini.

Lalu ada .NET Standard 2.1, kemungkinan akan dirilis pada musim gugur 2019. Ini akan didukung oleh .NET Core, Mono dan Xamarin. Ini tidak akan didukung oleh versi .NET Framework , setidaknya untuk masa mendatang, dan kemungkinan besar selalu. Jadi dalam waktu dekat, jauh dari " level API terendah dari kerangka kerja ", .NET Standard akan menggantikan kerangka kerja dan memiliki API yang tidak didukung oleh yang terakhir.

Jadi berhati-hatilah dengan " Alasan di balik ini adalah bahwa suatu hari nanti platform baru dapat datang yang hanya mendukung level API yang sangat rendah " karena sangat mungkin bahwa platform baru pada kenyataannya akan mendukung API level yang lebih tinggi daripada kerangka lama.

Lalu ada masalah perpustakaan pihak ketiga. JSON.NET misalnya kompatibel dengan .NET Standard. Pustaka apa pun yang kompatibel dengan .NET Standard dijamin - bijaksana API - untuk bekerja dengan semua implementasi .NET yang kompatibel dengan versi .NET Standard. Jadi Anda tidak mencapai kompatibilitas tambahan dengan tidak menggunakannya dan membuat perpustakaan JSON Anda. Anda hanya menciptakan lebih banyak pekerjaan untuk diri Anda sendiri dan mengeluarkan biaya yang tidak perlu untuk perusahaan Anda.

Jadi ya, Anda pasti terlalu jauh dalam pandangan saya.

David Arno
sumber
16
"Anda hanya menciptakan lebih banyak pekerjaan untuk diri Anda sendiri dan mengeluarkan biaya yang tidak perlu untuk perusahaan Anda." - dan kewajiban keamanan. Apakah JSON encoder Anda mengalami crash dengan stack overflow jika Anda memberikannya objek rekursif? Apakah parser Anda menangani karakter yang keluar dengan benar? Apakah itu menolak karakter yang tidak terhindar dari yang seharusnya? Bagaimana dengan karakter pengganti yang tidak berpasangan? Apakah itu meluap ketika JSON mengkodekan angka yang lebih besar dari 2 ^ 64? Atau itu hanya evalpembungkus kecil dengan beberapa cek kewarasan yang mudah dilewati?
John Dvorak
4
"Set API yang paling ketat untuk .NET dicapai dengan membuat perpustakaan kelas portabel yang menargetkan Windows Phone dan Silverlight." Saya akan mengambil risiko dan mengklaim bahwa setidaknya ada beberapa API dalam subset yang tidak didukung oleh semua kemungkinan implementasi yang pernah ada (dan tidak ada lagi yang peduli tentang WinPhone atau Silvernight, bahkan microsoft). Menggunakan .NetStandard 2.0 sebagai target untuk kerangka kerja modern tampaknya sangat bijaksana dan tidak terlalu membatasi. Memperbarui ke 2.1 adalah cerita yang berbeda tetapi tidak ada indikasi bahwa mereka akan melakukannya.
Voo
Selain dari platform masa depan mungkin mendukung lebih daripada kurang, mengembangkan untuk semua hal yang mungkin terjadi sangat mahal (dan Anda kemungkinan akan kehilangan sesuatu). Sebaliknya, mengembangkan tanpa menciptakan kembali roda akan menghemat lebih banyak waktu daripada beradaptasi dengan beberapa situasi baru ketika yang dibutuhkan adalah biaya.
Jasper
51

Kami dipaksa untuk tetap pada level API terendah dari kerangka kerja (standar .net). Alasan di balik ini adalah bahwa suatu hari platform baru bisa tiba yang hanya mendukung tingkat API yang sangat rendah.

Alasan di sini agak terbelakang. Tingkat API yang lebih tua dan lebih rendah cenderung menjadi usang dan tidak didukung daripada yang lebih baru. Meskipun saya setuju bahwa tetap dengan cara yang nyaman di belakang "ujung tombak" masuk akal untuk memastikan tingkat kompatibilitas yang wajar dalam skenario yang Anda sebutkan, tidak pernah bergerak maju adalah hal yang luar biasa.

Kami telah menerapkan komponen kami sendiri untuk (menonaktifkan) serialisasi JSON, dan sedang dalam proses melakukan hal yang sama untuk JWT. Ini tersedia di tingkat yang lebih tinggi dari kerangka API. Kami telah menerapkan pembungkus di sekitar kerangka HTTP dari pustaka standar karena kami tidak ingin bergantung pada implementasi HTTP dari pustaka standar. Semua kode untuk pemetaan ke / dari XML ditulis "dengan tangan", sekali lagi untuk alasan yang sama.

Ini kegilaan . Bahkan jika Anda tidak ingin menggunakan fungsi pustaka standar untuk alasan apa pun, pustaka sumber terbuka ada dengan lisensi yang kompatibel secara komersial yang melakukan semua hal di atas. Mereka sudah ditulis, diuji secara luas dari sudut pandang fungsionalitas, keamanan dan desain API, dan digunakan secara luas di banyak proyek lainnya.

Jika yang terburuk terjadi dan proyek itu hilang, atau berhenti dipertahankan, maka Anda tetap memiliki kode untuk membangun perpustakaan, dan Anda menugaskan seseorang untuk memeliharanya. Dan Anda kemungkinan masih dalam posisi yang jauh lebih baik daripada jika Anda menggulirkan sendiri, karena pada kenyataannya Anda akan memiliki kode yang lebih teruji, lebih bersih, dan lebih dapat dikelola.

Dalam skenario yang jauh lebih mungkin bahwa proyek dikelola, dan bug atau exploit ditemukan di perpustakaan itu, Anda akan tahu tentang mereka sehingga dapat melakukan sesuatu tentang hal itu - seperti memutakhirkan ke versi yang lebih baru secara gratis, atau menambal versi Anda dengan perbaikan jika Anda telah mengambil salinan.

berry120
sumber
3
Dan bahkan jika Anda tidak bisa, beralih ke perpustakaan lain masih lebih mudah dan lebih baik daripada menggulir perpustakaan Anda sendiri.
Lightness Races dengan Monica
5
Poin yang sangat baik bahwa hal-hal tingkat rendah mati lebih cepat Itulah inti dari membangun abstraksi.
Lightness Races dengan Monica
"Tingkat API yang lebih tua dan lebih rendah cenderung menjadi usang dan tidak didukung daripada yang lebih baru". Hah? NetSTandards dibangun di atas satu sama lain sejauh yang saya tahu (artinya 2,0 adalah 1,3 + X). Juga Standar hanyalah itu .. standar, bukan implementasi. Tidak masuk akal untuk berbicara tentang standar yang tidak didukung, paling tidak implementasi spesifik dari standar itu di masa depan (tetapi lihat poin sebelumnya mengapa itu juga bukan masalah). Jika pustaka Anda tidak memerlukan apa pun di luar NetStandard 1.3, sama sekali tidak ada alasan untuk mengubahnya menjadi 2.0
Voo
11

Secara keseluruhan, hal-hal ini baik untuk pelanggan Anda. Bahkan perpustakaan open source yang populer mungkin mustahil bagi mereka untuk menggunakan karena suatu alasan.

Misalnya, mereka mungkin telah menandatangani kontrak dengan pelanggan mereka yang berjanji untuk tidak menggunakan produk-produk sumber terbuka.

Namun, seperti yang Anda tunjukkan, fitur-fitur ini bukan tanpa biaya.

  • Saatnya ke pasar
  • Ukuran paket
  • Performa

Saya akan meningkatkan kelemahan ini dan berbicara dengan pelanggan untuk mencari tahu apakah mereka benar-benar membutuhkan tingkat kompatibilitas yang Anda tawarkan.

Jika semua pelanggan sudah menggunakan Json.NET misalnya, kemudian menggunakannya dalam produk Anda dan bukan kode deserialisasi Anda sendiri, kurangi ukurannya dan tingkatkan.

Jika Anda memperkenalkan versi kedua dari produk Anda, yang menggunakan perpustakaan pihak ketiga serta yang kompatibel, Anda bisa menilai penyerapan pada keduanya. Apakah pelanggan akan menggunakan pihak ketiga untuk mendapatkan fitur terbaru sedikit lebih awal, atau tetap menggunakan versi yang 'kompatibel'?

Ewan
sumber
11
Ya saya jelas setuju, dan saya akan menambahkan "keamanan" ke daftar Anda. Ada beberapa potensi yang Anda mungkin memperkenalkan kerentanan dalam kode Anda, terutama dengan hal-hal seperti JSON / JWT, dibandingkan dengan kerangka kerja yang telah diuji dengan baik dan tentunya perpustakaan standar.
Bertus
Ya, sulit untuk membuat daftar karena jelas hal-hal seperti keamanan dan kinerja dapat berjalan dua arah. Tetapi ada konflik kepentingan yang jelas antara fitur finishing dan mengasuransikan komponen internal yang sepenuhnya ditampilkan / dipahami
Ewan
12
"mereka mungkin telah menandatangani kontrak dengan pelanggan mereka yang berjanji untuk tidak menggunakan produk-produk open source" - mereka menggunakan .NET Standard, yang merupakan open source. Merupakan ide yang buruk untuk menandatangani kontrak itu ketika Anda mendasarkan seluruh produk Anda pada kerangka kerja open source.
Stephen
Dan orang masih melakukannya
Ewan
7

Jawaban singkatnya adalah Anda harus mulai memperkenalkan dependensi pihak ketiga. Selama pertemuan Anda berikutnya, beri tahu semua orang bahwa minggu depan di tempat kerja akan menjadi yang paling menyenangkan selama bertahun-tahun - mereka akan mengganti komponen JSON dan XML dengan sumber terbuka, solusi perpustakaan standar. Beri tahu semua orang bahwa mereka memiliki tiga hari untuk mengganti komponen JSON. Rayakan setelah selesai. Berpesta. Ini layak dirayakan.

Double Vision Stout Fat Heavy
sumber
2
Ini mungkin lidah di pipi tetapi itu tidak realistis. Saya bergabung dengan sebuah perusahaan di mana seorang dev "senior" (senior hanya dengan pendidikan) menugaskan seorang dev junior dengan menulis perpustakaan mesin negara. Itu memiliki lima pengembang-bulan di dalamnya dan itu masih buggy, jadi saya merobeknya dan menggantinya dengan solusi turnkey dalam beberapa hari.
No U
0

Pada dasarnya itu semua bermuara pada upaya vs risiko.

Dengan menambahkan ketergantungan tambahan atau memperbarui kerangka kerja Anda atau menggunakan API tingkat lebih tinggi, Anda menurunkan upaya Anda tetapi Anda mengambil risiko. Jadi saya sarankan melakukan analisis SWOT .

  • Kekuatan: Lebih sedikit usaha, karena Anda tidak harus membuat kode sendiri.
  • Kelemahan: Ini tidak seperti yang dirancang khusus untuk kebutuhan khusus Anda sebagai solusi buatan tangan.
  • Peluang: Waktu ke pasar lebih kecil. Anda mungkin mendapat untung dari perkembangan eksternal.
  • Ancaman: Anda mungkin mengecewakan pelanggan dengan ketergantungan tambahan.

Seperti yang Anda lihat upaya tambahan untuk mengembangkan solusi kerajinan tangan adalah investasi untuk menurunkan ancaman Anda. Sekarang Anda dapat membuat keputusan strategis.

Dominic Hofer
sumber
-2

Pisahkan pustaka komponen Anda menjadi set "Core", yang tidak memiliki dependensi (pada dasarnya apa yang Anda lakukan sekarang) dan set "Common", yang memiliki dependensi pada pustaka "Core" dan pihak ketiga Anda.

Dengan begitu jika seseorang hanya menginginkan fungsionalitas "Core", mereka dapat memilikinya.

Jika seseorang menginginkan fungsionalitas "Umum", mereka dapat memilikinya.

Dan Anda dapat mengatur apa itu "Core" versus "Common". Anda dapat menambahkan fungsionalitas dengan lebih cepat ke "Umum", dan memindahkannya ke implementasi "Inti" Anda sendiri jika / ketika masuk akal untuk menyediakan implementasi Anda sendiri.

Turtle1363
sumber