Saya telah bekerja sebagai pengembang iOS selama lebih dari enam tahun. Saya kebetulan bekerja di beberapa perusahaan dan tim yang berbeda. Saya bekerja baik dalam outsourcing dan outstaff, saya bahkan memiliki kesempatan untuk berpartisipasi dalam startup. Dan sekarang, setelah beberapa tahun pengembangan komersial, serta beberapa tahun pemrograman di universitas, saya mulai memilih beberapa prinsip atau aturan untuk pendekatan kualitatif untuk pengembangan aplikasi. Awalnya itu saran untuk teman saya. Memberinya nasihat, saya pikir saya tidak memiliki nasihat seperti itu ketika saya baru memulai jalur pengembangan saya. Apa yang bisa saya katakan, beberapa saat saya baru sadar untuk diri saya sendiri, dan beberapa sudah di tempat kerja yang baru. Maka muncul ide untuk membuat daftar kiat yang ingin saya bagikan kepada diri saya lima hingga enam tahun yang lalu. Saya yakin bahwa dalam lima tahun lagi saya akan mengatakan sesuatu kepada diri saya hari ini. Tapi kita mungkin akan meninggalkan ini untuk masa depan.
Kode Anda buruk
Dan hal pertama yang ingin saya katakan pada diri saya seperti sebelumnya adalah: "Kode Anda buruk!". Pada orang biasa, "govnokod". Dan kolega asing saya di bengkel pengembangan memiliki "kode monyet".
Tidak, ini bukan yang Anda pikirkan. Saya tidak ingin menekankan bahwa saya dulu pembuat kode yang buruk, dan sekarang kode saya sempurna. Saya ingin mengulangi pesan ini dan menyampaikan tiga poin utama dalam arti saran ini.
"Kodemu dulu dan akan buruk!"Saat pertama: tidak ada kode yang sempurna, tidak ada yang meletakkan arsitektur yang ideal dan tidak ada kode seperti itu di mana tidak akan ada bug. Saya pikir banyak yang berpikir bahwa mereka tidak dapat menemukan perpustakaan baru atau teknologi baru. Atau beberapa dari kita telah berusaha keras untuk menulis fitur dengan sempurna, mengikuti semua prinsip OOP, SOLID. Yang pada gilirannya menyebabkan banyak waktu dan kadang-kadang menyebabkan jalan buntu. Kadang-kadang, dalam upaya untuk menulis kode yang sempurna, monster dilahirkan yang membawa daftar pola lengkap yang diketahui pengembang, atau bahkan mungkin lebih.
Dengan frasa saya, saya ingin menyampaikan gagasan bahwa Anda tidak perlu khawatir, khawatir tentang kualitas kode Anda. Tidak mungkin untuk memprediksi semuanya. Dan lebih baik bersantai, menulis lebih mudah, dan seperti yang Anda tahu, daripada menderita dan khawatir dengan sia-sia. Dengan pengalaman, keputusan akan datang sendiri. Kadang-kadang perlu untuk “nagovodnodit”, mereka akan menghadapi masalah yang menyebabkan dan memahami kode shit ini sekali dan untuk semua yang lebih baik untuk tidak melakukan ini.
Momen kedua, yang saya sebutkan sebelumnya, adalah hampir mustahil untuk memprediksi semuanya. Ya, Dengan pengalaman, muncul pemahaman tentang apa yang Anda lakukan dan Anda dapat memprediksi jalur pengembangan proyek. Tapi itu datang dengan pengalaman. Dan jika pengalaman tidak cukup, maka Anda sebaiknya tidak mencoba membuat kode universal. Ada beberapa kasus ketika fitur Anda, yang Anda pikir untuk waktu yang lama dan sangat hati-hati pada awalnya, dan kemudian menulis, dibuang begitu saja dari aplikasi. Juga, ada beberapa kasus ketika aplikasi berubah hanya karena menurut pikiran pelanggan semuanya tampak berbeda. Dan setelah berjam-jam transfer antarmuka dari desain ke kode, 100.500 perubahan tiba-tiba muncul. Ini hanya permulaan, karena setelah pengulangan pertama, semakin banyak suntingan baru akan datang. Dan dalam kasus ketika pengembang tidak memiliki pengalaman yang cukup, proses ini dapat mengambil tidak hanya banyak waktu tetapi juga membawa bukan sensasi yang paling menyenangkan yang ditunda oleh pikiran tidak menyenangkan di suatu tempat di sudut-sudut rahasia pikiran, mengubah proses pengembangan dari pelajaran yang menyenangkan menjadi sakit neraka. Karena itu, jagalah saraf Anda dan jangan cocok dengan yang ideal. Terkadang Anda bisa berbicara sedikit.
Poin ketiga: ini lagi-lagi murni momen psikologis, yaitu kritik dari pengembang lain. Seperti semua orang tahu, semua pengembang dalam negeri mempertimbangkan kode lain - kode kotoran. Bahkan jika dia menunjukkan kode sendiri, yang tidak dikenali, dia cenderung menyebutnya omong kosong. Seringkali kritik semacam itu disertai oleh kepuasan moral dari kritik itu sendiri. Seperti dicatat oleh pengembang berpengalaman, itu adalah orang-orang yang paling sering memanggil kode orang lain govnodkod persis mereka yang pada satu waktu novnokovodil lebih dari. Dan semakin keras seseorang berteriak "govnokod", semakin banyak "kue" yang ditinggalkannya di jalannya.
Selain itu, setiap gadis yang mengingat dirinya masih muda harus mengakui bahwa ia telah menjadi novocode yang terkenal.
Oleh karena itu, saya menyarankan Anda untuk menggunakan ungkapan "Kode Anda dulu dan akan menjadi omong kosong", sebagai perisai dari kritik yang tidak selalu membangun. Saya juga ingin mencatat bahwa kode Anda akan selalu sial karena pengembangan tidak berhenti. Setiap tahun kualitas kode Anda hanya meningkat. Jadi kode saat ini pada akhirnya akan berubah menjadi govnokod.
Bagilah dan taklukkan
Saya tidak ingin sepertinya saya hanya menyarankan govnokod, oleh karena itu saya akan mulai memberikan saran tentang cara menghindari kode yang buruk itu. Dan saya ingin memulai dengan prinsip yang telah saya sisihkan untuk diri saya sendiri. Tidak, ini bukan warisan atau polimorfisme, dan bukan salah satu dari prinsip SOLID. Saya menyebut prinsip ini Divide and Conquer.
Ya, ada yang namanya dekomposisi.
Dekomposisi - pembagian keseluruhan menjadi beberapa bagian. Juga, dekomposisi adalah metode ilmiah yang menggunakan struktur masalah dan memungkinkan Anda untuk mengganti solusi dari satu masalah besar dengan serangkaian tugas yang lebih kecil, meskipun saling terkait, tetapi lebih sederhana.
Seperti kata Wikipedia. Tetapi ini hanya sebagian dari apa yang saya masukkan dalam makna prinsip saya. Jelas ya, Anda perlu membagi proyek dan tugas menjadi bagian-bagian yang lebih kecil. Tapi maksud saya pendekatan konseptual untuk pemisahan kelompok-kelompok logis dalam proyek.
Dan hal pertama yang saya rujuk pada prinsip ini adalah pemisahan antarmuka pengguna DAN logika bisnis dari aplikasi tersebut. Tampaknya saya sekarang adalah kapten langsung bukti. Tapi! Dalam praktiknya, batasan-batasan ini sering kabur dan ternyata ViewController atau Activity berisi sepotong logika bisnis.
Saya pikir contoh layar "Login" akan sederhana dan dapat dimengerti. Di sini pengembang mulai mengimplementasikan arsitektur MVC. Tampaknya ada View terpisah, seperti Controller with Model juga menambahkan, sebagaimana mestinya. Tetapi pada titik tertentu mereka berpikir: "Mengapa saya perlu menambahkan beberapa kelas untuk layar dengan satu tombol?" dan pada saat ini saya sangat merekomendasikan untuk meninggalkan pikiran-pikiran jahat seperti itu dan secara ketat berpegang pada prinsip "Divide and Conquer" untuk memisahkan UI dan logika bisnis. Dan bahkan jika arsitektur mengharuskan Anda untuk menambahkan kelas ViewModel, yang akan memiliki satu dua baris kode, Anda harus melakukannya. Karena sering ada kasus ketika layar di mana awalnya ada satu tombol, seiring waktu, tumbuh menjadi kesulitan yang tidak terpikirkan. Jika Anda mengikuti pemisahan komponen logis sebelumnya, maka ini akan sangat memudahkan kehidupan di masa depan.
Anda khususnya dapat merasakan esensi dari pemisahan ketat antara UI dan logika, dalam kasus di mana Anda harus mentransfer layar dari satu proyek ke proyek lainnya. Atau dalam situasi di mana, dalam kondisi yang berbeda, algoritma yang berbeda digunakan dalam logika bisnis. Misalnya, dengan membagi layar otorisasi menjadi beberapa komponen, kami dapat mengganti salah satu komponen di masa mendatang tanpa memengaruhi yang lain. Kami dapat mengganti Lihat atau Model dengan metode otorisasi baru untuk data yang sama.
Jangan membatasi prinsip "memecah belah dan menaklukkan" hanya dua lapisan ini. Untuk pemisahan yang ketat, saya akan menambahkan pemisahan layar dan logika navigasi untuk aplikasi seluler. Apa yang saya maksud dengan itu?
Praktik saya telah mendorong saya untuk membuatnya lebih mudah untuk mengkodekan layar tertentu dengan mengeluarkan logika navigasi secara terpisah. Layar, khususnya View, untuk iOS adalah UIViewController, dan kadang-kadang UIView, dan untuk Aktivitas Android, atau Fragment, mereka tidak boleh terlibat dalam fungsi untuk menampilkan dirinya sendiri, serta beralih ke layar lain. Masing-masing kelas ini seharusnya hanya peduli tentang apa yang terjadi pada layar tertentu, atau lebih tepatnya, hanya untuk merender layar tertentu dan berinteraksi dengan kelas logika bisnis (Presenter, ViewModel, dan lainnya).
Ini hanyalah dua dari banyak contoh di mana Anda perlu mengikuti pemisahan secara mendasar. Mengikuti prinsip ini akan sangat memudahkan pekerjaan lebih lanjut dengan proyek. Bahkan jika govnokod didapat dari komponen yang terpisah.
Gaya tunggal
Beranjak dari saran sebelumnya, saya ingin beralih ke saran berikutnya, yaitu kepatuhan yang ketat pada gaya tunggal dalam proyek.
Apa yang saya maksud dengan itu?
Untuk mulai dengan, kata kuncinya di sini ketat, dari kata sama sekali. Awalnya, kami memilih satu pendekatan untuk mengatur proyek, untuk manajemen file, untuk gaya kode, dan sebagainya. Ini akan secara signifikan meningkatkan tampilan umum proyek dan sangat memudahkan navigasi proyek, mencari berdasarkan kode, dan mempercepat proses memperkenalkan pengembang baru ke proyek. Saya pikir tidak ada gunanya mengingatkan bahwa setelah beberapa saat kita sendiri dapat menjadi orang baru ini dengan kode lama kita.
Pilihan arsitektur dan mengikutinya
Sekali lagi, melanjutkan dari saran sebelumnya, kami dengan lancar melanjutkan ke yang berikutnya, pilihan arsitektur. Dan ide utama yang ingin saya sampaikan adalah tidak berbicara tentang arsitektur terbaik atau mengatakan bahwa Anda harus memilih ini dan bukan yang lain. Tidak! Untuk memulainya, tidak ada arsitektur ideal yang akan sepenuhnya mencakup semua kasus yang mungkin dalam proyek. Saya pernah mendengar kata-kata ini: "jika ada arsitektur yang ideal, maka kami pengembang akan dipecat sebagai tidak perlu dan diganti dengan skrip yang menghasilkan arsitektur yang ideal."
Poin utama, saya percaya, bukanlah pilihan arsitektur terbaik, tetapi sekali lagi kepatuhan ketat terhadap arsitektur yang telah dipilih dan mulai diterapkan. Baik itu VIPER, REDUX, MVP atau MVC. Tentu saja ada pro dan kontra untuk masing-masing arsitektur di atas. Seiring waktu, semakin banyak pendekatan baru pada desain arsitektur proyek.
Saya akan mengatakan lebih spesifik tentang ide saya. Jika Anda sudah mulai menggunakan VIPER, maka patuhi prinsipnya dengan ketat. Bahkan jika tampaknya untuk layar satu tombol ada terlalu banyak file untuk membuat unit garis kode, jangan melewati aturan ini dalam keadaan apa pun. Karena, pada saat-saat seperti ini, govnokod dilahirkan, yang kemudian, seperti bola salju, semuanya tumbuh dan tumbuh.
Saya menyarankan Anda untuk berkenalan dengan arsitektur paling populer dan memilih salah satu yang Anda sukai atau yang paling populer sebelum memulai proyek baru. Saya sangat menyarankan memilih opsi kedua, yaitu mulai dengan arsitektur paling populer, sebagai akan mudah untuk menemukan jawaban atas banyak pertanyaan. Saat memilih arsitektur, perhatian khusus harus diberikan pada minus arsitektur ini dan dalam hal ini disarankan untuk menggunakannya.
Misalnya, jika Anda memiliki proyek kecil di mana terdapat satu dua pengembang, maka Anda tidak boleh mengambil VIPER karena fakta bahwa ini adalah arsitektur yang agak rumit yang berkinerja sangat baik pada proyek besar dan dalam tim besar. Sehingga tidak ada kasus ketika kode untuk membuat VIPER berkali-kali lebih banyak daripada kode logika bisnis itu sendiri.
Secara pribadi, saya sekarang lebih suka arsitektur MVVM + Router. Ini bekerja dengan baik pada proyek kecil di mana saya adalah pengembang tunggal.
Intinya: hal utama bukanlah arsitektur yang telah Anda pilih, tetapi bagaimana tepatnya Anda mengikutinya.
Saya juga ingin menambahkan, jika proyek tidak dikembangkan dari awal, maka pertama-tama Anda perlu membiasakan diri dengan arsitektur saat ini dan gaya umum proyek, dan mulai mengikutinya. Anda tidak boleh keluar dengan jeritan bahwa ada govnokod (kembali ke saran pertama) dan mulai mengulangi semuanya. Pengecualian mungkin merupakan anarki yang lengkap pada proyek atau kurangnya gaya umum.
Jeda Refactoring
Sebagai kesimpulan, saya ingin mengatakan bahwa berhenti sejenak untuk refactoring adalah pendekatan yang baik. Refactoring adalah bagian yang sangat penting dari pengembangan aplikasi yang berkualitas. Ya, kami tidak segera menulis kode yang sempurna, tetapi membiarkannya karena tidak baik juga. Sering terjadi bahwa implementasi asli tidak memiliki kemampuan untuk skala ketika Anda perlu memperkenalkan fitur baru. Lagi pula, hampir tidak mungkin untuk memprediksi semua kemungkinan perubahan dalam versi proyek yang akan datang. Juga, tidak ada arsitektur yang menjamin cakupan 100% dari semua kasus. Karena itu, penting untuk membuat perubahan pada kode yang ada untuk menyesuaikannya dengan fitur baru.