SwiftUI Seri 15｜Bangun proyek SwiftUI yang dapat dikelola dari awal

Jika saya diminta untuk membangun proyek SwiftUI dari awal, hal pertama yang saya pertimbangkan bukanlah seperti apa direktorinya, dan saya juga tidak mengkhawatirkannya terlebih dahulu:

• Apakah Anda perlu mengirimkan template arsitektur lengkap? -Apakah saya perlu menggambar banyak lapisan dasar terlebih dahulu?

Hal pertama yang saya pikirkan adalah hal-hal ini:

• Bagaimana statusnya mengalir
• Cara mengalihkan tanggung jawab halaman
• Kapan dan sejauh mana komponen dipompa?
• Akankah proyek menjadi sulit untuk dimodifikasi setelah tiga bulan?

Karena banyak proyek SwiftUI yang awalnya cukup ringan, titik balik sebenarnya sering kali terjadi setelah dua atau tiga bulan:

• Semakin banyak halaman
• Keadaan semakin buruk
• Penggunaan kembali komponen menjadi semakin acak
• Mulai susun logika bisnis di View

Jadi yang sebenarnya ingin dipecahkan oleh “pemeliharaan” adalah stabilitas setelah pertumbuhan, bukan kecepatan pengembangan di minggu pertama.

1. Saya tidak akan membangun kerangka yang berat dari awal, tetapi perjelas dulu tanggung jawabnya.

Salah satu kesalahpahaman paling umum ketika memulai sebuah proyek dari awal adalah:

• Bisnis belum dimulai
• Pertama-tama tata letak satu set struktur lengkap yang terlihat lengkap

Hal ini belum tentu salah, namun risikonya adalah:

• abstrak terlalu dini
• Strukturnya tidak sesuai dengan bisnis sebenarnya
• Tim akan terus melewatinya nanti

Jadi saya lebih suka:

• Perjelas dulu batasan tanggung jawabnya
• Tambahkan lapisan secara bertahap seiring meningkatnya kompleksitas

Daripada “menjadi besar dan lengkap di hari pertama”, saya lebih menghargai “menjadi lancar di bulan pertama”.

2. Hal pertama yang biasanya saya pahami adalah tiga lapisan: lapisan halaman, lapisan status, dan lapisan kemampuan.

1. Lapisan halaman

Bertanggung jawab untuk:

• Struktur
• Kombinasi komponen
• Pemetaan status halaman

2. Lapisan status

Bertanggung jawab untuk:

• Status bisnis
• Proses asinkron
• Pergantian status semantik halaman

3. Lapisan kemampuan

Bertanggung jawab untuk:

• jaringan
• Penyimpanan
• Layanan domain
• Komponen umum dan kemampuan penataan

Ketiga lapisan ini belum tentu bisa dibongkar secara halus sejak awal, namun kesadaran harus ada terlebih dahulu. Jika tidak, proyek SwiftUI dapat dengan mudah masuk ke “tulis semuanya langsung di Tampilan”.

3. Saya akan sangat waspada terhadap “pandangan raksasa”

Menulis UI di SwiftUI sangat mudah, jadi salah satu bau tidak sedap yang paling umum adalah:

• Strukturnya ditulis dalam View
• Permintaan ditulis dalam View
• Penilaian status ditulis dalam View
• Perakitan copywriting juga ditulis dalam View

Tentu saja ini terlihat sangat cepat pada tahap awal, tetapi begitu proyek menjadi kompleks, Tampilannya akan segera menjadi:

• Sulit dibaca
• Sulit diubah
• Tidak dapat diprediksi

Masalahnya di sini adalah View mengambil terlalu banyak tanggung jawab non-display.

4. Saya sengaja memperlambat penggunaan kembali komponen daripada melakukannya dengan susah payah di awal.

Banyak tim mudah untuk mengejar “perpustakaan komponen universal” pada awalnya. Namun dalam proyek nyata, mengabstraksi terlalu dini seringkali lebih berbahaya daripada mengabstraksi nanti:

• Antarmuka akan dirancang terlalu lebar
• Banyak opsi disiapkan untuk kemungkinan skenario masa depan
• Komponen terkesan digunakan kembali, namun nyatanya siapapun yang menggunakannya akan merasa tidak nyaman

Jadi saya lebih suka membiarkan komponen berkembang dalam satu atau dua halaman nyata terlebih dahulu, lalu mengekstraknya setelah polanya cukup stabil. Komponen yang diekstraksi dengan cara ini biasanya lebih mendekati kegunaan nyata dibandingkan senam abstrak.

5. Batasan negara biasanya lebih penting daripada struktur direktori

Banyak proyek menghabiskan banyak waktu untuk berdebat di awal:

• Fitur-pertama atau Lapisan-pertama
• Cara membagi folder

Tentu saja ini penting, tapi yang lebih saya pedulikan adalah:

• Status manakah yang dikelola oleh halaman itu sendiri?
• Negara bagian mana yang dikelola oleh objek bisnis eksternal
• Status mana yang sebaiknya dibagikan dan mana yang tidak boleh dibagikan

Karena yang paling menentukan biaya perawatan seringkali adalah apakah statusnya berjalan atau tidak.

6. Inti dari pemeliharaan sebenarnya adalah membiarkan setiap lapisan “menjelaskan dengan jelas apa yang menjadi tanggung jawabnya”

Jika suatu proyek menjadi semakin sulit untuk diubah di kemudian hari, biasanya terdapat tanda-tanda berikut:

• Struktur halaman tidak menunjukkan prioritas
• Atribusi status menjadi semakin kabur
• Batasan komponen menjadi semakin abstrak
• Setelah persyaratan diubah, logika harus dilengkapi di banyak lapisan

Jadi untuk proyek SwiftUI yang dapat dipelihara, yang paling saya hargai biasanya adalah:

• Halaman dapat dibaca sekilas
• Status dapat dibedakan secara sekilas
• Batasan komponen bersifat alami -Logika bisnis tidak ditumpuk di View

Keempat hal ini sangat sederhana, namun sangat berharga dalam jangka panjang.

7. Kesimpulan: Saat membangun proyek SwiftUI dari awal, yang benar-benar perlu diatur dengan benar terlebih dahulu adalah batasannya, bukan templatenya.

Singkatnya, saya akan mengatakan:

Untuk membangun proyek SwiftUI yang dapat dikelola dari awal, hal terpenting adalah menetapkan batasan negara bagian, tanggung jawab halaman, dan abstraksi komponen dengan benar.

Ketika batas-batas ini ditetapkan, proyek akan berkembang lebih lama dan lebih stabil; Jika batasan tidak ditetapkan, betapapun canggihnya template tersebut, hal tersebut dapat dengan mudah tersapu oleh bisnis nyata.