Seri Swift Package Manager 01｜Posisi dan pentingnya SPM

Pertama kali banyak pengembang iOS bersentuhan dengan Swift Package Manager sering kali karena mereka “ingin menghubungkan perpustakaan pihak ketiga”. Sangat mudah untuk menarik kesimpulan yang terlalu sempit:

Bukankah SPM hanyalah pengganti CocoaPods?

Kesimpulan ini hanya sebagian yang benar.

SPM tentu saja dapat menginstal dependensi, tetapi jika Anda hanya memahaminya sebagai pengelola dependensi, Anda akan meremehkan apa yang sebenarnya berubah. Yang berubah sebenarnya adalah cara proyek Swift mendefinisikan modul, cara mereka mengatur dependensi, dan cara mereka menetapkan batasan proyek.

Jadi dalam artikel ini saya ingin memperjelas premisnya terlebih dahulu: **Nilai SPM bukan sekedar “mendapatkan kode dengan lebih nyaman”, tetapi “mengatur kode dengan lebih standar”. **

1. SPM pertama-tama adalah pintu masuk sistem modul resmi Swift, bukan hanya pengunduh.

Nilai inti dari banyak alat berasal dari ekologi, dan nilai inti dari beberapa alat berasal dari “apakah itu jalur resmi”.

SPM lebih dekat dengan yang terakhir.

Pentingnya hal ini pertama-tama berasal dari tiga fakta:

• Ini adalah solusi manajemen paket dan modularisasi yang didukung secara resmi oleh Swift
• Terintegrasi dengan arah evolusi kompiler, rantai alat, dan Xcode
• Ini tidak hanya mengelola kode pihak ketiga, tetapi juga secara alami mendukung pengelolaan kode Anda sendiri

Ketiga poin ini jika digabungkan berarti bahwa bahasa ini secara bertahap menjadi bahasa default untuk organisasi teknik Swift.

Ini bukan perubahan sebesar “satu perintah lagi untuk menginstal dependensi”.

2. Yang sebenarnya dihadapi adalah masalah “batas”.

Apa yang benar-benar sulit untuk dikelola dalam proyek yang matang adalah selalu masalah-masalah berikut:

• Kode mana yang harus dipisahkan menjadi modul
• Kemampuan apa yang harus diandalkan secara langsung oleh proyek tuan rumah?
• Modul mana yang bisa saling mereferensikan dan mana yang tidak boleh direferensikan
• Dimana batas antara kemampuan publik dan kemampuan bisnis?

Ketika SPM memasuki proyek, isu-isu ini menjadi lebih spesifik. Karena tidak lagi sekedar “membagi direktori ke dalam folder”, tetapi sebenarnya mendefinisikan:

• Apa antarmuka publik suatu modul?
• Tergantung pada modul mana
• Siapa yang mengandalkannya
• Bagaimana cara mengujinya

Oleh karena itu, saya katakan inti dari SPM adalah memaksa kita untuk berpikir lebih serius tentang batasan modul.

Alasan semakin pentingnya

Banyak proyek kecil yang dapat bertahan dengan baik dengan “satu target Aplikasi + sekelompok grup” di awal. Namun begitu proyek mencapai skala menengah, masalah akan mulai muncul:

• Kecepatan kompilasi semakin lambat
• Kemampuan publik dan kode bisnis digabungkan
• Arah ketergantungan modul tidak terkontrol
• Perubahan akan memicu kompilasi ulang sejumlah besar kode yang tidak relevan
• Sulit membedakan kode mana yang benar-benar dapat digunakan kembali

Saat ini, Anda akan menemukan bahwa masalahnya adalah “batas proyek tidak ada”.

SPM menjadi semakin penting karena menyediakan jalur yang lebih standar daripada “terus menumpuk direktori di proyek utama”. Hal ini memungkinkan batasan modul berubah dari konvensi menjadi struktur teknik nyata.

4. Perbedaan terbesar antara SPM dan alat ketergantungan zaman dulu bukan hanya pada pengalamannya, tetapi positioning perannya

Di masa lalu, ekspektasi sederhana terhadap alat manajemen ketergantungan adalah hal yang umum:

• Bantu saya menginstal perpustakaan pihak ketiga
• Bantu saya dengan versi dan integrasi

Namun SPM akan segera membawanya ke level lain: Ia tidak hanya mengelola “perpustakaan yang ditulis oleh orang lain”, tetapi juga sangat cocok untuk mengelola “modul yang diambil sendiri”.

Perubahan ini sangat penting. Karena begitu Anda mulai mengatur kode Anda ke dalam Paket, peran SPM berubah dari “installer” menjadi “sistem modul”.

Saat ini, permasalahan yang menjadi perhatian bukan lagi sekedar:

• Apakah bisa dipasang?

Sebaliknya:

• Cara mendefinisikan antarmuka modul
• Cara menyembunyikan implementasi internal
• Bagaimana menjaga ketergantungan satu arah
• Modul mana yang layak diuji secara independen

Di sinilah kematangan teknik mulai meningkat.

5. Cepat atau lambat banyak tim yang akan mencapai SPM

Di permukaan sepertinya sudah “diperbarui”, namun kenyataannya lebih mirip dengan cara proyek Swift modern diatur.

Selama sebuah tim mulai melakukan hal-hal ini dengan serius, tentu saja mereka akan semakin dekat dengan SPM:

• Ingin melakukan pemisahan modul yang lebih jelas
• Ingin mengekstraksi kemampuan publik
• Ingin mengurangi perluasan proyek utama yang berlebihan
• Ingin membuat dependensi menjadi eksplisit
• Ingin membuat pengujian modul lebih natural

Dengan kata lain, dalam proses mengejar batasan teknik, banyak tim akhirnya menemukan bahwa SPM adalah cara paling nyaman untuk melaksanakan tugas.

6. Namun nilainya bukan pada “menjadi maju saat digunakan”, tetapi pada “batas-batasnya akhirnya dapat ditentukan dengan serius”

Kesalahpahaman lain harus dihindari di sini: Ketika topik SPM disebutkan, mudah untuk menyamakannya dengan “tim matang modular”.

Hal ini sebenarnya tidak akurat.

SPM dengan sendirinya tidak serta merta menghasilkan struktur yang baik. Jika Anda belum memikirkannya dengan jelas:

• Mengapa modul ini ada?
• Apa yang diekspos dan apa yang tidak
• Apa hubungannya dengan proyek tuan rumah?

Itu baru saja memindahkan kekacauan asli dari direktori proyek utama ke direktori Paket.

Oleh karena itu, nilai SPM bukan terletak pada “menjadikannya modern”, namun menjadikan banyak permasalahan batasan yang tadinya tidak jelas akhirnya tidak bisa lagi menjadi kabur.

7. Ini tidak akan menyelesaikan apa pun secara otomatis

Ini juga penting. SPM tidak secara otomatis membantu menyelesaikan:

• Apakah pembongkaran modul masuk akal?
• Apakah penamaannya jelas?
• Ketergantungan pada apakah arahnya sehat
• Apakah modul publik tertentu dibuat terlalu dini?
• Apakah lapisan bisnis dan lapisan dasar tercampur menjadi satu?

Meskipun demikian, SPM bukanlah seorang arsitek, ini hanya sebuah alat yang lebih cocok untuk menampung arsitektur yang baik.

Jika tim tidak memiliki kesadaran akan batasan sejak awal, SPM mungkin hanya akan mengemas masalah dengan cara yang lebih “modern”.

8. Kesimpulan: SPM menjadi semakin penting. Di permukaan, tampaknya ia dapat menginstal perpustakaan, namun sebenarnya lebih dekat dengannya dan lebih cocok untuk menghosting proyek modular.

Singkatnya, saya akan mengatakan:

Alasan mengapa SPM menjadi semakin penting adalah karena tampaknya hal ini akhirnya memungkinkan kita untuk mengurangi satu CocoaPods. Faktanya, ini lebih memudahkan proyek Swift untuk mengubah batasan modul, dependensi, dan struktur proyek menjadi desain eksplisit.

Jadi yang terpenting bukanlah sekadar “manajemen ketergantungan”, namun:

• Modular
• Standardisasi
• Buat batasan secara eksplisit

Inilah sebabnya mengapa hal ini semakin layak untuk ditanggapi dengan serius.