Swift Package Manager Series 07｜Metode manajemen SPM dalam proyek iOS berukuran sedang

Jika saya menggunakan SPM untuk mengelola proyek iOS berukuran sedang, perhatian pertama saya bukanlah “berapa banyak paket yang harus dihapus”, tetapi tiga pertanyaan berikut:

• Kemampuan apa yang benar-benar layak untuk mandiri?
• Bagaimana mempertahankan arah ketergantungan modul yang stabil
• Apa yang harus dipertahankan dalam proyek utama dan apa yang tidak boleh dipertahankan?

Karena proyek berukuran menengah kemungkinan besar akan terjebak: Tampaknya modularisasi telah dimulai, namun nyatanya ini hanyalah redistribusi kompleksitas proyek utama asli ke beberapa paket.

Jadi yang ingin saya bahas di artikel ini adalah bagaimana saya menilai modul, hierarki, dan grafik ketergantungan.

1. Saya tidak akan mengejar “modul lebih banyak” dari awal, tetapi akan mengejar “level yang jelas” terlebih dahulu

Kompleksitas proyek berukuran sedang biasanya tidak cukup besar sehingga memerlukan subdivisi yang ekstrem, namun cukup membuat “semua dalam proyek utama” mulai menjadi berbahaya.

Yang terpenting saat ini adalah menghilangkan layering tersebut terlebih dahulu.

Saya biasanya pertama kali melihat apakah kategori hal berikut dapat dipisahkan secara stabil ke dalam proyek:

• Lapisan kemampuan dasar
• Lapisan kemampuan domain
• Lapisan penggunaan kembali UI
• Lapisan proyek host

Setelah keempat jenis hal ini digabungkan, proyek akan mudah lepas kendali begitu skalanya meningkat. Namun jika hierarki ditetapkan terlebih dahulu, jumlah modul akan dirinci kemudian.

2. Pertama-tama saya akan membagi modul inti menjadi tiga kategori.

1. Modul kemampuan dasar

Misalnya:

• jaringan
• Catatan
• tembolok
• Pembacaan konfigurasi
• Alat dasar

Ciri-ciri modul jenis ini adalah jauh dari bisnis, memiliki kemampuan digunakan kembali yang kuat, dan arah ketergantungan harus ditutup semaksimal mungkin.

2. Modul kemampuan domain

Misalnya:

-Akun

• Pengguna
• Konten
• Pesan

Modul-modul ini adalah pusat kemampuan bisnis. Mereka harus menghosting model domain, gudang, kasus penggunaan, bukan implementasi halaman tertentu.

3. Modul penggunaan kembali UI

Misalnya:

• Sistem desain
• Komponen umum
• Wadah daftar universal

Saya akan sangat berhati-hati di sini untuk menghindari pemisahan halaman bisnis menjadi modul UI secara tidak sengaja. Modul penggunaan kembali UI lebih cocok untuk membawa kemampuan komponen yang stabil, universal, dan lintas halaman.

3. Apa yang harus dipertahankan dalam proyek host?

Ini adalah masalah yang cenderung diabaikan oleh banyak tim.

Begitu Anda mulai melakukan SPM, mudah untuk memiliki kecenderungan: “Karena semuanya modular, sebaiknya proyek induk dibuat setipis mungkin.”

Pernyataan ini hanya setengah benar.

Proyek host seharusnya tidak membawa terlalu banyak kemampuan yang dapat digunakan kembali, namun tetap harus mempertahankan beberapa hal yang secara alami menjadi milik host, seperti:

• Orkestrasi siklus hidup aplikasi
• Perakitan perutean
• Injeksi konfigurasi lingkungan
• Perakitan modul
• Kode yang berhubungan dengan bentuk produk akhir

Dengan kata lain, proyek tuan rumah harus fokus pada perakitan dan kolaborasi tingkat produk, daripada membawa banyak kemampuan yang bisa saja ditenggelamkan.

4. Saya tidak akan membongkarnya terlalu halus di awal.

Ini adalah sesuatu yang sangat saya tekankan.

Salah satu kendala yang paling mungkin dihadapi oleh proyek-proyek skala menengah adalah “modularisasi demi modularitas”, yang pada akhirnya terlalu merusak sistem.

Jika modul terlalu terfragmentasi, masalah akan segera muncul:

• Grafik ketergantungan yang kompleks
• Jalur debugging menjadi lebih panjang
• Sering melompati modul selama peninjauan
• Sedikit perubahan melibatkan beberapa keterkaitan paket

Hal ini dapat dengan cepat membuat tim meragukan modularitas itu sendiri.

Jadi saya lebih suka:

• Pertama bongkar beberapa modul besar dengan tanggung jawab yang jelas
• amati beberapa iterasi
• Putuskan apakah akan menyempurnakannya

Memilih sistem dengan sangat halus pada kali pertama biasanya dilakukan dengan tergesa-gesa.

5. Arah ketergantungan lebih penting daripada jumlah modul

Jika saya diminta untuk memilih antara “menghapus lebih banyak modul” dan “meluruskan ketergantungan”, saya pasti akan memilih yang terakhir.

Karena lebih banyak modul tidak secara otomatis berarti struktur yang lebih baik. Yang benar-benar menentukan apakah sistem dapat berkembang secara stabil dalam jangka panjang adalah apakah arah ketergantungannya jelas.

Misalnya, saya lebih peduli apakah hubungan ini bertahan:

-Lapisan dasar tidak bergantung pada lapisan bisnis

• Lapisan domain tidak bergantung pada lapisan host secara terbalik
• Lapisan penggunaan kembali UI tidak mencuri semantik bisnis halaman
• Lapisan host bertanggung jawab atas perakitan, bukan memegang seluruh implementasi internal di tangannya

Selama arah ketergantungannya kacau dan tidak peduli berapa banyak modul yang ada, sistem hanya akan menjadi “kopling bersarang berlapis-lapis”.

6. Saya akan sangat waspada terhadap “modul publik universal”

Ini adalah anti-pola yang sering muncul di proyek berukuran sedang.

Ketika sebuah proyek dimodulasi pada awalnya, sering kali muncul pertanyaan yang disebut:

• Common
• Shared
• Core
• Base

Modul super seperti ini.

Jika modul ini mengusung kemampuan dasar yang jelas, maka tidak ada masalah. Namun “modul publik” di banyak proyek pada akhirnya akan menjadi:

• Bisa diandalkan dimana saja
• Taruh semuanya di sana
• Ada fungsi alat, model bisnis, dan komponen UI

Hasilnya adalah titik penghubung pusat yang baru.

Jadi saya lebih suka membaginya menjadi modul-modul dasar kecil dengan tanggung jawab yang jelas, daripada membangun modul publik besar yang mencakup semuanya.

7. Hal terpenting untuk modularisasi proyek skala menengah adalah kognisi tim yang konsisten.

Ini sangat realistis.

Dalam proyek-proyek berukuran sedang, banyak masalah struktural disebabkan oleh kurangnya pemahaman yang konsisten tentang batas-batas tim. Misalnya, beberapa orang berpikir:

• Segala sesuatu yang berhubungan dengan halaman dianggap sebagai modul

Beberapa orang berpikir:

• Model domain harus dibongkar secara terpisah

Beberapa orang berpikir:

• Komponen publik harus ditempatkan bersama dengan modul bisnis untuk kenyamanan lebih

Jika kognisi ini tidak disatukan dalam jangka waktu yang lama, konflik batas dalam sistem akan terus berkembang bahkan dengan SPM.

Jadi dalam proyek skala menengah, saya akan sangat mementingkan:

• Apakah penamaan tanggung jawab modul konsisten?
• Apakah ada konsensus mengenai arah ketergantungan?
• Saat menambahkan kode baru, dapatkah Anda mengetahui di lapisan mana kode tersebut harus ditempatkan?

Ini jauh lebih penting dari sekadar “berapa banyak paket yang dibuka”.

8. Kesimpulan: Inti dari penggunaan SPM untuk mengelola proyek skala menengah bukanlah kuantitasnya, tetapi stabilitas grafik ketergantungan dalam jangka panjang.

Singkatnya, saya akan mengatakan:

Saat menggunakan SPM untuk mengelola proyek iOS berukuran sedang, hal terpenting adalah membentuk arah ketergantungan stabil jangka panjang antara kemampuan dasar, kemampuan domain, penggunaan kembali UI, dan perakitan host.

Dengan melakukan ini, jumlah modul secara alami akan menemukan ukuran yang tepat. Jika Anda tidak dapat melakukan ini, tidak peduli seberapa banyak Anda membaginya, itu hanya akan mengurangi kerumitannya.