Swift Package Manager Seri 05｜Akses dan manajemen Paket pihak ketiga dalam proyek iOS

Ketika berbicara tentang manajemen ketergantungan pihak ketiga pada isu-isu tersebut, fokusnya lebih ke depan:

• Apakah perpustakaan ini dapat diakses melalui SPM?
• Bisakah Xcode mengenalinya?
• Cara menulis nomor versi

Tentu saja ini penting, namun dalam proyek nyata, biaya sebenarnya sering kali memakan waktu beberapa tahun setelah pemasangan.

Karena begitu ketergantungan pihak ketiga memasuki proyek, hal itu akan menimbulkan serangkaian masalah jangka panjang:

• Cara mengontrol ritme peningkatan
• Modul mana yang akan terpengaruh oleh perubahan API?
• Apakah perpustakaan tertentu terkena langsung ke kode bisnis
• Sekali ingin mengganti perpustakaan, apakah biayanya akan mahal?

Jadi kesulitan sebenarnya dalam “mengelola paket pihak ketiga” adalah tata kelola.

1. Sebelum menerima dependensi pihak ketiga, hal pertama yang ditanyakan adalah “Apakah akan masuk ke batas inti?”

Sebelum perpustakaan ditambahkan ke suatu proyek, hal pertama yang biasanya saya tanyakan bukanlah:

• Ada berapa bintang di sana?
• Apakah dokumennya cantik?

Sebaliknya:

• Apakah akan langsung masuk ke banyak kode bisnis?
• Apakah ini akan menentukan bentuk antarmuka bagi kita di masa mendatang?
• Seberapa besar dampaknya setelah ditingkatkan atau diganti?

Karena beberapa perpustakaan hanya memiliki kemampuan periferal, seperti alat debugging, backend logging, dan gadget satu kali; Beberapa perpustakaan akan langsung masuk ke inti sistem, seperti lapisan jaringan, lapisan gambar, lapisan perutean, dan lapisan penyimpanan.

Jika pilihan terakhir salah, biaya modifikasi selanjutnya akan sangat tinggi.

Jadi saya lebih mementingkan apakah itu masuk ke “lapisan tepi” atau “lapisan tulang punggung”.

2. Jangan biarkan kode bisnis mengetahui secara langsung terlalu banyak detail perpustakaan pihak ketiga

Ini adalah pengalaman yang paling mudah diabaikan, namun merupakan pengalaman yang paling penting.

Asumsikan bahwa pustaka pemuatan gambar digunakan, dan API-nya ada di mana pun dalam proyek:

• Lihat lapisan yang diimpor secara langsung
• ViewModel juga mengetahui tipenya
• Lapisan alat juga bergantung padanya

Maka perpustakaan ini akan segera berubah dari “ketergantungan” menjadi “bagian dari infrastruktur”. Jika Anda ingin mengupgrade atau menggantinya di kemudian hari, biayanya akan jauh lebih tinggi dari yang diharapkan.

Jadi pendekatan yang lebih stabil biasanya:

• Bungkus abstraksi Anda sendiri di sekitar batasan yang sesuai
• Biarkan bisnis mengandalkan kemampuan antarmuka daripada perpustakaan itu sendiri

Ini tidak berarti bahwa perpustakaan pihak ketiga mana pun harus dikemas sepenuhnya, tetapi setidaknya untuk dependensi yang masuk jauh ke dalam lapisan trunk utama, isolasi harus dipertimbangkan secara serius.

3. SPM membuat akses lebih mudah, namun juga dapat dengan mudah membuat “menambahkan ketergantungan” menjadi terlalu sembrono.

Ini adalah efek samping yang sangat nyata.

Karena akses SPM yang begitu mudah, banyak tim yang perlahan-lahan mengembangkan kebiasaan ini:

• Melihat kebutuhan kecil
• Cari perpustakaan
• tambahkan
• Lagipula itu hanya satu paket

Ini sangat efisien dalam jangka pendek, namun masalah jangka panjang secara bertahap akan menumpuk:

• Perluasan ketergantungan
• Rantai kompilasi menjadi lebih panjang
• Beberapa perpustakaan sudah lama tidak dipelihara
• Beberapa fungsi perpustakaan tumpang tindih
• Ada banyak ketergantungan dalam proyek yang “tidak ada yang bisa menjelaskan alasan keberadaannya”

Oleh karena itu, SPM membuat pengelolaan ketergantungan menjadi lebih ringan, namun ringan bukan berarti standar tata kelola harus dilonggarkan. Semakin ringan alatnya, semakin banyak kendali manusia yang dibutuhkan.

4. Inti dari manajemen versi terletak pada apakah strategi peningkatannya jelas

Saat pertama kali mempelajari konten tentang versi SPM ini, pertama-tama saya akan memperhatikan:

• Versi persisnya
• versi cakupan
• upToNextMajor

Aturan-aturan ini perlu diketahui, namun pertanyaan teknik yang lebih penting sebenarnya adalah:

• Siapa yang bertanggung jawab untuk meningkatkan ketergantungan ini?
• Seberapa sering meninjau versi
• Apakah peningkatan harus mengikuti kebutuhan bisnis atau dikelola secara berkala?
• Cara menilai dampak dengan cepat ketika pemutakhiran gagal

Jika tidak ada yang bertanggung jawab atas hal-hal ini, betapapun indahnya batasan versi yang ditulis, itu hanya akan menjadi “nilai tetap yang tidak berubah selama beberapa tahun”.

Jadi mengandalkan manajemen versi pada dasarnya adalah masalah ritme tata kelola.

5. Hal yang paling menakutkan tentang ketergantungan pihak ketiga adalah “tidak ada yang akan melihatnya setelah memasuki sistem”

Semua orang sangat serius dengan banyak ketergantungan pada hari mereka diperkenalkan, tetapi tidak ada yang mengurusnya setelah itu. Hal ini membawa beberapa risiko umum:

• Pembaruan keamanan tertinggal dalam waktu lama
• Simpanan perubahan API meledak menjadi peningkatan
• Tidak ada seorang pun di tim yang mengetahui siapa lagi yang mengandalkan perpustakaan ini
• Pustaka kemampuan serupa terus ditumpangkan

Kemudian proyek secara perlahan akan memasuki keadaan:

• Dependensi bukannya tidak dapat digunakan
• Tapi tidak ada yang berani bergerak

Hal ini lebih umum dan lebih sulit untuk ditangani daripada “memilih perpustakaan yang salah”.

6. Yang lebih saya hargai adalah apakah daftar ketergantungan “dapat dijelaskan”

Daftar ketergantungan proyek yang sehat tidak harus pendek, namun sebaiknya dapat dijelaskan.

Dengan kata lain, saat mengambil ketergantungan, tim dapat dengan jelas menyatakan:

• Masalah apa yang dipecahkannya?
• apakah itu
• Di lantai berapa letaknya
• Apakah ada batas isolasi
• Jika di kemudian hari perlu diganti, berapa biaya utamanya?

Jika ketergantungan telah menjadi:

• “Itu pernah ada sebelumnya”
• “Sepertinya digunakan di suatu tempat”
• “Hapus karena takut terjadi sesuatu”

Kemudian sebenarnya sudah memasuki zona tata kelola yang tidak terkendali.

7. Strategi praktis: perlakukan ketergantungan pihak ketiga secara berlapis

Saya biasanya membagi dependensi menjadi tiga kategori:

1. Ketergantungan marginal

Misalnya, beberapa alat bantu pengembangan, pelaporan log, dan alat frekuensi rendah. Bahkan jika ketergantungan jenis ini digunakan secara lebih langsung, risikonya relatif dapat dikendalikan.

2. Ketergantungan platform

Misalnya gambar, jaringan, penyimpanan, perutean, dll. Jenis ketergantungan ini kemungkinan besar akan memasuki trunk sistem, dan cakupan paparannya harus dikontrol dengan hati-hati.

3. Ketergantungan yang sangat erat dengan kemampuan penggantian yang lemah

Setelah beberapa perpustakaan terhubung, mereka akan mempengaruhi sejumlah besar desain API. Ketergantungan seperti ini memerlukan batasan yang jelas di awal, jika tidak maka biaya penggantiannya akan sangat tinggi di kemudian hari.

Pendekatan berlapis ini lebih realistis daripada “semua menggunakannya secara langsung” atau “satu lapisan mencakup semua”.

8. Kesimpulan: Inti dari Paket pihak ketiga adalah tata kelola jangka panjang

Singkatnya, saya akan mengatakan:

Saat mengelola paket pihak ketiga dalam proyek iOS, yang paling penting adalah “setelah paket tersebut memasuki sistem, dapatkah Anda mengontrol batasannya, ritme peningkatan, dan biaya penggantian?”

Jadi manajemen ketergantungan adalah kemampuan tata kelola jangka panjang.