Flutter — Membangun Proyek Boilerplate yang sempurna dari awal. Bagian 2: Titik nyeri

Kredit: Nguyễn Thành Minh (Pengembang Android)

Melalui artikel ini, saya akan menyampaikan kepada Anda 5 poin rasa sakit yang saya alami selama menjadi pengembang seluler. Saya telah membentuk beberapa kriteria yang kita butuhkan dalam arsitektur. Terakhir, saya juga akan menceritakan kisah tentang bagaimana Arsitektur Bersih membantu saya memecahkan masalah tersebut.

1. Lima poin rasa sakit di masa lalu

1.1. Keputusan sulit pemimpin

Sumber: Unsplash

Titik sakit dari setiap pemimpin atau arsitek berasal dari keharusan membuat keputusan.

Pemimpin harus memutuskan framework, library, database, dan teknologi mana yang harus digunakan proyek ini. Keputusan yang terburu-buru atau kurangnya visi akan menyebabkan konsekuensi yang tidak terduga dalam proses pengembangan perangkat lunak. Jadi sebagai pemimpin proyek, saya selalu mencari arsitektur untuk membantu saya menunda pengambilan keputusan selama mungkin tetapi tetap memastikan tim tidak perlu menunggu saya untuk berpikir, tim saya tetap terdepan. Meskipun tim desain belum menggambar layar apa pun, tim kami masih dapat melakukan logika terlebih dahulu dan menulis Tes Unit secara normal.

1.2. Selama pemeliharaan proyek, memperbaiki 1 bug akan menghasilkan 10 bug baru

Sumber: Unsplash

Ini tidak biasa bagi pengembang ketika mereka harus memperbaiki atau memperbaiki bug dalam proyek dengan "arsitektur yang sangat lengket". Kelas dan fungsi sangat erat kaitannya satu sama lain sehingga hanya memperbaiki satu fungsi kecil sudah cukup untuk meledakkan keseluruhan proyek. Dalam beberapa skenario, setelah memperbaiki 1 bug, penguji akan menemukan 10 bug lagi, oleh karena itu, perlu waktu berbulan-bulan hanya untuk memperbaiki 1 bug. Ini membuat biaya pemeliharaan proyek menjadi sangat tinggi, jadi kami membutuhkan arsitektur yang membantu memisahkan dependensi sebanyak mungkin. Sehingga setiap kali kami mengedit kelas atau fungsi, seluruh sistem tidak akan terpengaruh, dan Anda tidak perlu memperbaiki kodenya secara manual.

1.3. Poin rasa sakit pengembang FE bisa berasal dari pengembang BE

Pengembang FE yang kode kelas Modelnya didasarkan pada Respons API yang ditentukan oleh pengembang BE akan memiliki 4 risiko:

1. Jika BE dirancang dengan buruk, FE juga akan terpengaruh, kodenya sangat sulit dipetakan dengan UI, membutuhkan banyak perhitungan untuk dipetakan dengan UI. Seperti gambar di atas, Json Response ada di sebelah kanan, di model Booking ada model Room; dan pada model Room, ada model Booking, yang terus berulang tanpa henti.
2. FE harus beradaptasi dengan BE, tetapi kelas Model diimpor ke banyak kelas seperti UI dan Bloc. Memperbaikinya akan menyebabkan modifikasi massal pada kelas yang bergantung padanya.
3. Dua pengembang BE dalam satu tim dapat memiliki dua gaya pengkodean yang berbeda, sehingga mereka dapat mengembalikan UserDatarespons yang sangat berbeda bergantung pada API. Misalnya, di fetchUsersAPI, mereka mengembalikan agebidang type int?, tetapi di fetchUserDetailAPI, mereka mengembalikannya type String?. Bagaimana jika saya mendeklarasikan bidang usia tipe int?? Aplikasi saya akan mogok saat memanggil fetchUserDetailAPI. Jadi, kita harus mendeklarasikan agebidang tipe dynamicmeskipun tipe ini dianggap tidak aman karena dapat dengan mudah menyebabkan kesalahan runtime. Kasus ini sangat umum terjadi saat bekerja sebagai freelancer ketika anggota tim BE belum pernah bekerja satu sama lain sebelumnya, dan tidak ada pemimpin dan tidak ada yang mengulas kode.
4. Demi keamanan, semua bidang dalam kelas Model Data harus selalu berupa tipe nullable seperti int?, String?. Namun, ini dapat menyebabkan risiko aplikasi kami mogok karena NullPointerException.

1.4. Buat aplikasi seluler dan aplikasi TV di satu repositori

Sebelumnya, saya berpartisipasi dalam proyek untuk mengembangkan aplikasi seluler dan aplikasi TV seperti Youtube. Saat itu, saya harus membuat 2 modul aplikasi: mobile_app, dan tv_app. Perlu disebutkan di sini bahwa kedua modul ini menggunakan API permintaan yang sama seperti fetchVideos, fetchVideoDetail. Jadi, untuk menggunakan kembali kode permintaan API untuk kedua modul, kita perlu mendesain arsitektur sehingga bagian API dipisahkan menjadi modul lain untuk dimasukkan ke dalam dua modul aplikasi tersebut.

1.5. Kisah Kura-kura dan Kelinci dan Kekeliruan Klasik Pengembang

Melihat dua grafik statistik di atas. Pengembang dapat melihatnya seperti biasa, karena ini adalah sesuatu yang sering kami temui. Tapi bagi manajer, mereka pasti akan khawatir. Mereka ingin membelanjakan lebih banyak uang untuk menghasilkan pendapatan yang lebih tinggi dan produktivitas yang lebih tinggi setelah setiap rilis, tetapi hidup tidaklah sempurna. Faktanya, proyek hanya membutuhkan 20% dari total biaya untuk membuat 80% fitur utama dari sebuah perangkat lunak. Namun, dalam rilis berikutnya, menambahkan beberapa fitur sedikit demi sedikit dapat menghabiskan banyak biaya, dalam beberapa kasus bahkan dapat menyebabkan insiden dengan konsekuensi yang sangat serius. Arsitektur tentu memainkan peran besar dalam penyebab masalah ini.

Mari kita mengingat kembali pelajaran tentang Kelinci dan Kura-kura yang kita pelajari di masa kecil. Kita dapat melakukan tiga pelajaran untuk diri kita sendiri:

• Lambat dan mantap memenangkan perlombaan
• Kemenangan tidak bergantung pada seberapa kuat atau cepat Anda
• Semakin tergesa-gesa, semakin sedikit kecepatannya

Kekeliruan umum pengembang adalah "Batas waktu proyek akan datang, buat kode apa pun yang Anda inginkan, lalu refactor nanti". Berpikir seperti ini akan membawa dua masalah besar:

1. Tidak ada waktu untuk refactoring. Secara pribadi, saya juga pernah mengalami dan juga menyaksikan banyak pengembang lain menghabiskan waktu luang mereka di akhir pekan untuk memperbaiki fitur-fitur baru yang dirilis di sprint terakhir. Ini adalah kebiasaan kerja yang tidak sehat.
2. Tidak ada jaminan bahwa refactor akan berfungsi dan tidak membuat lebih banyak bug.

Kesimpulannya, ini adalah 5 poin rasa sakit yang saya temui selama saya menjadi pengembang seluler. Di bagian terakhir, saya akan mengungkapkan: Bagaimana Arsitektur Bersih membantu saya mengatasi masalah-masalah ini.