Swift Package Manager Seri 02｜Buat Paket Swift pertama

Banyak tutorial yang membahas tentang “membuat Paket Swift pertama Anda” berfokus pada perintah atau tindakan Xcode.

Tentu saja langkah-langkah tersebut perlu diketahui. Namun jika Anda hanya mengetahui cara mengklik “Paket Baru”, Anda sebenarnya baru belajar “menghasilkan template”, dan Anda belum benar-benar memahami pentingnya rekayasa pembuatan Paket.

Karena ini pertama kalinya saya membuat Paket Swift sendiri, yang sebenarnya mulai berubah adalah cara berpikir saya:

• Apakah kode ini layak dipisahkan menjadi sebuah modul? -Antarmuka apa yang harus diekspos modul ini?
• Detail implementasi mana yang harus disembunyikan
• Bergantung pada siapa dan siapa yang harus diandalkan?

Jadi yang ingin saya bahas di artikel ini adalah penilaian apa yang harus diambil saat membuat Paket untuk pertama kalinya.

1. Jangan terburu-buru membuat Paket terlebih dahulu. Pertama tanyakan apakah kode ini harus tetap ada di proyek utama.

Ini adalah langkah yang paling saya pedulikan.

Situasi yang umum adalah mengatakan: “Mari kita memodulasinya.” Namun yang patut ditanyakan adalah:

Mengapa kode ini harus dipisahkan dari konteks proyek saat ini dan menjadi modul independen?

Alasan umum yang sah meliputi:

• Ini akan digunakan kembali oleh beberapa target atau beberapa modul bisnis
• Telah terbentuk kemampuan lapangan yang relatif stabil
• Seharusnya tidak lagi bergantung pada halaman atau detail proyek host
• Ini layak mendapatkan batasan pengujian terpisah

Jika Anda tidak dapat menyebutkan salah satu alasan ini dan hanya “merasa ada terlalu banyak file”, mungkin ini belum waktunya untuk membuat paket.

Paket tidak digunakan untuk menyimpan file, ini digunakan untuk menyatakan batasan.

2. Yang paling cocok untuk diekstraksi pertama kali biasanya adalah kemampuan kecil dengan batasan yang jelas.

Jika sebuah tim baru mengenal SPM, saya biasanya tidak menyarankan untuk menghancurkannya sebagai langkah pertama:

• Seluruh halaman beranda
• Seluruh sistem akun
• Seluruh modul pembayaran

Karena modul-modul ini sering kali sangat digabungkan dengan proyek host, lapisan halaman, lapisan perutean, dan lapisan status, jika batasannya tidak dirancang dengan jelas, pemisahan pertama akan mudah dilakukan.

Paket yang lebih cocok untuk Paket batch pertama biasanya memiliki kemampuan berikut:

-Kemampuan dasar lapisan jaringan

• Pencatatan, pemantauan, dan pengemasan titik tersembunyi
• Alat pemrosesan gambar atau cache
• Perpustakaan model domain yang jelas
• Satu set komponen dasar UI yang relatif stabil

Fitur umum dari modul ini adalah:

• Mengurangi ketergantungan
• Tanggung jawab tunggal
• Batasannya relatif jelas

Mereka lebih cocok untuk membantu tim membangun pemahaman tentang “apa itu modul independen”.

3. Saat pertama kali membuat Paket, hal yang paling penting adalah antarmuka publik

Situasi yang umum terjadi adalah setelah membangun Paket pertama, Anda akan segera fokus pada cara mengatur direktori. Namun dari sudut pandang teknik, yang lebih penting adalah:

• Apa yang dipaparkan modul kepada dunia luar?
• Apa yang disimpan di dalam modul

Anda dapat menganggap membuat Paket sebagai pengendalian diri:

• Tipe mana yang benar-benar layak diekspos sebagai public
• Fungsi utilitas mana yang seharusnya hanya bersifat internal
• Dependensi mana yang tidak boleh diketahui pemanggil

Jika Anda hanya memindahkan semua yang ada di proyek utama asli ke dalam satu Paket lalu mengubahnya menjadi public, maka itu tidak akan benar-benar membentuk batas.

Oleh karena itu, saat membuat Paket untuk pertama kalinya, praktik yang paling bermanfaat adalah “mendefinisikan antarmuka”.

4. Salah satu kesalahpahaman paling umum: Bangun paketnya terlebih dahulu, lalu pikirkan tanggung jawab modul

Sangat mudah untuk salah dengan urutan ini.

Urutan yang benar biasanya adalah:

1. Perjelas dulu tanggung jawab kemampuan ini
2. Mari kita lihat apakah modul ini layak dijadikan modul independen.
3. Terakhir host dalam bentuk Paket

Jika urutannya dibalik, akibat yang umum adalah:

• Paket A ingin mengurus semuanya
• Kebingungan ketergantungan internal
• Antarmuka eksternal terlalu besar
• Proyek tuan rumah masih perlu mengetahui banyak detail implementasi

Dengan kata lain SPM tidak bisa melakukan perancangan modul untuk tim, hanya lebih cocok untuk membawa modul yang sudah dipikirkan dengan matang.

5. Empat masalah yang paling saya pedulikan saat membuat Paket untuk pertama kalinya

Jika saya mereview paket pertama sebuah tim, empat pertanyaan yang paling sering saya tanyakan adalah:

1. Apakah modul ini mempunyai tanggung jawab tunggal yang jelas?

Jika sebuah modul menangani jaringan, cache, status halaman, dan titik terkubur pada saat yang bersamaan, mungkin hal tersebut belum jelas.

2. Apakah dependensinya cukup sedikit

Saat pertama kali membuat Paket, semakin sedikit ketergantungannya, semakin mudah keberhasilannya. Ketika terdapat terlalu banyak ketergantungan, batasan menjadi kabur.

3. Apakah antarmuka publiknya jauh lebih kecil dibandingkan implementasi internalnya?

Jika ada sepuluh tipe dalam modul, delapan di antaranya akan diekspos, yang menunjukkan bahwa kontrol batas kurang baik.

4. Apakah layak dilakukan pengujian independen?

Modul yang layak untuk diuji secara independen biasanya lebih layak untuk keberadaannya secara independen. Jika Anda tidak tahu cara mengujinya secara terpisah, mungkin itu masih terlalu terikat dengan konteks host.

6. Kriteria keberhasilan pertama kali adalah “pembongkaran stabil”

Ketika banyak tim melakukan modularisasi untuk pertama kalinya, kemungkinan besar mereka akan mengejar “rasa hasil”, seperti:

• Hapus 10 modul sekaligus
• Semua kode publik masuk ke dalam Paket
• Proyek utama kehilangan banyak bobot dengan segera

Namun dalam proyek nyata, kriteria kesuksesan pertama yang lebih penting biasanya adalah:

• Memiliki modul dengan batasan yang jelas
• Ketergantungan eksternal itu sehat
• Tim mengerti kenapa dipecah seperti ini
• Itu tidak kembali dengan cepat dalam beberapa iterasi berikutnya

Karena ketakutan terbesar terhadap modularitas adalah kepercayaan semua orang terhadap masalah ini akan hilang pada langkah pertama.

7. Kesimpulan: Paket Swift pertama benar-benar mengajarkan cara mengatur kode berdasarkan batasan.

Singkatnya, saya akan mengatakan:

Arti sebenarnya dari pembuatan Paket Swift pertama adalah dipaksa untuk menjawab dengan serius untuk pertama kalinya “mengapa kode ini layak menjadi modul yang berdiri sendiri”.

Begitu Anda mulai melihat masalah dari perspektif ini, SPM tidak lagi hanya “dapatkah saya menggunakannya”, tetapi mulai benar-benar memasuki pintu masuk pemikiran teknik modular.