Halo semuanya, nama saya Gevorg. Saya Kepala Mobile di Profi.ru. Saya ingin berbagi dengan Anda kisah percobaan kami dengan React Native. Saya akan memberi tahu Anda bagaimana kami mengevaluasi pro dan kontra pengembangan React Native - secara teori dan dalam praktik. Artikel ini akan bermanfaat bagi mereka yang tertarik dengan pengembangan ponsel lintas platform, tetapi belum memutuskan apakah akan menggunakan cara ini atau tidak.
Akselerasi maksimum
Semuanya dimulai dengan fakta bahwa kami memutuskan untuk mempercepat pengembangan sebanyak 10 kali di tingkat perusahaan. Kami menetapkan tujuan yang mustahil untuk melampaui cakrawala peristiwa dan mencoba hal-hal baru. Semua tim pengembangan Profi.ru melakukan percobaan. Pada waktu itu, perusahaan memiliki 13 pengembang ponsel asli, termasuk saya dan dua pemimpin tim. Tim saya bekerja pada dua aplikasi seluler. Yang pertama, pelanggan mencari spesialis, yang kedua - pelanggan ahli. Bagi saya, periode ini tidak dapat dipahami dan penuh tekanan secara emosional. Menurut perasaan saya, kami melakukan begitu banyak sehingga semuanya bekerja dengan cepat.
Kami menggunakan arsitektur umum di seluruh proyek dan memantau kemurnian kode. Generator yang digunakan yang membuat semua file modul. Mereka mencoba mengeluarkan semua logika bisnis di backend. Kami mengatur CI / CD, dan aplikasi yang ditutupi dengan tes E2E. Karena semua ini, beberapa aplikasi dirilis secara stabil seminggu sekali. Saya tidak tahu bagaimana mempercepat pengembangan bahkan dua kali. Sejauh ini pukul 10. Karena itu, kami menentukan apa yang penting bagi kami.
- Basis kode terpadu. Saya ingin semua pengembang seluler kami menulis kode yang sama. Dalam satu bahasa, tanpa perbedaan platform antara iOS dan Android. Jadi kita bisa mempercepat pengembangannya hingga setengahnya.
- Alat baru yang mudah dipelajari. Sehingga saat memperluas tim kami tidak memiliki masalah dengan pelatihan ulang atau perekrutan.
- Rilis cepat. Sehingga kita bisa rilis bukan seminggu sekali, tapi setiap hari.
- Pembaruan instan. Sehingga semua pengguna segera menerima pembaruan. Seperti yang sekarang terjadi dalam pengembangan web.
Setelah tinjauan singkat, tiga kandidat muncul: React Native, Flutter, Kotlin / Native. Baik Flutter maupun Kotlin Native tidak dapat dirilis dengan cepat. Dan kami menganggap ini mungkin yang paling penting. Selain itu, teknologi ini sepenuhnya mentah pada waktu itu. Kami memilih React Native - itu bisa dirilis secara instan. Plus, sebagian besar pengembang kami sudah menggunakan Bereaksi.
Secara umum, saya negatif tentang alat lintas platform - seperti kebanyakan pengembang seluler asli. Pergi ke konferensi seluler apa saja dan bicarakan - Anda akan segera dirajam. Saya suka benda ini sendiri :-) Oleh karena itu, untuk mengkonfirmasi atau menyangkal ketakutan, kami melakukan penyelidikan.
Pro, Risiko, dan Masalah
Kami mempelajari contoh penggunaan React Native di berbagai perusahaan - sukses dan tidak begitu baik. Dengan Kepala Dev, Borey Egorov dengan hati-hati membaca lebih dari tiga lusin artikel dan materi lainnya. Beberapa membahas setiap paragraf. Di akhir artikel - tautan ke yang paling menarik. Kami mencatat poin-poin yang dapat mempercepat kami, kemungkinan risiko dan pertanyaan. Setelah itu, kami berbicara dengan pengembang dari tiga perusahaan. Di masing-masing orang, mereka menciptakan produk massal dan bekerja dengan React Native selama setidaknya satu tahun.
Dengan pro, semuanya sangat jelas.
- Basis kode umum.
- Over-the-Air, atau perbarui melalui udara, melewati toko.
- Dari dua poin pertama, maka kecepatan pengiriman fitur kepada pengguna akan meningkat.
- Pengembang web akan dapat menulis kode untuk aplikasi seluler. Jika seorang pengembang web tahu Bereaksi dengan baik, maka ia dapat dengan cepat mempelajari Bereaksi Asli. Dan jika pengembang seluler sudah mengetahui platform ini, maka itu dapat memasuki pengembangan web relatif cepat.
Daftar risiko lebih panjang :-)
Risiko pertama . Alih-alih satu platform, dalam jangka panjang kami terpaksa mendukung tiga: Android, iOS dan React Native.
Terkadang layar pengembang terlihat seperti ini:
Realita Salah satu teman bicara kami menyuntikkan React Native ke dalam kode yang ada. Ya, platform ketiga yang lengkap muncul, tetapi Anda tidak pergi ke mana pun dari pengembangan asli. Timnya harus menyinkronkan keadaan antara Bereaksi Asli dan kode asli. Ini mensyaratkan banyak pergantian di antara bagian kode / paradigma dan IDE yang berbeda. Oleh karena itu, mereka memutuskan untuk menulis proyek baru dari awal, membuat kerangka kerja tentang React Native, dan sudah memasukkan karya asli ke dalamnya di mana mereka diperlukan. Itu menjadi lebih baik.
Risiko kedua. React Native Black Box - kadang-kadang ada situasi ketika pengembang tidak mengerti mengapa bug muncul. Anda harus mencari di mana-mana: di React Native code, di bagian asli produk atau di platform React Native itu sendiri.
Realita Orang-orang yang kami ajak bicara membungkus aplikasi dengan log dan berbagai alat: Crashlytics, Kibana, dan sebagainya. Masalah tetap ada, tetapi menjadi jelas di mana mereka muncul.
Risiko ketiga. Sering ditemukan dalam artikel bahwa React Native cocok untuk proyek kecil, tetapi tidak untuk produk besar dengan fungsionalitas platform.
Realita Kami melihat apakah ada perusahaan besar di pasar yang bekerja dengan React Native. Ternyata - ada lusinan, jika tidak ratusan. Termasuk Skype, Tesla, Walmart, Uber Eats, dan Kitchen di Area.
Risiko keempat. Setiap kali Anda meningkatkan sistem operasi Anda dari Apple atau Google, proyek mungkin rusak.
Realita Kami memutuskan bahwa risikonya bisa diterima. Risiko yang sama ada untuk pengembangan penduduk asli. Ketika OS baru untuk iOS dan Android keluar, Anda menyesuaikan aplikasi Anda dengannya.
Risiko kelima. Tidak ada dukungan sistem 64-bit di Android, dan masalah telah terbuka sejak 2015. Dan sejak Agustus 2019, Google Play belum menerima build yang hanya mendukung sistem 32-bit.
Realita Kami melihat masalah yang tim React Native kerjakan pada musim panas 2018. Mereka berjanji untuk menambahkan dukungan dalam rilis berikutnya, meskipun mereka belum sepenuhnya memperbaiki dukungan untuk sistem 64-bit. Ini sangat kesal. Dukungan kemudian ditambahkan, tetapi beberapa perangkat Android jatuh setelah transisi. Seperti yang kemudian kami ketahui, persentasenya sedikit, tetapi tetap saja itu adalah titik paling menyakitkan bagi saya.
Risiko keenam. Kemungkinan besok, Apple atau Google akan merilis versi baru OS mereka dan merusak React Native. Atau teknologi baru yang pada prinsipnya Profi.ru tidak akan dapat mendukung.
Realita Tidak ada jaminan untuk kami atau banyak perusahaan lain. Anda bisa menyadari risikonya dan melakukannya, atau mencoba sesuatu yang lain. Kami memutuskan untuk melakukannya, dan menyelesaikan semua masalah saat tersedia.
Risiko ketujuh. Kami tidak dapat mengatakan sebelumnya seberapa cepat React Native akan dibandingkan dengan aplikasi asli dan kinerja apa yang akan ditampilkan.
Realita Kutipan literal dari salah satu lawan bicara kami adalah "daftar elemen dengan tinggi variabel saat menggulir melambat." Kami memutuskan untuk check-in dalam praktik. Sedikit berjalan di depan - pada saat penulisan prototipe pertama dari aplikasi, kami tidak melihat masalah seperti itu, tetapi ketika kami mengembangkan aplikasi yang lengkap, ada banyak pertanyaan tentang kinerja React Native.
Risiko kedelapan. Tidak jelas seberapa cepat kita dapat menemukan pengembang Bereaksi Asli. Di HeadHunter saya menemukan sekitar 300 resume, meskipun faktanya ada lebih dari 150 ribu pengembang untuk iOS.
Realita Mereka tidak masuk jauh ke sini, karena mereka telah merekrut pengembang Bereaksi lebih dari sekali dan tahu apa yang harus dicari. Kami memutuskan bahwa sebagai upaya terakhir kami dapat melatih kembali pengembang Bereaksi di React Native.
Ada juga risiko bahwa seseorang akan meninggalkan tim, karena pengembang seluler tidak menyukai teknologi ini. Ngomong-ngomong, aku benar. Seseorang pergi :-(
Saya bosan menulis React Native, jadi yang berikut ini hanya RN :-)
Apa yang kita ubah dan apa yang tidak
Kami mendiskusikan hasil penyelidikan dengan para pendiri perusahaan, Sergey Kuznetsov dan Yegor Rudi, dan mendapat lampu hijau untuk percobaan.
Kami memutuskan untuk membuat produk baru dari awal, dan tidak memasukkannya ke yang sudah ada. Dan juga - jangan menyentuh aplikasi klien kami. Itu cukup matang, dan secara ekonomi tidak masuk akal untuk secara radikal mengubah sesuatu. Selain itu, penting bagi kami bahwa aplikasi klien memiliki pengalaman asli sendiri untuk iOS dan Android.
Tetapi kami ingin mengubah aplikasi untuk spesialis secara radikal. Tidak seperti klien, kami tidak malu bahwa para spesialis akan memiliki pengalaman interaksi yang sama untuk aplikasi iOS dan Android. Selain itu, kami percaya bahwa dalam suatu produk untuk spesialis dapat kita lakukan tanpa animasi dan efek visual. Tetapi sebelum seluruh tim beralih ke teknologi baru, perlu dirasakan bagaimana cara kerjanya.
Eksperimen dalam aksi
Pada bulan Desember 2018, kami membentuk tim yang terdiri dari tiga orang. Dua pengembang Bereaksi dan satu asli - saya. Saya mengerti bagaimana Android bekerja, dan sangat berpengalaman dalam pengembangan iOS.
Sebagai bagian dari percobaan, kami ingin memeriksa poin-poin berikut:
- bagaimana rilis instan bekerja di RN;
- bagaimana interaksi antara komponen asli dan RN;
- bisakah kita menggunakan komponen asli kita;
- bagaimana RN bekerja dengan kamera, push, dan diplink;
- bagaimana navigasi dan penghematan negara bekerja di RN;
- sejauh yang bisa kita lakukan dengan RN pixel perfect;
- bagaimana pengujian otomatis bekerja di RN;
- seberapa cepat pengembang asli atau Bereaksi dapat mempelajari teknologi.
Kami mendapat hasil pertama dalam waktu satu setengah bulan setelah terjun ke pengembangan.
- Saya mulai menulis kode di bawah RN setelah hanya dua minggu. Bagi saya, teknologinya benar-benar tidak rumit. Salah satu pengembang React kami banyak membantu saya - dia terkenal berbicara tentang React / Redux dan JS secara umum. Itu perlu untuk memasuki seluk-beluk React / Redux, tetapi setelah beberapa saat "neuron mulai belajar," seperti yang dikatakan perusahaan kami :-)
- Saya terkejut bahwa dalam beberapa bentuk JS + Flow menyediakan pengetikan yang kuat. Untuk JS, harapan saya jauh lebih rendah. Pada saat yang sama, saya pasti akan lebih memilih Swift dan Kotlin: bagi saya mereka jauh lebih indah dan menyenangkan daripada JS, tetapi di sini kata-kata utamanya adalah "untuk saya".
- Ini membantu kami bahwa tim menyertakan pengembang yang dapat menulis kode untuk iOS, Android, dan React. Setiap platform memiliki masalah spesifiknya sendiri. Untuk mengatasinya, tim harus lintas fungsi.
- Rilis instan berfungsi. Bagi saya itu seperti sihir. Tidak perlu menunggu rilis dan peningkatan dari Apple. Dicari - mengambil dan melepaskan.
- Sangat sering proyek mogok. Ini benar-benar tidak keren. Anda mengambil perubahan dari cabang, Anda mencoba lari - dan tidak apa-apa. Itu sangat menjengkelkan. Pada titik tertentu, kami baru saja menulis sebuah skrip yang membersihkan proyek sepenuhnya. Ini bukan untuk mengatakan bahwa mereka memecahkan masalah secara keseluruhan, tetapi menyelesaikan sebagian besar masalah itu.
- Namun, kami harus bekerja dengan tiga platform, meskipun pada kenyataannya kami terutama menulis kode pada RN. Semua pengembang memiliki tiga IDE: Xcode, Android Studio, WebStorm.
- Pushas, tautan dalam, kamera, mulai navigasi. Tetapi mereka mulai dengan bantuan perpustakaan pihak ketiga, atau perpustakaan dalam kode asli harus ditulis sendiri, dan kemudian terhubung ke RN.
Di akhir artikel saya ingin kembali ke judul. Jadi, apakah RN peluru perak untuk semua masalah? Kami memutuskan sendiri bahwa tidak. Pada saat yang sama, mereka mendapatkan apa yang mereka inginkan. Kami telah meningkatkan beberapa kali kecepatan pengiriman fitur dan sekarang kami dapat merilisnya ke semua pengguna setiap hari. Penting juga bahwa tim lintas fungsi telah muncul di perusahaan, di mana setiap pengembang menulis kode baik di Android / iOS dan di web.
Dan ya, aplikasi di toko :-)
Artikel yang berguna tentang Bereaksi Asli
- Mengapa Perselisihan Bertahan dengan Bereaksi Asli - Fanghao (Robin) Chen
- Betapa Aku Mencintai dan Benci Bereaksi Asli - Andrey Melikhov
- Bereaksi Asli dari sudut pandang pengembang seluler - Andrey Konstantinov
- Bereaksi Asli di Instagram - Instagram Engineering
- React Native: Retrospektif dari tim teknik ponsel di Udacity - Nate Ebel
- Bereaksi Asli: pertarungan satu babak - Samat Galimov
- Sunsetting React Native - Gabriel Peal