Hai, saya Andrey Kucherenko, pemimpin tim pengembangan ponsel Skyeng. Kami membuat aplikasi seluler untuk iOS dan Android. Mereka memiliki fungsi yang sama dan antarmuka yang sama akurat dengan gaya. Tetapi karena platform yang berbeda, pengembangan aplikasi yang tampaknya cukup mahal. Dalam mencari peluang untuk menghemat pengembangan lintas platform seluler, kami mencoba empat solusi:
- Menggabungkan pengembang iOS dan Android dalam satu tim
- Pembentukan kelompok kerja untuk memecahkan masalah yang kompleks
- Menyimpan pada dokumentasi
- Menulis kode umum
Saya memiliki kesempatan untuk membuat beberapa laporan tentang apa yang terjadi; Dalam artikel ini, saya telah mengumpulkan pengamatan dan hasil utama.
Menggabungkan pengembang iOS dan Android dalam satu tim
Dua tahun lalu, kami memiliki dua aplikasi seluler yang terpisah dan dua tim pengembangan, yang hanya terhubung oleh manajer produk umum. Banyak masalah muncul dari ini: aplikasi satu sama lain secara lahiriah hanya menyerupai jarak jauh, mereka bekerja dalam banyak cara, para pengembang tidak tahu bagaimana aplikasi tetangga diatur, mereka secara teratur mengeluarkan segala macam bug dan kesalahan dalam logika. Pada titik tertentu, menjadi jelas bahwa ini tidak dapat dilanjutkan, dan hal pertama yang kami lakukan dalam hal ini adalah menyatukan pengembang iOS dan Android menjadi satu tim produk, membuat sejumlah proses menjadi umum.
Salah satu dari proses ini telah menjadi tinjauan teknis.
Sebelum sampai ke pengembang, tugas berjalan dengan cara tertentu. Untuk mulai dengan, itu dirumuskan dalam format Kisah Pengguna, sketsa atau tata letak digambar di atasnya, setelah itu sebuah epik dimulai di mana masalah pengguna dan solusinya dijelaskan. Dalam bentuk ini, cerita jatuh ke dalam memimpin tim jika itu adalah epik lintas tim, atau ke satu pemimpin tim jika berada di tim yang sama. Di sana semuanya terurai ke tingkat tugas individu. Dalam setiap tugas tersebut, jika sesuai, solusi yang mungkin dijelaskan, tugas di dalam tautan Epic satu sama lain, berbagai pemblokir ditempelkan, yang menghilangkan banyak komunikasi yang tidak perlu. Setelah itu, tinjauan teknis dilakukan secara langsung, di mana keputusan akhir akan diperbaiki dan estimasi akan dimasukkan. Juga pada tahap ini, tugas dapat didekomposisi lebih lanjut jika estimasi diperoleh lebih dari dua hari.
Bagaimana kami menghemat ulasan teknis bersama:
- dalam kebanyakan kasus, ternyata solusi teknis yang sama untuk iOS dan Android. Solusi yang berbeda juga mungkin, ini mungkin disebabkan oleh arsitektur platform yang berbeda, tetapi dalam konteks tugas perbedaannya paling sering minimal;
- menyinkronkan arsitektur dan struktur kedua aplikasi. Ini menghilangkan situasi ketika produk dilengkapi dengan fitur lain, dan kami mengevaluasi tugas iOS dua jam, dan Android pada minggu itu, karena semuanya harus ditulis ulang di sana;
- lebih sering daripada tidak, kita mendapat nilai bagus. Jika penilaian kami untuk platform sangat berbeda, ini mungkin mengindikasikan bahwa pengembang tidak memahami tugas, atau beberapa masalah platform yang perlu ditangani;
- Dengan ulasan ini, pertukaran pengalaman terjadi antara pengembang iOS dan Android, dan saya percaya mereka harus memiliki gagasan tentang bagaimana platform tetangga bekerja. Sering kali ternyata solusi dari satu platform berhasil untuk yang lain;
- penyederhanaan pengujian manual. Fitur diimplementasikan berdasarkan satu solusi teknis, jika QA menemukan bug, maka ini adalah kesempatan untuk mengulangi langkah yang sama di platform lain. Seringkali bug yang sama juga ada;
- tentara universal, yang mampu menulis untuk kedua platform: jika ya, maka Anda dapat mengalihkannya di antara proyek, yang meningkatkan faktor bus dan membuatnya mudah untuk mentransfer liburan dan ketidakhadiran. Tidak ada situasi ketika satu platform berjalan jauh di depan selama liburan.
Faktor bus: jumlah orang dalam tim yang harus diturunkan oleh bus sehingga proyek tidak dapat dilanjutkan.
Kelompok kerja untuk memecahkan masalah yang kompleks
Untuk menyelesaikan masalah, sangat sering, selain menulis kode secara langsung, kita perlu melakukan beberapa penelitian, melaksanakan desain, dan jika tugas tersebut melibatkan interaksi antar tim, menghabiskan banyak waktu untuk berkomunikasi. Dalam konteks pengembangan ponsel, tugas apa pun yang tidak memerlukan semua ini adalah sesuatu yang sepele, tidak melibatkan pekerjaan dari backend. Saya menyebutnya "sederhana", dan yang lainnya - "kompleks".
Saya menganalisis worklog mengenai distribusi waktu yang dihabiskan untuk penulisan kode, komunikasi, desain, dan penelitian. Inilah yang terjadi untuk tugas-tugas sederhana:
Semuanya jelas di sini, pada dasarnya kita menulis kode, biayanya hingga 80% dari waktu.
Sangat sering, tugas memerlukan semacam penyempurnaan dari backend, ini secara otomatis membuatnya antar-perintah. Di sini, lebih banyak waktu dihabiskan untuk desain dan komunikasi. Pangsa penulisan kode berkurang:
Seringkali produk datang dengan tugas-tugas yang tidak sesuai dengan arsitektur aplikasi saat ini, dan kita perlu menghabiskan waktu untuk menemukan solusi yang baik: mungkin merencanakan beberapa refactoring, segera melaksanakannya sebagai bagian dari tugas, dll. Dalam hal ini, banyak waktu dihabiskan untuk mendesain:
Akhirnya, tugas-tugas yang umumnya tidak jelas cara pendekatannya, di mana Anda harus terlebih dahulu meneliti dan merancang:
Jika pekerjaan pada tugas kompleks tidak dapat dikoordinasikan dengan cara apa pun, maka semua pekerjaan yang tidak terkait langsung dengan penulisan kode akan dilakukan dua kali. Dan dalam tugas yang kompleks, ini adalah 50% dari waktu penyelesaian, seringkali bahkan lebih.
Saya menemukan jalan keluar: Saya hanya mengambil dan mengunci semua tugas ini pada diri saya sendiri. Saya berhasil menghemat waktu, tetapi saya terus kelebihan beban, saya tidak punya cukup waktu untuk memperhatikan tugas-tugas prioritas rendah, para pengembang harus menunggu saya, semuanya buruk. Masalah muncul lagi, dan kami sudah menyelesaikannya dengan membuat kelompok kerja.
Kelompok kerja adalah beberapa pengembang iOS dan Android yang akan terlibat langsung dalam penerapan fitur ini. Seseorang ditunjuk sebagai pemimpin, dialah yang akan bertanggung jawab untuk desain, penelitian, interaksi dengan tim lain. Hasil karyanya akan menjadi dokumentasi, di mana semuanya sudah diperbaiki; dermaga ini kemudian ditinjau oleh kelompok kerja dan ketua tim, dan tim melanjutkan implementasi.
Sebagai hasilnya, kami menerima:
- Beban pada Timlid telah menurun, sementara dia tidak kehilangan kendali atas kemajuan tugas. Saya berpartisipasi dalam semua pertemuan utama, meninjau solusi teknis, benar-benar mengontrol tugas sebelum langsung masuk ke dalam pengembangan;
- para pengembang sangat termotivasi. Ketika kami menguji latihan ini, semua orang datang dan berkata "keren, mari kita coba lagi." Tidak ada orang yang tidak mau melakukan ini dan lebih suka "hanya coding". Orang-orang memiliki lebih banyak peluang untuk pengembangan;
- faktor bus meningkat, tim menjadi lebih mandiri, ditambah mereka yang dapat dikembangkan lebih lanjut menjadi pemimpin tim terlihat jelas pada tugas-tugas tersebut. Masalah meninggalkan Timlida untuk berlibur sedang diselesaikan.
Simpan pada dokumentasi
Kami memutuskan untuk menyimpan dokumentasi di marketdown dan menyimpannya di repositori github. Dokumentasi direvisi bersama dengan kode dan permintaan tarik, jadi kami mengecualikan situasi ketika sesuatu ditulis, tetapi ketika tidak ada yang membacanya, dan ketika diminta, tidak ada yang mengerti apa pun. Dokumentasi dengan kode memungkinkan Anda untuk masuk ke dalam konteks, untuk memahami apa itu pull-rikvest.
Kami mengedit dokumentasi langsung dari IDE, kebanyakan dari mereka dapat membuat penurunan harga, itu tidak mengganggu kode penulisan, Anda tidak perlu pergi ke suatu tempat dalam pertemuan, risikonya berkurang bahwa pengembang hanya akan lupa untuk memperbaruinya. Bagi mereka yang mengunduh repositori secara lokal, kami melemparkan tautan ke Github, mereka juga dapat membaca semuanya.
Akhirnya, gaya docking ini membantu dalam pengembangan pengembang baru: bersama dengan kode, ia menerima semua gaya kode yang mungkin, konvensi, instruksi perakitan aplikasi, dan memasuki tim jauh lebih mudah.
Kode umum
Gagasan menulis kode umum bukan yang terbaru, ada banyak alat untuk melakukan ini. Kami mencoba C ++ untuk menulis perpustakaan kosa kata, dan kami memiliki aplikasi kecil yang seluruhnya ditulis dalam Multipliner Kotlin. Secara teoritis, ketika menggunakan alat pengembangan lintas-platform, biaya penulisan kode kami harus dikurangi setengahnya. Tetapi yang tambahan muncul:
biaya awal. Banyak waktu harus dihabiskan untuk mengumpulkan, meluncurkan, menguji, menguji hipotesis, dan melatih tim. Dalam beberapa kasus, biaya ini sangat besar sehingga keuntungannya tidak terlihat sama sekali;
menulis kode platform. Dari pengalaman saya sendiri dan berdasarkan sejumlah sumber, saya dapat mengatakan bahwa apa pun alat yang Anda pilih, jika Anda memiliki aplikasi yang agak rumit, cepat atau lambat Anda harus menulis kode platform. Waktu untuk menulisnya sangat bervariasi tergantung pada alat yang dipilih;
penghapusan cacat. Sebagian besar alat masih sangat mentah, mereka memiliki bug, Anda harus berurusan dengan beberapa rilis yang melanggar kompatibilitas, dan akan butuh waktu untuk memperbaiki semua ini juga;
menghindari pembatasan. Alat lintas platform mungkin memiliki batasan arsitektural atau lainnya yang dapat Anda temui dan habiskan waktu untuk menghindarinya. Kadang-kadang pembatasan seperti itu ternyata sangat parah sehingga orang harus sepenuhnya meninggalkan alat. Misalnya, Airbnb mengabaikan React Native dan kembali ke pengembangan asli;
Kompleksitas pengembangan. Anda harus menulis kode untuk dua platform sekaligus, yang tidak semua orang tahu, ditambah komunikasi tambahan akan muncul. Kurangnya IDE asli juga tidak menyederhanakan pengembangan ini.
Untuk membandingkan biaya metode pengembangan lintas platform yang kami coba, saya mengidentifikasi empat kelompok utama:
- biaya awal
- biaya penulisan kode umum
- biaya penulisan kode platform
- biaya infrastruktur (yang tidak berlaku untuk tiga poin pertama)
Dia mengambil acak-acakan dan membandingkan waktu yang sebenarnya dihabiskan untuk pengembangan lintas-platform dan waktu yang seharusnya kita habiskan untuk pengembangan asli.
Setiap kolom adalah tugas. Dalam kasus C ++, itu ternyata menjadi awal yang cukup mudah, tetapi biaya infrastruktur ternyata signifikan, total penghematan - hanya 29%. C ++ juga ditinggalkan karena bahasa ini menurunkan faktor bus: pengembang seluler kami tidak tahu C ++, mereka dapat mendukung kode, tetapi tidak ada seorang pun di tim yang memiliki pengalaman serius.
Start-up sangat tinggi, tetapi sementara biaya kode platform dan infrastruktur rendah. Kami tidak memiliki cukup untuk analisis yang baik dari jumlah tugas, pada posisi saat ini menghemat 19%. Dengan asumsi bahwa kita akan melakukan banyak tugas dan membuang biaya awal, kita akan mendapatkan penghematan sekitar 40%, kecuali, tentu saja, masalah serius akan muncul di masa depan. Kelebihan lainnya adalah sebagian besar pengembang akrab dengan Kotlin.
Yang minus jelas - kerumitan prosesnya. Kami baik menulis untuk kedua platform sekaligus, tetapi tidak semuanya dapat, atau menunggu sampai seseorang menulis bagian umum, maka kami akan merevisinya, kemudian ternyata tidak cocok, dll. dll. Kita harus mengeluarkan biaya tambahan untuk fase desain, sehingga semuanya mungkin segera berakhir.
Total:
- Anda dapat dan harus menghemat proses pengembangan seluler dan penulisan kode. Proses yang dibangun dengan benar membantu tidak hanya menyimpan, tetapi juga menyelesaikan sejumlah tugas tambahan.
- Saat memilih alat untuk pengembangan ponsel lintas platform, Anda perlu menilai risiko dan biaya tenaga kerja secara cermat.