Hingga baru-baru ini, Dropbox memiliki strategi teknis untuk menggunakan kode C ++ umum untuk aplikasi seluler iOS dan Android. Idenya jelas: tulis kode sekali dalam C ++ daripada menduplikasi secara terpisah di Jawa dan Objective C. Kami mengadopsi strategi ini kembali pada 2013, ketika kelompok insinyur pengembangan ponsel relatif kecil dan harus dengan cepat mengembangkan produk. Solusi semacam itu memungkinkan untuk menghasilkan sejumlah besar kode pada Android dan iOS oleh kekuatan tim kecil.

Sekarang kami telah sepenuhnya meninggalkan strategi ini demi bahasa-bahasa asli dari setiap platform (terutama Swift dan Kotlin, yang tidak ada ketika kami mulai). Solusi ini melibatkan (tidak begitu) biaya tersembunyi dari pembagian kode.

Semua masalah berasal dari hal utama: overhead ternyata lebih dari sekadar menulis kode dua kali .

Sebelum menganalisis berbagai jenis overhead, saya ingin mengklarifikasi bahwa kita tidak pernah sampai pada titik di mana sebagian besar basis kode berada di C ++. Biaya sebenarnya mencegah kami bergerak ke arah itu.

Perlu dicatat juga bahwa banyak perusahaan besar seperti Google dan Facebook telah mengembangkan solusi berbagi kode yang dapat diskalakan selama beberapa tahun sekarang. Solusi semacam itu tidak terlalu umum. Meskipun sistem pihak ketiga seperti React Native atau Flutter menghindari beberapa overhead, beberapa biaya masih tetap ada (setidaknya sampai salah satu teknologi ini menjadi cukup populer dan cukup matang). Misalnya, Airbnb menolak untuk menggunakan Bereaksi Asli karena banyak alasan yang sama yang diuraikan dalam artikel ini.

Semua biaya dapat dikelompokkan ke dalam empat kategori utama.

Overhead kerangka kerja dan pustaka kustom

Cara termudah untuk memprediksi biaya pembuatan kerangka kerja dan perpustakaan. Mereka secara kasar dibagi menjadi dua subkategori:

• Kerangka kerja yang memungkinkan Anda untuk berinteraksi dengan lingkungan host untuk membuat aplikasi seluler lengkap. Sebagai contoh:
  
  • Djinni , alat untuk membuat deklarasi antar-bahasa dari tipe dan antarmuka koneksi
    
  • Kerangka kerja untuk melakukan tugas di latar belakang terhadap utas utama (sepele dalam bahasa asli platform)
  
  
• Perpustakaan untuk menggantikan standar bahasa atau solusi open source yang dapat digunakan dalam bahasa asli, misalnya:
  
  • json11 untuk (de) serialisasi JSON
    
  • nn pointer tidak nol untuk C ++

Semua ini tidak diperlukan jika Anda tetap menggunakan bahasa asli platform. Dan partisipasi kami dalam proyek sumber terbuka dalam bahasa asli mungkin akan lebih bermanfaat bagi pengembang. Dalam komunitas C ++, budaya open source adalah (dan apakah itu?) Tidak seperti yang dikembangkan di komunitas pengembang seluler, terlebih lagi karena komunitas seluler C ++ praktis tidak ada.

Harap perhatikan bahwa overhead ini sangat tinggi untuk C ++ (tidak seperti bahasa non-asli lainnya yang mungkin seperti Python atau C #), karena tidak ada satu perpustakaan standar yang berfungsi penuh. Namun, hanya C / C ++ yang memiliki kompiler yang didukung oleh Google dan Apple, jadi beralih ke bahasa lain menyebabkan sejumlah masalah lain.

Lingkungan pengembangan kustom yang terlalu besar

Ada banyak alat dalam ekosistem seluler untuk meningkatkan efisiensi pengembangan. IDE seluler sangat fungsional, dan Google dan Apple telah menginvestasikan banyak sumber daya untuk menjadikannya ideal di platform mereka. Beranjak dari standar, kami memberikan beberapa keuntungan. Pertama-tama, debugging bahasa asli biasanya mengungguli debugging C ++ di IDE secara default.

Saya terutama ingat satu kesalahan yang menyebabkan pemblokiran struktur streaming latar belakang, yang menyebabkan aplikasi crash. Kesalahan seperti itu sulit dilacak bahkan dengan tumpukan standar yang sederhana. Karena masalahnya melibatkan debug kode multi-ulir yang berjalan antara C ++ dan Java, butuh berminggu-minggu untuk melacak!

Selain kehilangan alat standar, saya harus menginvestasikan waktu dalam membuat alat saya sendiri untuk mendukung kode C ++ umum. Yang paling penting, sistem build khusus diperlukan untuk membuat pustaka yang berisi kode C ++, serta shell Java dan Objective-C. Seharusnya menghasilkan gol yang dipahami oleh Xcodebuild dan Gradle. Menciptakan sistem seperti itu membutuhkan banyak sumber daya, karena harus terus diperbarui untuk mendukung perubahan dalam dua sistem pembangunan.

Platform Override untuk Perbedaan Platform

Meskipun iOS dan Android adalah "aplikasi mobile" yang biasanya menyediakan fitur yang sama, ada beberapa perbedaan dalam platform itu sendiri yang mempengaruhi implementasinya. Misalnya, bagaimana aplikasi melakukan tugas latar belakang. Bahkan hal serupa dapat mulai sangat berbeda dari waktu ke waktu (misalnya, berinteraksi dengan kamera).

Akibatnya, Anda tidak bisa hanya menulis kode sekali dan menjalankannya di platform lain. Anda perlu menghabiskan banyak waktu mengintegrasikan dan mengkode untuk platform tertentu, dan terkadang kode ini berakhir tepat di level C ++!

Penghematan teoritis dari menulis kode hanya sekali tidak sesuai dengan kenyataan, yang segera sangat mengurangi efektivitas pendekatan ini.

Overhead untuk mempekerjakan, melatih, dan mempertahankan pengembang

Terakhir, namun tidak kalah pentingnya, adalah biaya pelatihan dan / atau mempekerjakan pengembang untuk bekerja dengan tumpukan kami yang sangat aneh. Ketika Dropbox mulai menggunakan strategi seluler ini, kami memiliki kelompok inti pengembang C ++ yang berpengalaman. Grup ini meluncurkan proyek C ++ dan melatih pengembang seluler lainnya.

Seiring waktu, pengembang ini pergi ke tim lain dan perusahaan lain. Sisanya tidak memiliki pengalaman yang cukup untuk mengisi kesenjangan dalam kepemimpinan teknis, dan menjadi semakin sulit untuk menemukan insinyur berpengalaman dengan pengalaman C ++ yang relevan yang tertarik untuk mengembangkan perangkat seluler.

Akibatnya, kami dihadapkan dengan kurangnya pengetahuan kritis untuk mempertahankan basis kode C ++. Hanya dua opsi yang tersisa, dan masing-masing membutuhkan upaya signifikan:

1. Temukan dan rekrut kandidat dengan keahlian yang sangat spesifik (kami gagal selama satu tahun).
   
2. Latih pengembang seluler (atau C ++) Anda sendiri, yang hampir mustahil dilakukan jika tidak ada manula dengan keterampilan yang tepat untuk menyelesaikan pelatihan. Bahkan ketika kelompok utama belum bubar, pengembang seluler biasanya tidak tertarik pada C ++, jadi mencari orang untuk belajar juga merupakan masalah besar.

Selain perekrutan, rilis tumpukan teknologinya sendiri menciptakan masalah retensi - pengembang seluler tidak ingin bekerja pada proyek C ++. Ini menyebabkan banyak insinyur berbakat meninggalkan proyek alih-alih terus menderita dengan tumpukan kustom yang tidak terawat. Secara umum, komunitas pengembang seluler sangat dinamis - teknologi dan model baru sering muncul dan diimplementasikan dengan cepat. Insinyur papan atas senang menjaga keterampilan mereka tetap mutakhir.

Produk dewasa dengan tumpukan standar tidak mudah untuk selalu diperbarui. Anda mengorbankan hal baru untuk stabilitas. Masalah ini meningkat secara signifikan jika Anda mengunci diri di tumpukan kustom di luar ekosistem seluler yang lebih luas.

Kesimpulan

Sekali, menulis kode sekali untuk platform yang berbeda tampak seperti banyak, tetapi biaya yang terkait dengannya melebihi keuntungannya (yang dalam hal apapun kurang dari yang diharapkan). Pada akhirnya, kami tidak lagi menggunakan basis kode umum melalui C ++ (atau cara non-standar lainnya), tetapi menulis kode dalam bahasa asli kami untuk setiap platform.

Selain itu, kami ingin teknisi kami merasa baik dan dapat berkontribusi kepada masyarakat. Itulah sebabnya kami memutuskan untuk menerapkan praktik kami sesuai dengan standar industri.