Swift Package Manager Seri 06｜Skenario yang berlaku dan batasan SPM

Setelah konsensus tercapai dalam komunitas teknis, masalah lain akan muncul dengan mudah: Semua orang mulai default pada “karena arahnya benar, maka kita harus berusaha sekuat tenaga secepat mungkin.”

Sangat mudah bagi SPM untuk mengikuti ritme ini juga.

Ini memang merupakan alat yang sangat penting untuk proyek Swift modern, namun “penting” tidak berarti “harus dipromosikan sepenuhnya segera setiap saat.” Hanya karena alatnya canggih, bukan berarti proyek saat ini sudah mempunyai batasan dan kondisi organisasi untuk melaksanakannya.

Jadi saya tidak pernah menyukai kesimpulan umum seperti itu:

• “Saatnya memindahkan semuanya ke SPM”
• “Jika tidak menggunakan SPM, Anda akan tertinggal.”

Pertanyaan yang lebih praktis adalah:

Apakah proyek saat ini cocok untuk memigrasikan kemampuan tertentu ke SPM, dan apakah proyek tersebut akan lebih stabil setelah migrasi selesai.

1. Syarat layak menjadi SPM adalah sudah mulai jelas batasannya.

Jika proyek saat ini berada dalam kondisi ini:

• Semua kode sangat digabungkan dalam satu target Aplikasi
• Halaman, layanan, perutean, dan konfigurasi dapat saling menembus
• Batasan antara kemampuan publik dan kemampuan bisnis masih membingungkan

Jika Anda terburu-buru ke SPM saat ini, Anda mungkin hanya akan memindahkan kopling yang ada secara utuh ke dalam beberapa paket.

Kelihatannya modular di permukaan, namun kenyataannya ketergantungan lebih sulit untuk dipahami dan lebih sulit untuk diubah.

Jadi urutan yang saya sukai adalah:

1. Biarkan batasannya menjadi jelas terlebih dahulu
2. Gunakan kembali SPM untuk menampung batasan-batasan ini

Daripada sebaliknya, SPM diharapkan secara otomatis membantu menciptakan batasan.

2. Kapan waktu terbaik untuk mulai menggunakan SPM?

Saya biasanya mempertimbangkan tanda-tanda berikut bahwa suatu proyek siap memperkenalkan atau memperluas SPM:

• Terdapat modul kapabilitas publik yang jelas dan dapat mandiri
• Tim sudah mulai merasakan batasan, bukan hanya membagi kode berdasarkan direktori
• Kemampuan tertentu memerlukan pengujian independen dan evolusi independen
• Proyek utama mengeluarkan biaya pemeliharaan yang signifikan karena perluasan
• Tim bersedia menanggung biaya desain tambahan untuk batasan modul

Jika kondisi tersebut muncul secara bertahap, seringkali SPM menjadi langkah alami berikutnya.

3. Kapan waktu yang tidak tepat untuk “memaksa diri sendiri”?

Yang dimaksud dengan “penguatan” di sini adalah memajukan SPM sebagai misi politik.

Saya akan sangat berhati-hati dalam situasi berikut:

1. Proyek ini masih sangat kecil, dan kendala utamanya bukanlah batasan modul sama sekali.

Jika proyek saat ini hanya memiliki sedikit orang, berskala kecil, dan memiliki batasan yang relatif sederhana, masalah utamanya mungkin tidak bersifat modular sama sekali.

Memperkenalkan sejumlah Paket terlalu dini pada saat ini mungkin membawa kompleksitas yang lebih besar dibandingkan manfaatnya.

2. Tim tidak memiliki konsensus dasar mengenai batasan.

Jika Anda terhubung sekarang:

• Bagaimana membedakan lapisan dasar dan lapisan bisnis
• Bagaimana membedakan lapisan halaman dan lapisan layanan
• Bagaimana membedakan modul publik dan modul host

Jika belum ada konsensus, SPM hanya akan mengungkap perselisihan tersebut terlebih dahulu, namun mungkin tidak menyelesaikannya.

3. Sekadar untuk “terlihat canggih”

Ini adalah jenis motivasi yang paling berbahaya. Jika alasan penerapan SPM hanya:

• Semua orang menggunakannya
• Diagram arsitektur akan terlihat lebih baik
• Tampilan resume yang lebih modern

Ada kemungkinan besar bahwa pada akhirnya akan menjadi “bentuk yang ditingkatkan, struktur yang tidak berubah”.

4. Aspek SPM yang paling mudah dilebih-lebihkan: berpikir bahwa SPM secara otomatis akan menghasilkan arsitektur yang baik

Itu tidak akan terjadi.

Kelebihan SPM adalah:

• Batasan modul hosting
• Ketergantungan eksplisit
• Jadikan evolusi modul lebih alami

Tapi itu tidak akan menjawab tim:

• Modul mana yang layak ada
• Cara mendesain tergantung arahnya
• Apakah lantai umum digambar terlalu dini?
• Haruskah kode bisnis tertentu tidak independen?

Konon, SPM lebih seperti sebuah fondasi yang baik daripada seorang arsitek. Tanpa kesadaran desain, struktur yang rumit akan tetap dibangun meskipun pondasinya diganti.

5. Strategi migrasi lebih penting daripada “harus bermigrasi atau tidak?”

Banyak proyek gagal karena “perubahan undang-undang yang terlalu drastis”.

Strategi migrasi yang lebih stabil biasanya:

• Mulai uji coba modul dengan batasan yang paling jelas terlebih dahulu
• Lakukan sejumlah kecil pemisahan dengan tingkat kepastian tinggi terlebih dahulu
• Jalankan beberapa iterasi untuk memverifikasi ketergantungan dan biaya kolaborasi
• Putuskan apakah akan terus melakukan ekspansi

Daripada muncul begitu saja:

• Pembongkaran gudang penuh
• Semua kode publik dipaksa masuk ke dalam Paket
• Migrasikan semua dependensi pihak ketiga sekaligus

Modularisasi adalah proyek jangka panjang dan tidak cocok untuk kemajuan satu langkah.

6. Kriteria penilaian praktis: setelah menggunakan SPM, apakah proyek akan menjadi lebih jelas atau berbelit-belit?

Jika perubahan dilakukan setelah migrasi:

• Arah ketergantungan lebih jelas -Tanggung jawab modul lebih jelas
• Lebih mudah untuk menilai cakupan dampak selama peninjauan
• Batasan tes lebih alami

Maka migrasi ini kemungkinan besar layak dilakukan.

Jika setelah migrasi selesai:

• Modulnya lebih banyak tetapi tanggung jawabnya tidak jelas
• Proyek tuan rumah masih mengetahui banyak implementasi internal
• Mengubah suatu fungsi memerlukan bolak-balik melintasi beberapa paket

Artinya, masalahnya bukan pada alatnya, melainkan pada desain batas itu sendiri.

7. Kesimpulan: SPM layak digunakan, namun tidak layak digunakan sebagai migrasi formalis

Singkatnya, saya akan mengatakan:

Kapan menggunakan SPM, kuncinya bukanlah “apakah arahnya benar”, namun “apakah proyek dan tim saat ini siap menggunakan batasan modul untuk membawa kompleksitas.”

Jadi pendekatan yang benar-benar stabil adalah:

• Gunakan pada waktu yang tepat
• Mulailah dengan batasan yang sesuai
• Digunakan untuk membawa struktur yang telah dipikirkan dengan jelas

Dengan cara ini, SPM akan menjadi alat pengurangan beban dan bukan beban rekayasa yang baru.