Fakta lucu, saya pikir saya sudah menulis posting ini, tetapi ketika saya ingin merujuknya, saya menemukan bahwa saya tidak. dalam posting ini, saya ingin menggambarkan pendekatan saya ketika memilih ketergantungan. saya akan terlebih dahulu mendefinisikan apa yang saya maksud dengan ketergantungan dalam konteks posting ini. Apa itu ketergantungan? Sebuah ketergantungan secara harfiah adalah sesuatu yang tergantung pada perangkat lunak Anda: infrastruktur seperti sistem file atau database, jaringan, dll Dalam konteks posting ini, bagaimanapun, saya ingin mempersempit lingkup ke ketergantungan perangkat lunak yang perlu Anda kompilasi / menjalankan, Perangkat lunak yang berbeda memiliki nama yang berbeda untuk perpustakaan ini: I. yang 
 
 
 
 
 
 
 Ruby menyebutnya sebagai perhiasan Rust memanggilnya Cate Python dan Node.js menyebutnya paket yang disebut sebagai modul Maven/Gradle menyebutnya ketergantungan, oleh karena itu nama yang saya gunakan dalam judul dan sebagainya. Perhatikan bahwa industri telah pindah ke arsitektur berbasis layanan untuk alasan pendapatan murni. seseorang dapat mengakses layanan melalui REST API atau sesuatu yang lain. Membeli vs. Membeli Ketika Anda membutuhkan perangkat lunak baru, kebiasaan biasa adalah untuk membangunnya vs. untuk membelinya-Component Off The Shelf. Alasan yang sama dapat diterapkan dengan ketergantungan baru, dengan satu opsi tambahan utama: Open Source. Berikut adalah kontribusi sederhana saya, dari pengalaman pribadi. Dalam proyek-proyek saya, saya sangat konservatif tentang visibilitas. saya mencoba untuk menjaga akses eksternal hingga minimum. Sebisa mungkin, termasuk di konstruktor. Namun, Anda tidak dapat menggunakan konstruktor pribadi dalam tes. Oleh karena itu, saya memperluas visibilitas ke paket-protected, tetapi saya ingin cara untuk mendokumentasikannya. private Di masa lalu, saya menggunakan komentar reguler sampai seorang kolega menunjuk ke Guava. Saya menjadi penggemar besar dengan segera.Tetapi, saya tidak akan membawa ketergantungan untuk Jika itu adalah satu-satunya anotasi yang saya miliki untuk Guava, maka saya lebih suka membuat saya sendiri. Pengujian visual @VisibleForTesting Jika saya membutuhkan kelas lain dari Guava, bagaimanapun, saya akan menilai kembali keputusan saya. , peta dengan mungkin beberapa nilai yang disimpan di bawah kunci, membutuhkan waktu yang lebih lama untuk dikembangkan. Saya mungkin akan menambahkan ketergantungan. Multimedia Multimap Seperti yang Anda lihat, keputusan itu cukup kontekstual. Di sisa posting ini, kita akan mengasumsikan bahwa memilih untuk membangun bukanlah solusi terbaik, dan kita perlu memilih ketergantungan dari apa yang ada. Manajemen Risiko Memilih ketergantungan adalah risiko, dan seperti dengan setiap risiko, Anda harus menerapkan : Teknik Manajemen Risiko 
 
 
 
 
 Identifikasi risiko: di bagian berikutnya, saya akan daftar beberapa item yang dapat Anda pertimbangkan. Analisis setiap risiko. Pertimbangkan probabilitas dan dampaknya. Organisasi berbeda. Satu menganggap dampak risiko tertentu sebagai rendah dalam konteks mereka, tetapi yang lain menganggapnya sebagai tinggi. Untuk setiap risiko, dokumentasikan tindakan mitigasi dan biaya yang terkait Bahkan dalam konteks ketergantungan, risiko baru dapat muncul, misalnya, CVE kritis baru.Selain itu, risiko dapat meningkatkan probabilitasnya, misalnya, seorang komisioner inti meninggalkan proyek, dan mengurangi faktor bus ke tingkat kritis.Mungkin sudah waktunya untuk mendedikasikan karyawan penuh waktu untuk pemeliharaan proyek? Kriteria Pilihan yang Saya menulis adalah fondasi di mana saya akan membangun. Blur Lisensi dan Aspek Hukum Saya percaya ini adalah aspek yang paling penting sejauh ini. Anda perlu melihat lisensi. GitHub membuatnya mudah untuk memverifikasi: pertama, itu mendorong proyek untuk memiliki file; kemudian, menampilkan dengan jelas di bagian atas jika itu adalah salah satu lisensi Open Source yang diakui. LICENSE Anda harus memastikan bahwa Anda memahami lisensi. , itu cukup mudah: orang lain sudah melakukan pekerjaan untuk Anda. untuk jenis lain, itu bisa lebih sulit. Beberapa ketergantungan dirilis di bawah lisensi ganda: satu Open Source dan satu komersial. Sebagian besar waktu, Anda dapat mengasumsikan lisensi Open Source cukup restriktif dan akan membutuhkan yang komersial. Lisensi yang disetujui OSI harga Ada tiga model harga (yang saya ketahui): 
 
 
 
 harga tetap Harga variabel berdasarkan beberapa faktor (faktor), misalnya, jumlah CPU, jumlah pengguna, dll. Kombinasi dari yang di atas Lisensi bisa untuk waktu yang terbatas atau untuk selamanya. Saran terbaik saya adalah untuk menuliskan persyaratan Anda, lingkup Anda, dan anggaran Anda. kemudian, Anda mungkin harus delegasi pembelian ke departemen pembelian Anda: mereka adalah pro dan adalah yang terbaik untuk negosiasi. Pemerintahan Proyek komersial dikelola oleh perusahaan. Manfaat utama dari proyek yang dikelola oleh perusahaan adalah dukungan keuangan. Ini bisa menjadi masalah jika proyek tidak mengembalikan pendapatan yang diharapkan. Manfaat lain mungkin termasuk keterampilan profesional untuk leverage serta dukungan (lihat link:# di bawah). Open Source menyediakan beberapa alternatif mengenai pemerintahan: sebuah yayasan, sebuah komunitas pengembang, atau satu saja. yayasan adalah bentuk pemerintahan yang paling stabil, mirip dengan perusahaan. , yang Dan yang Beroperasi di bawah model yang sangat berbeda. Yayasan Apache Yayasan Eclipse Yayasan Linux Yayasan Apache dibangun pada merit individu dari orang-orang yang bekerja pada proyek. mereka menyediakan infrastruktur (SCM, email, membangun infrastruktur, dll.), tetapi Anda sendiri di luar itu. , bagian dari Linux Foundation, dibangun pada perusahaan. sebuah perusahaan menjadi bagian dari CNCF dengan membayar kontribusi. cnnf Semakin besar kelompok yang mengatur proyek, semakin memakan waktu untuk mempengaruhi. pengaruh bisa sama besarnya dengan mendorong roadmap ke arah yang Anda inginkan, dan sama kecilnya dengan mendapatkan bug yang diperbaiki, atau bahkan mendapatkan penyelesaian Anda sendiri. Berinteraksi dengan pengembang akan lebih mudah bagi orang-orang yang berpikiran teknis. dalam hal apapun, mengharapkan untuk memainkan politik untuk memajukan tujuan Anda, meskipun dengan kebijakan yang berbeda tergantung pada badan penguasa. Maturitas Menambahkan ketergantungan adalah kompromi: Anda menghemat waktu, tetapi Anda kehilangan kendali.Jika Anda membangun perangkat lunak Anda pada proyek yang tidak dipertahankan, Anda harus memindahkan kode Anda untuk mengurangi ketergantungan atau untuk mempertahankannya sendiri. Berikut adalah beberapa titik data untuk mengevaluasi kesuburan proyek: 
 
 
 
 
 Kapan proyek ini dibuat? proyek-proyek yang lebih tua menghasilkan lebih banyak kepercayaan. Apa sejarah rilisnya? Semakin teratur frekuensi rilisnya, semakin baik. Apakah proyek mengumumkan roadmapnya? jika ya, seberapa detailnya? roadmap yang kabur, atau tidak sama sekali, mengkhianati kurangnya visi; yang terlalu rinci, terutama di masa depan yang jauh, bisa menjadi tanda kurangnya kelincahan atau realisme. Untuk proyek komersial, apakah ada sesuatu seperti dukungan jangka panjang? Aktivitas Untuk proyek open source, Anda harus memeriksa aktivitas mereka. Sebuah proyek mungkin telah sangat aktif di masa lalu, tetapi kehilangan drive di sepanjang jalan. 
 
 
 
 Berapa banyak masalah yang terbuka? berapa waktu median untuk memecahkan masalah? apa status resolusi yang paling umum? apa masalah yang paling panjang yang terbuka? menjawab ini harus memberi Anda petunjuk tentang kesehatan keseluruhan proyek. Berapa banyak akun yang berkomitmen untuk proyek? Berapa banyak akun yang secara teratur melakukannya, yaitu, berapa banyak komitator inti mereka? dengan kata lain, apa faktor Bus? Semakin tinggi faktor bus, semakin besar kemungkinan bahwa proyek akan berlanjut jika satu komitator berhenti. Berkaitan dengan yang di atas, apa sejarah komitmen komite utama? Apakah komite tersebar di antara beberapa proyek yang tidak terkait, atau apakah mereka berfokus pada yang Anda ketahui? Dukungan Dukungan mencakup dukungan komersial dan dukungan komunitas. Untuk sebagian besar organisasi yang matang, dukungan komersial adalah persyaratan. ketergantungan komersial memberikan dukungan semacam itu karena sifatnya. Untuk proyek open source, dukungan berkisar dari tidak ada hingga perusahaan yang memberikan dukungan pada proyek sebagai bagian dari bisnis inti mereka. dan Memberikan dukungan untuk diselenggarakan oleh Yayasan Apache. Tomitribe pahlawan Mesin Tomcat Servlet Dukungan dari komunitas gratis, tetapi juga upaya terbaik. tidak ada jaminan seseorang akan menjawab permintaan Anda, dan jika mereka melakukannya, kapan. , GitHub, Slack, Grup Google, dll, dan periksa: yang g. 
 
 
 
 Jumlah orang yang menjawab Jangka waktu antara jawaban dan pertanyaan Kualitas jawaban Pengalaman pengembang Pengalaman pengembang, juga dikenal sebagai DX, adalah salah satu faktor kunci yang membedakan antara proyek yang baik dan yang hebat. dan kelompok konten ke dalam kelompok-kelompok berikut: tutorial, panduan bagaimana, panduan referensi, dan penjelasan. Sistem Divio Sebagian besar proyek menyediakan dokumentasi referensi yang komprehensif. beberapa menawarkan awal yang cepat. inisiatif DevRel pertama saya pada proyek baru umumnya adalah untuk membuat (atau membuat orang lain membuat) satu ketika hilang. Komponen lain dari DX berasal dari menggunakan ketergantungan itu sendiri. Saya akan merekomendasikan prototipe dalam proyek kecil dengan kotak waktu, menggunakan ketergantungan yang disediakan. Ini akan memberi Anda perasaan yang baik untuk Pengalaman Pengembang. Jika Anda berinvestasi banyak, masuk akal untuk prototipe beberapa ketergantungan bersaing secara paralel. Adopsi pasar dan ekosistem Saya telah menyebutkan di atas bahwa memilih ketergantungan adalah manajemen risiko. Karena kita adalah hewan sosial, kita dapat mempercayai orang-orang yang telah memilih ketergantungan sebelum kita untuk membuat keputusan yang benar. Ergo, semakin banyak organisasi yang menggunakan ketergantungan, semakin besar kemungkinan itu adalah pilihan yang tepat. Namun, hati-hati dengan sindrom mentalitas kawanan: Saya melihat banyak organisasi yang melakukan itu dan memilih sesuatu yang orang lain telah memeriksa dalam konteks yang sama sekali berbeda. Batuk, microservice, batuk. Saya juga akan merekomendasikan untuk memeriksa ekosistem di sekitar, jika itu berlaku. ketergantungan pemindaian CSV jelas tidak memenuhi syarat, tetapi membaca / menulis LDAP. apa penyedia LDAP yang mendukung? apakah kompatibel dengan Azure Directory, dll.? Akhirnya, periksa apakah satu atau lebih anggota tim sudah akrab dengan ketergantungan. Miscellany Saya tidak pernah menggunakan salah satu kriteria berikut; saya tidak akan mengembangkan. 
 
 
 
 
 
 
 Manajemen Kerentanan dan Waktu Tanggapan Kesehatan ketergantungan dan frekuensi update Kebijakan Keamanan Publik Benchmark publik dan metrik kinerja Contoh skala dunia nyata Stabilitas perusahaan dan transparansi keuangan Pendekatan Dalam posting ini, saya telah menyertakan beberapa kriteria yang dapat Anda gunakan untuk mengevaluasi ketergantungan. Awalnya dipublikasikan di A Java Geek pada 2 November, 2025 Menggunakan Java Geek

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Audio ini diproduksi dalam bahasa asli cerita!

Cara Memilih Ketergantungan: Membangun vs Beli, Manajemen Risiko, dan Lebih

About Author

KOMENTAR

HANG TAG

ARTIKEL INI DISAJIKAN PADA

Related Stories

PROMISES FULFILLED.

NIGHT (continued)

How to biohack your intelligence — with everything from sex to modafinil to MDMA

19 things I learnt reading the NodeJSdocs

PROMISES FULFILLED.

NIGHT (continued)

How to biohack your intelligence — with everything from sex to modafinil to MDMA

19 things I learnt reading the NodeJSdocs

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps