Seri Konkurensi Swift 02｜Masalah diselesaikan dengan async/menunggu

Jika Anda hanya melihat permukaannya, async/await tampaknya memecahkan tiga masalah utama:

• terlalu banyak panggilan balik
• Bersarang terlalu dalam
• Kodenya terlalu jelek

Namun setelah benar-benar menggunakannya dalam proyek untuk jangka waktu tertentu, Anda akan menemukan bahwa ini hanyalah tampilannya saja. Apa yang benar-benar dipecahkan adalah: **Bisnis asinkron akhirnya dapat diatur, diberi alasan, dan digunakan kembali seperti bisnis normal. **

Ini adalah perubahan pemeliharaan teknis.

1. Hal pertama yang diselesaikan adalah: proses bisnis tidak lagi dibajak oleh metode penulisan

Banyak bisnis asynchronous sendiri yang tidak rumit. Yang ribet, cara penulisan yang lama bikin ribet.

Misalnya, proses yang nyata namun umum:

1. Tarik informasi pengguna
2. Periksa status keanggotaan
3. Tarik konten yang direkomendasikan di beranda
4. Jika salah satu langkah gagal, kembali ke tampilan penuh
5. Status halaman terakhir diperbarui

Ini akan menjadi proses berurutan yang sangat jelas.

Namun di era penyelesaian, seringkali kita harus menghadapi “masalah penulisan” ini terlebih dahulu:

• Di mana tertulis cabang sukses?
• Di mana tertulis cabang yang gagal?
• Di mana peralihan thread utama ditulis?
• Lapisan manakah yang bertanggung jawab atas pengembalian lebih awal? -Lapisan manakah yang bertanggung jawab untuk menyatukan kesalahan bom?

Maka kerumitannya bukan lagi datang dari bisnisnya, tapi dari ekspresi itu sendiri. async/await Manfaat paling langsungnya adalah menghilangkan lapisan kebisingan tambahan ini dan mengembalikan kompleksitas bisnis ke bisnis itu sendiri.

2. Ini membuat “ketergantungan” menjadi jelas kembali

Banyak proses asinkron yang sangat bergantung.

Misalnya:

• Hanya setelah mendapatkan status login Anda dapat memperoleh informasi pengguna
• Hanya setelah mendapatkan informasi pengguna Anda dapat memutuskan modul mana yang akan dimuat di beranda.
• Hanya setelah mendapatkan konfigurasi eksperimental Anda dapat memutuskan jalur tampilan halaman

Tentu saja, penyelesaian juga dapat mengungkapkan hubungan-hubungan ini, tetapi masalahnya adalah: sering kali menyembunyikan ketergantungan dalam lapisan-lapisan yang bersarang. Kode dapat berjalan, tetapi rantai ketergantungannya tidak lagi jelas.

Salah satu nilai inti async/await adalah mengembalikan hubungan “siapa bergantung pada siapa” ke aliran kontrol linier:

let session = try await authService.loadSession()
let user = try await userService.loadUser(session: session)
let modules = try await homeService.loadModules(for: user)

Nilai dari kode ini bukan hanya tampilannya saja yang bagus, tapi juga bisa langsung terlihat:

• Hubungan berurutan
• titik istirahat
• Langkah manakah yang mungkin salah?

Hal ini secara langsung akan mempengaruhi kepercayaan diri Anda saat memodifikasi persyaratan nanti, karena Anda akhirnya dapat menentukan di mana bagian yang Anda pindahkan berada di seluruh tautan.

3. Ini secara signifikan meningkatkan penyebaran kesalahan

Dalam model asinkron yang lama, penanganan kesalahan adalah yang paling rapuh.

Karena setiap tingkat penyelesaian mungkin gagal, hal ini sering kali berakhir pada situasi berikut:

• Satu set penanganan kegagalan permintaan tingkat pertama
• Serangkaian perawatan lain untuk kegagalan lapisan kedua
• Jika level ketiga gagal, coba level lainnya.
• Beberapa tempat salah menelannya
• Mainkan roti panggang di beberapa tempat
• Beberapa tempat hanya mencatat

Anda akan menemukan bahwa masalah sebenarnya adalah jalur kesalahan terpecah seperti proses utama.

async/await setidaknya memberikan model propagasi kesalahan terpadu:

• Buang lapisan ini
• Teruslah melempar ke atas
• Tanggung jawab terpadu dari tingkat yang lebih tinggi

Dengan kata lain, hal ini tidak memutuskan “bagaimana menangani kesalahan” bagi tim, namun setidaknya membuat “bagaimana kesalahan mengalir” menjadi jelas kembali. Hal ini sangat penting terutama untuk batasan bisnis.

4. Ini secara eksplisit memperlihatkan titik jeda

Situasi yang umum terjadi adalah mengabaikan arti terpenting dari await: Ini adalah pengingat.

Ini menceritakan:

• Kemungkinan jeda di sini
• Konteksnya di sini mungkin berbeda
• Kode setelah ini tidak boleh berada di lingkungan yang sama persis secara default

Ini adalah kunci untuk berpikir secara bersamaan.

Karena bahaya sebenarnya dari kode asinkron adalah setelah memanggilnya, Anda sering kali secara tidak sadar berpikir:

• Halaman saat ini masih ada
• Status saat ini tidak berubah
• Objek saat ini tetap utuh

Dan await setidaknya dengan jelas menandai “inilah batasnya” secara tata bahasa. Ini akan memaksa Anda untuk mulai berpikir serius tentang validitas status, daripada memperlakukan asinkron sebagai pemanggilan fungsi biasa.

5. Mempermudah memasukkan desain utama daripada logika plug-in.

Di masa lalu, banyak kode juga dapat melakukan pembatalan, namun pembatalan biasanya seperti fungsi mengejar ketinggalan:

• Simpan token secara terpisah
• Ingatlah untuk membatalkan ketika halaman dihancurkan
• Hentikan permintaan lama secara manual dalam beberapa skenario

Bisakah itu dilakukan? Tentu saja bisa. Namun masalahnya pembatalan pada model lama seringkali bukan bagian dari proses utama, melainkan seperti patch eksternal.

Dalam Konkurensi Swift, tugas dan pembatalan pada akhirnya secara alami dipandang sebagai serangkaian hal. Hal ini memaksa beberapa pertanyaan kunci untuk ditanyakan sebelumnya:

• Siapa pemilik tugas ini?
• Haruskah berhenti ketika halamannya tersisa?
• Tugas baru akan datang, haruskah tugas lama menjadi tidak valid?

Hal ini tidak secara otomatis membantu melakukan pembatalan dengan benar, namun hal ini mengedepankan fakta bahwa pembatalan harus dirancang di dalamnya.

6. Ini tidak hanya meningkatkan pengalaman pribadi, tetapi juga konsistensi kolaborasi tim.

Ini adalah situasi umum yang diremehkan.

Saat seseorang menulis kode, perbedaan antara penyelesaian dan async/await mungkin hanya terlihat pada kelancaran. Namun dalam proyek kolaborasi multi-orang, hal yang sangat penting tentang async/await adalah membuat ekspresi tim lebih terpadu.

Sekarang setidaknya mungkin untuk default ke:

• Kemampuan asinkron akan muncul di fungsi async
• Gagal dengan throw
• Gunakan await untuk titik jeda

Penyatuan ini sangat penting. Karena ketakutan terbesar dalam proyek yang kompleks adalah setiap orang menggunakan metode organisasi asinkronnya sendiri. Cepat atau lambat proyek tersebut akan dapat dijalankan, tetapi tidak ada seorang pun yang dapat mengambil alih dengan cepat.

7. Itu tidak menyelesaikan apa pun

Pada titik ini, kami juga harus memperjelas bahwa async/await tidak menyelesaikan masalah berikut:

• Itu tidak secara otomatis menghilangkan kondisi balapan
• Tidak secara otomatis mencegah permintaan lama menimpa hasil baru
• Tidak akan memutuskan untuk tim bagaimana batas status harus ditetapkan
• Tidak secara otomatis memastikan bahwa pembaruan UI terjadi dalam konteks yang benar

Jadi, jika desain asinkron asli suatu proyek sangat berantakan, mungkin akan “terlihat berantakan” setelah diganti dengan async/await.

Hal ini harus dilihat dengan jelas. async/await bukanlah obat mujarab arsitektural, ia hanya menjelaskan banyak masalah yang awalnya ditutupi oleh tulisan.

8. Kesimpulan: Yang dipecahkan adalah “Apakah kode asinkron masih dapat dipertahankan untuk waktu yang lama?”

Singkatnya, saya akan mengatakan:

async/await Solusi sebenarnya adalah kode asinkron menjadi semakin sulit untuk diatur, dipikirkan, dan dipelihara dalam proyek yang kompleks.

Jadi pernyataan yang lebih akurat bukanlah:

“Itu membuat kodenya lebih pendek.”

Sebaliknya:

“Ini membawa kode asinkron kembali ke kondisi struktural untuk pemeliharaan jangka panjang.”