Swift Package Manager Seri 04｜Batasan kode cocok untuk disertakan dalam Paket

Salah satu kesalahan paling umum yang dilakukan banyak tim saat pertama kali melakukan modularisasi adalah:

Pertama-tama putuskan untuk menghapus modul, lalu pikirkan mengapa modul itu ada.

Jadi hasil akhirnya biasanya “menyalin kopling asli ke lebih banyak direktori”. Di permukaan, ada lebih banyak modul, namun kenyataannya ketergantungannya tidak berubah, dan bahkan lebih membingungkan.

Jadi yang ingin saya bahas di artikel ini adalah: kode seperti apa yang cocok untuk dimasukkan ke dalam Package, dan kesalahan penilaian struktural apa yang paling umum terjadi saat pemisahan.

1. Untuk menentukan apakah harus dipecah, jangan lihat dulu jumlah filenya, tapi lihat dulu apakah batasannya memang ada.

Apakah suatu modul layak untuk diambil tergantung pada apakah modul tersebut memiliki batasan alami.

Yang disebut batas alam biasanya tercermin dalam:

• Ini mengasumsikan serangkaian tanggung jawab yang relatif tunggal
• Arah ketergantungannya relatif jelas
• Tidak perlu mengetahui banyak tentang konteks proyek tuan rumah
• Kemungkinan akan digunakan kembali dalam berbagai skenario di masa depan

Jika kondisi tersebut tidak terpenuhi, hanya karena “folder ini agak besar sekarang”, maka kemungkinan besar akan dipisahkan hanya untuk melanjutkan penggandengan di tempat lain.

Prinsip modularitas yang pertama adalah “batasnya sudah ada, saya jelaskan saja”.

2. Yang paling tidak cocok untuk dihapus pada batch pertama sering kali merupakan blok bisnis besar yang sangat terkait dengan halaman tersebut.

Ketika saya pertama kali melakukan ini, ketika saya melakukan modularisasi, hal-hal yang paling ingin saya bongkar adalah:

• Halaman beranda
• Pusat Akun
• Proses pembayaran
• Detail konten

Tentu saja modul-modul ini penting, namun sering kali juga sangat erat kaitannya dengan hal-hal berikut:

• Perutean Siklus hidup Aplikasi -Host
• Status halaman
• kubur intinya
• Sumber daya UI

Jika Anda memulai dari tempat-tempat ini untuk perpecahan pertama, batas-batasnya tidak akan jelas, dan mudah terlihat:

• Modul itu sendiri juga harus bergantung pada host secara terbalik
• Untuk berbagi sesuatu, beberapa paket saling mereferensikan
• Lapisan publik tercemar oleh lapisan bisnis

Oleh karena itu, yang lebih cocok untuk dibongkar pertama kali biasanya adalah “blok dengan batas paling jelas”.

3. Kode yang cocok untuk dimasukkan ke dalam Paket biasanya memiliki tiga bentuk umum:

1. Modul kemampuan dasar

Misalnya:

• Catatan
• Enkapsulasi jaringan
• cache lokal
• Pembacaan konfigurasi

Fitur umum dari kemampuan ini adalah tanggung jawab yang jelas, independensi halaman, dan ruang penggunaan kembali yang besar.

2. Model domain atau modul layanan domain

Misalnya:

• Model pengguna dan permintaan informasi pengguna
• Objek domain konten dan gudang konten
• Logika bidang pesanan

Modul jenis ini lebih berorientasi bisnis, tetapi selama batasannya jelas, modul ini juga cocok untuk pengembangan paket.

3. Modul komponen dasar UI yang stabil

Misalnya:

• Merancang komponen dasar sistem
• Sistem gaya universal
• Beberapa komponen interaktif tanpa penggabungan bisnis

Premisnya adalah mereka benar-benar stabil dan tidak mencuri semantik khusus halaman.

4. Kesalahpahaman yang sangat umum: pemisahan berdasarkan direktori, bukan berdasarkan arah ketergantungan

Banyak tim gagal dalam modularisasi. Di permukaan sepertinya pembongkarannya terlalu sedikit, namun nyatanya lebih mendekati cara pembongkaran yang salah.

Pertanyaan yang paling umum adalah: Cara membagi folder yang dulu sekarang adalah cara membagi modul.

Misalnya:

• Home/
• User/
• Common/
• Utils/

Di permukaan tampak seperti modul, namun nyatanya Anda akan segera menemukan:

• Home bergantung pada User
• User bergantung pada Common
• Common sebenarnya berisi sekumpulan logika bisnis yang tercampur
• Utils Pada akhirnya, itu menjadi tempat sampah dengan semua yang ada di dalamnya.

Ini menunjukkan bahwa yang dipecah adalah direktorinya, bukan batasnya.

Metode pembongkaran yang benar-benar lebih stabil harus dilihat dari arah ketergantungan:

• Modul mana yang hanya bisa diandalkan kebawah
• Kemampuan apa yang mendasari publik
• Apa saja lapisan area bisnisnya?
• Manakah yang eksklusif untuk lapisan host?

Hanya ketika arah ketergantungan sudah jelas terlebih dahulu, pemisahan modul akan stabil dalam jangka panjang.

5. Jangan sembunyikan dependensi untuk modularitas

Ketika beberapa proyek membongkar modul, untuk menghindari ketergantungan melingkar, mereka mulai menggunakan berbagai metode kompromi:

• Modul publik ekstra besar
• Buatlah perjanjian di mana-mana
• Letakkan “lapisan penghubung” di tengahnya

Teknik-teknik ini bukan tidak mungkin untuk digunakan, tetapi jika teknik tersebut hanya untuk “membuat diagram modul terlihat bagus”, akan lebih mudah untuk menyembunyikan sambungan sebenarnya daripada menyelesaikannya.

Jadi yang lebih saya pedulikan adalah:

• Apakah hubungan ketergantungan saat ini masuk akal secara bisnis
• Apakah modul dipisahkan karena tanggung jawab nyata yang berbeda?
• Atau hanya untuk menghindari keterbatasan alat?

Modularitas yang benar-benar sehat adalah ketika kopling ditempatkan dengan jelas pada arah yang benar.

6. Penilaian praktis: Jika modul ini dihilangkan, apakah proyek tuan rumah masih akan memahaminya?

Ini adalah cara yang sangat umum untuk menilai diri sendiri.

Jika Anda mengeluarkan modul kandidat, tanyakan pada diri Anda:

• Apakah pemahaman proyek tuan rumah masih jelas?
• Apakah penelepon eksternal hanya perlu mengetahui antarmuka tanpa mengetahui banyak detail internal? -Apakah masih konsep lengkap setelah keluar dari pembawa acara

Jika jawabannya “ya”, maka biasanya lebih cocok sebagai Paket. Jika jawabannya “tidak”, mungkin itu masih berupa sekumpulan detail implementasi di dalam host.

7. Saat pertama kali membongkar, lebih baik membongkar lebih sedikit daripada membongkarnya menjadi beberapa bagian.

Saat melakukan modularisasi untuk pertama kalinya, kita akan mudah terjerumus ke dalam dorongan “Sekarang kita sudah mulai membongkarnya, mari kita bongkar lagi.” Namun salah satu kegagalan paling umum dalam proyek skala menengah adalah modulnya terlalu terfragmentasi.

Jika modul terlalu terfragmentasi, biaya akan meningkat dengan cepat:

• Grafik ketergantungan lebih kompleks
• Hubungan kompilasi lebih sulit dipahami
• Manajemen versi dan batas lebih merepotkan
• Saat meninjau, Anda harus bolak-balik melintasi banyak modul

Jadi saat pertama kali berpisah, saya lebih suka:

• Pertama hapus beberapa modul dengan batasan yang jelas
• amati beberapa iterasi
• Putuskan apakah akan melanjutkan penyempurnaan

Ketakutan terbesar terhadap modularitas adalah bahwa langkah pertama adalah memecah sistem menjadi beberapa bagian kecil yang tampak independen namun sebenarnya saling terkait satu sama lain.

8. Kesimpulan: Yang cocok untuk dimasukkan ke dalam Paket adalah “kemampuan dengan batasan yang jelas”

Singkatnya, saya akan mengatakan:

Kunci untuk menilai apakah sebuah kode cocok untuk disertakan dalam sebuah Paket bukanlah berapa banyak file yang dimilikinya, namun apakah kode tersebut memiliki batasan tanggung jawab yang relatif jelas, arah ketergantungan, dan semantik independen.

Jadi yang penting adalah:

• membongkar
• Menurut batasan apa?
• Apakah arah ketergantungan lebih jelas setelah pembongkaran?

Hanya jika ketiga hal ini ditetapkan terlebih dahulu, modularisasi benar-benar dapat mengurangi kompleksitas, daripada mengatur ulang kompleksitas.