Denis Neklyudov menarik bagi pengembang Android karena sejumlah alasan. Dia terlibat dalam Android Dev Podcast, berbicara di konferensi, menghadiri KTT GDE - secara umum, terlibat dalam kehidupan komunitas dalam berbagai cara. Dan karena dia sekarang tinggal di AS dan bekerja di Lyft, dia dapat membandingkan situasi barat dengan situasi Rusia.
Dan pada malam Mobius 2019 Piter, di mana ia
berbicara tentang "arsitektur dengan fokus pada penskalaan," kami bertanya kepadanya sedikit tentang semua ini. Bagaimana podcast Rusia menarik bagi pendengar Barat? Bagaimana rasanya bekerja di tempat ratusan pengembang seluler menghitung? Apa yang salah dengan solusi Google untuk pengembang Android? Dan apa yang salah dengan menggunakan smartphone secara umum?
Podcast
- Anda berpartisipasi dalam Android Dev Podcast , dan baru-baru ini Flutter Dev Podcast juga muncul - bagaimana ini "pemula" terjadi?- Awalnya, saya adalah troll Flutter yang paling penting. Mereka yang berada di KTT GDE tidak akan membiarkan Anda berbohong. Saya memberi tahu manajer Google utama secara langsung: jenis kerajinan apa ini, bagaimana Anda bisa meletakkannya di sebelah Android dewasa kita yang serius?
Tetapi beberapa bulan setelah saya mengatakan semua ini, mereka dibebaskan, saya sendiri mencoba semuanya dengan tangan saya sendiri, melihat apa yang dapat Anda lakukan, dan menyadari bahwa ini bukan mainan sama sekali.
Pada awalnya, kami merasa ada semacam mesin virtual, JavaScript. Dan ternyata semuanya dikompilasi menjadi kode asli, dan benar-benar bekerja dengan cepat pada kedua platform. Pada saat yang sama, penyetelan sudah cukup tua untuk platform eksperimental semacam itu. Dan ternyata bahasa Dart tidak terlalu buruk. Ya, ini bukan Kotlin yang akrab bagi kita, tetapi bahasa yang sangat dewasa dan bagus dengan semua pesona bahasa pemrograman modern.
Saya berubah pikiran dan menjadi jelas bahwa Flutter memiliki prospek. Bahkan React Native, Xamarin dan kerangka kerja pihak ketiga lainnya telah menyebar, dan di sini Google mendukung, dan bahkan rumor tentang sistem operasi Fuchsia baru, di mana Dart dan Flutter akan digunakan di tempat pertama.
Tapi kami tidak akan membahas semua berita Flutter di Android Dev Podcast. Dan kemudian saya punya ide bahwa akan menyenangkan untuk membuat podcast terpisah. Saya menoleh ke teman lama saya di universitas, Zhenya Saturov, mengatakan, “Apakah Anda ingin mengambil inisiatif? Saya tidak akan menarik podcast kedua, tetapi Anda lebih muda, mungkin Anda akan menerimanya. " Maka lahirlah Flutter Dev Podcast.
- Ketika perusahaan Google yang sama mengembangkan pengembangan Android asli dan Flutter, mungkin tidak jelas bagi pengembang pemula "baik, ke mana saya harus pergi." Apakah ini tampak seperti masalah bagi Anda?- Jika pemula tidak bisa memutuskan, biarkan mereka langsung menuju pengembangan game di Unity! Tapi serius, ada efek yang dijelaskan, tetapi Google telah duduk di dua kursi begitu lama: web dan asli. Ada hal-hal seperti Aplikasi Web Progresif yang juga sedang dikembangkan di Google. Tampaknya ada platform asli, mengapa Anda sibuk PWA Anda? Dan ada juga inisiatif seperti WebAssembly terkait dengan eksekusi segala sesuatu yang mungkin di browser (Google awalnya dari dunia web).
Karenanya, Google bukan yang pertama kali menciptakan lapangan kerja yang berbeda untuk berbagai kategori penyelesaian masalah yang sama. Ini adalah raksasa besar di mana di dalamnya ada perusahaan kecil yang berbeda berjuang satu sama lain. Oleh karena itu, tidak mengherankan bahwa ada persaingan dalam satu perusahaan.
- Melanjutkan topik podcast: perusahaan Lyft, tempat Anda bekerja, tahun ini memiliki podcast sendiri tentang pengembangan seluler. Apakah Anda ada hubungannya dengan ini?- Mereka memulainya sebelum saya datang: ketika perusahaan akan membuat podcast, itu bukan "direkam, ditata", tetapi proses panjang untuk menyepakati apa yang dapat Anda bicarakan, yang tidak dapat Anda bicarakan. Tetapi mereka berjanji untuk mengundang saya ke salah satu topik itu (mereka tidak memanggil tuan rumah).
Ada banyak podcast tentang pengembangan ponsel - baru-baru ini bahasa Rusia lainnya telah muncul. Saya berpikir bahwa semakin banyak ada, semakin baik: kualitas mereka yang ingin berada di atas semakin tinggi. Tetapi masalahnya jelas bahwa pendengar harus mengkonsumsi lebih banyak bahan. Ini sama dengan mitaps, konferensi, platform untuk laporan.
- Ada juga podcast The Context dengan Artyom Zinnatullin , dan karena Anda sekarang bekerja dengannya di perusahaan yang sama, pertanyaannya adalah, apakah Anda ingin bergabung.- Sejauh yang saya tahu, Artyom sudah ketinggalan beberapa edisi Konteks karena tingginya pekerjaan di tempat kerja. Tapi dia juga datang kepada kami di Android Dev Podcast dengan gembira, itu semua tergantung pada topik. Artyom tidak mengedit edisi, tetapi hadir dengan pendapat ahli. Dan saya sering suka mengedit, dan di sini kami melakukan hal-hal yang sangat berbeda.
- Ketika Anda terlibat dalam podcast berbahasa Rusia saat tinggal di luar negeri, apakah rasanya seperti dua kehidupan paralel, di mana podcast Anda tidak didengarkan di tempat kerja, dan di podcast Anda tahu sesuatu tentang pekerjaan Anda hanya dari kata-kata Anda?- Di Singapura, ini tidak terasa, tetapi di AS sangat terasa bahwa ini adalah dua dunia yang berbeda. Di Rusia mereka mengenal saya, nama saya sudah berbobot. Tidak ada yang mengenal saya di AS, dan menanggapi kata-kata "Saya punya podcast" mereka bertanya mengapa mereka tidak mendengarnya. Karena dia dalam bahasa Rusia. Di sini, tentu saja, saya kalah.
Karena itu, inisiatif pribadi saya adalah melakukan rilis podcast berbahasa Inggris, berbicara lebih banyak dalam bahasa Inggris untuk memperluas pemirsa. Apa yang kita diskusikan di Rusia sama relevannya di Barat, ada banyak ceruk yang tidak terisi. Tampaknya bagi saya bahwa topik yang kami angkat di podcast akan lebih baik untuk dibahas lebih sering di sini.
- Pendengar berbahasa Inggris sudah memiliki podcast seperti Terfragmentasi - menurut Anda apa yang bisa diberikan oleh Android Dev Podcast, yang tidak mereka miliki?- Saya selalu ingin percaya bahwa kita lebih dekat dengan pendengar. Kami tidak mencoba untuk bersikap objektif, dan seringkali opini pribadi kami tetap menjadi opini pribadi yang diungkapkan di depan umum. Tetapi pada saat yang sama, pendapat ini memiliki beberapa pengalaman hebat di belakang kami, dan kami tidak malu dalam pernyataan kami.
Mungkin di Barat itu tidak akan pergi, jadi Fragmented adalah podcast yang lebih disempurnakan, di mana ada sedikit pengetahuan mendalam, detail, dan kesulitan (yang banyak hanya tidak mengerti). Dalam mengejar sejumlah besar audisi untuk audiens yang luas, beberapa podcast menghapus topik kompleks untuk diskusi.
- Berbicara bukan tentang podcast, tetapi tentang pengembangan Android, apakah Anda merasakan perbedaan mencolok antara AS dan Rusia di dalamnya?- Saya kira begitu. Saya belum siap untuk menghakimi dengan ketat, tetapi perasaan utama (tidak sesulit di Singapura) adalah bahwa setiap orang sangat tertarik dengan profesi dan keterampilan mereka. Di sini, ketika perusahaan memiliki banyak pengembang pada platform yang sama, orang hanya duduk dan melakukan tugas mereka, bagi mereka Android bukanlah hidup mereka, bukan gairah mereka, bukan hobi mereka, tetapi hanya daftar tugas yang harus mereka laksanakan.
Skala besar dalam pengembangan ponsel
- Anda bekerja di perusahaan yang memiliki lebih dari seratus pengembang seluler. Apakah mereka terus-menerus mengajukan pertanyaan, "Anda memiliki aplikasi dari sekitar satu layar, apa yang harus dilakukan orang banyak di sana?"- Saya sendiri awalnya bertanya tentang ini. Jawabannya datang ketika Anda masuk ke dalam semua ini.
Pertama, kami tidak dapat mengatakan bahwa kami memiliki aplikasi satu layar. Untuk memulainya, ada dua aplikasi (pengemudi dan penumpang), dan kemudian, jika kita berbicara tentang pengalaman penumpang, maka kita memiliki aplikasi dengan mobil, skuter, sepeda, mobil otonom dan dengan chip yang berbeda untuk berbagai wilayah (pembayaran dan pengguna) .
Dan kedua, banyak kesulitan datang dengan skala. Ada banyak pekerjaan yang terkait dengan berpikir melalui metrik, membuat eksperimen, melacak bagaimana pekerjaan Anda sebelumnya berjalan. Skala dalam bentuk jutaan pengguna mempengaruhi waktu pengembangan, sekarang saya mengerti ini dengan lebih baik.
Kami dibagi menjadi sub-fungsional lintas-fungsi kecil, di mana setiap orang bertanggung jawab atas suatu bagian. Seseorang bertanggung jawab untuk perjalanan, seseorang untuk sepeda dan skuter, dan ini adalah bagaimana dua lusin tim yang berbeda terbentuk, di mana ada dua atau tiga pengembang. Saya bertanggung jawab atas bagian yang terkait dengan identifikasi pengguna. Dan saya ingin melihat kolega lain muncul untuk bagian ini, meningkatkan penghitung total kami.
Jika kita berbicara tentang pengembang aplikasi kecil, yang penuh di antara pembaca kita, ternyata kita hanya terdiri dari selusin aplikasi kecil di dalam satu aplikasi besar.
Situasinya serupa dalam banyak aplikasi besar. Dan pembagian ke dalam tim fitur, dan pengembangan berbasis metrik, di mana metrik mendorong segalanya, dan pendekatan startup, ketika kami pertama kali membuat MVP, dan kemudian membawanya ke keadaan yang baik: untuk beberapa itu adalah dalam bentuk seluruh produk, dan untuk seseorang dalam bentuk fitur internal. Bahkan Google menempatkan tim kecilnya sedemikian rupa sehingga mereka seperti startup, dan mencoba untuk meminimalkan birokrasi dan siklus pengembangan yang panjang.
- Dan seperti apa pekerjaan karyawan tertentu dalam situasi seperti itu? Bisakah Anda berbicara tentang beberapa tugas Anda yang banyak?- Butuh waktu dua bulan untuk membuat profil pengguna, meskipun tidak sulit dengan sendirinya. Layarnya sendiri baru, sebelumnya pengguna tidak memiliki profil, hanya ada pengaturan. Selain fakta bahwa itu perlu untuk menyelesaikan, ternyata dari sudut pandang arsitektur, beberapa komponen hilang, butuh saya untuk masuk ke arsitektur, bantu kawan-kawan.
Saya juga memutuskan untuk bereksperimen dengan Belati, juga butuh waktu. Itu juga perlu untuk memikirkan metrik, membangun dashboard, mengumpulkan analitik dari keberhasilan percobaan, butuh waktu. Kemudian saya mulai menambahkan layar yang ada dari pengaturan ke layar internal profil dan memperbarui.
Memperbarui sesuai dengan "aturan kepanduan" diperlukan refactoring apa yang disentuh. Refactoring untuk arsitektur terbaru juga membutuhkan waktu. Plus kami memiliki sistem desain, dan beberapa komponen tidak diimplementasikan dari elemen yang disetujui terbaru. Apa yang harus menunggu tim yang menulis elemen-elemen ini, saya mengambil dan membantu mereka untuk menyalin pekerjaan mereka kepada mereka, agar tidak diblokir.
Dari semua ini, dua bulan kerja terbentuk, yang pada pandangan pertama tampak beberapa minggu.
- Ketika Anda ingin "bereksperimen dengan Belati" selama tugas, apakah eksperimen seperti itu dianjurkan?- Tergantung pada tingkat insinyur. Saya pikir jika dia adalah insinyur entry-level, maka dia dan manajer memiliki pemahaman yang jelas bahwa dia tidak terganggu oleh eksperimen arsitektur, karena dia sendiri masih hijau untuk ini.
Dan dari para insinyur yang berpengalaman, secara langsung dalam tanggung jawab mereka untuk berkontribusi pada sesuatu yang luas: di seluruh organisasi, atau setidaknya di seluruh aplikasi. Oleh karena itu, tidak ada tempat untuk pergi: bahkan jika tidak terlalu menarik untuk terlibat dalam arsitektur, tetapi ingin berkembang, Anda harus menghubungkan hidup Anda dengan sesuatu yang lebih dari sekadar fitur.
- Dan jika Anda bereksperimen, dan hasilnya berhasil, maka itu menjadi kebijakan umum, atau bisakah tetap di dalam tim?- Sangat jarang, itu tetap di dalam satu tim. Biasanya, jika seseorang memulai percobaan, ini segera konsisten dengan tim arsitektur inti dan selanjutnya dianggap sebagai praktik umum yang baik. Sebagai contoh, sekarang dua tim sedang bereksperimen dengan Redux secara paralel untuk memahami siapa di antara kita yang akan menang, yang solusinya akan lebih universal, dan kita akan mulai menggunakannya di seluruh perusahaan.
- Peningkatan jumlah orang dalam sebuah tim juga merupakan pertumbuhan "kertas kerja" ketika Anda tidak membuat kode, tetapi melakukan sesuatu yang terkait. Sudah jelas bahwa ini perlu, tetapi berapa banyak ini memperlambat pengembang dibandingkan dengan bagaimana dalam proyek kecil ia akan "hanya menampilkan"?- Sekali lagi tergantung pada tingkat insinyur. Jika insinyur menengah atau pemula, maka tidak ada persyaratan baginya untuk menulis banyak dokumen, ia duduk dan mencari fitur di bawah pengawasan insinyur seniornya. Tetapi insinyur senior sudah mendapatkan tanggung jawab manajerial, seperti di perusahaan lain mana pun. Dia tidak dapat berbicara dengan bosnya jika ini adalah startup, atau menulis dokumen untuk manajernya, jika ini adalah perusahaan besar.
- Ketika Anda membuat aplikasi Android untuk taksi, apakah masalah dan masalah saat ini hampir sama dengan aplikasi besar lainnya, atau apakah Anda memiliki spesifikasi sendiri?- Masalah yang kita hadapi sangat mirip. Misalnya, masalah perakitan multi-modul menambah insinyur infrastruktur kekhawatiran yang sama setiap hari, sehingga tidak mengherankan bahwa Uber, Facebook, Airbnb, dan Lyft menggunakan sistem pembuatan Buck yang sama.
Yang lain juga melihatnya, mencapai skala kami, dan ini menegaskan bahwa masalahnya sama. Secara paralel, proses yang sama terjadi - misalnya, semua perlahan menjadi reaktif. Yah, seseorang lebih konservatif, seseorang masih memiliki panggilan balik, tidak ada reaktivitas, dan bahkan tidak ada Kotlin, karena skala dan kualifikasi pengembang tidak mengizinkan ini.
Perbedaan dari situasi di CIS adalah bahwa kita sering pergi ke satu sama lain dan berkata: "Teman-teman dari Gradle, bantu sesuatu." Artinya, sementara CIS menggunakan alat yang ditulis di Lembah, di sini kami juga terus berkomunikasi satu sama lain.
Apakah Google benar?
- Baru-baru ini, Jake Wharton memiliki sejumlah kritik terhadap solusi Google untuk pengembangan Android, dan Anda setuju dengan beberapa di antaranya. Menurut Anda apa yang salah yang dilakukan Google?- Ada diskusi bahwa tidak perlu memanggil ViewModel dan memasukkan konteks ke dalamnya. Dengan ini, saya pikir, banyak juga yang akan setuju. Saya sangat kesal karena banyak yang menganggap perpustakaan dari Google sebagai sumber yang tidak dapat disangkal dan paling benar.
Calon datang ke wawancara kami, dan 9 dari 10 menggunakan Komponen Arsitektur Android untuk menyelesaikan tugas yang kami tetapkan bagi mereka untuk menggambarkan desain aplikasi yang akan mereka tulis. Di sini saya tidak bisa tidak setuju dengan Jake bahwa ViewModel memiliki masalah kontroversial, meskipun semua orang sangat menyukai siklus hidup tersebut.
Adapun perpustakaan Binding Data, Android Summit adalah indikasi musim gugur ini, di mana pada obrolan api unggun lima dari sepuluh pertanyaan adalah tentang sesuatu yang tidak berfungsi di Binding Data. Alat ini terlalu kuat, dan menurut pendapat pribadi saya, itu tidak pernah diingatkan untuk multi-modul dan perakitan cepat. Tetapi pada saat yang sama, semua orang menganggapnya sebagai kebenaran.
Sebenarnya, ini cukup mudah, tetapi Google, menurut saya, tidak mengalokasikan sumber daya yang cukup untuk terus mendukungnya. Dan kemudian komunitas tersebut membentak: mereka mempercayai Google, tetapi kami tidak mendapatkan cukup dukungan.
"Beberapa orang tidak senang bahwa banyak solusi Google telah muncul hanya dalam beberapa tahun terakhir:" Sendok yang baik untuk makan malam, Anda sudah bungkuk selama bertahun-tahun dan masyarakat sudah mengetahuinya, tetapi sekarang Anda sudah bangun. " Apa yang Anda pikirkan tentang ini? Mengapa perusahaan berperilaku seperti ini dan itu buruk?- Saya melihat semua ini dari sudut pandang alokasi anggaran dan dari sudut pandang strategi beberapa manajer yang lebih tinggi terpisah yang sebelumnya memiliki satu sudut pandang atau hanya orang lain, tetapi sekarang mereka telah berubah dengan pendekatan yang berbeda.
Artinya, ini bukan Google, tetapi hanya beberapa orang yang membuat keputusan dalam tim alokasi sumber daya Android. Jadi mereka mendapatkan sumber daya, pengembang, dan perpustakaan yang ingin melakukan hal itu - ada solusi dari Google. Dan sangat bagus mereka muncul! Saya lebih kesal untuk komunitas yang tanpa syarat percaya apa yang mereka katakan dan tidak memberikan penilaian kritis.
- Google, dalam tutorial video pengembangan Android terbaru tentang Udacity, menyediakan campuran hal-hal dasar yang dibutuhkan semua orang dan solusi seperti Data Binding. Apakah Anda melihat masalah di mana pemula yang tidak terbiasa dengan konteks akan menganggap mereka sebagai kebenaran yang tak terbantahkan, dan bukan sebagai opsi opsional?- Kursus video tentang Udacity adalah cerita terpisah. Saya sudah terbiasa dengan kursus Android di sana sejak 2016, ketika kami melakukan kursus Study Jam pertama pada mereka. Di sana, secara umum, semuanya berjalan dengan sempurna, hal-hal dasar dijelaskan dengan sempurna. Namun dari delapan pelajaran dalam kursus ini, dua di antaranya berada di topik ContentProvider yang tidak dapat dicerna, tidak dapat dilewati, dan sangat kompleks. Mengapa seorang pemula tahu bagaimana ContentProvider terstruktur, sudah pada tahun 2016 itu tidak jelas.
Saya masih memiliki pertanyaan tentang bagaimana mereka menyusun topik dan aksen tempat. Karena itu, kata-kata yang semuanya campur aduk di sana sekarang, jangan mengejutkan saya sama sekali. Tetapi kursus video, layak membayar upeti, umumnya selalu menjadi topik yang rumit. Mereka menjadi usang segera setelah Anda mengeluarkannya.
Sangat sulit untuk menyiapkan bahan berkualitas baik. Ada banyak tempat di komunitas tempat Anda bisa mendapatkan sumber pembaruan terbaru dan pemahaman tentang apa yang terjadi dan bagaimana. Tetapi jika pemula membaca kami - pergi bekerja di perusahaan mana pun yang bergerak dalam pengembangan ponsel, di sana Anda akan segera diajarkan cara melakukan semuanya dengan benar. Sesuatu yang kurang lebih relevan, beri tahu, dari mulut ke mulut.
- Di sini, para pemula akan memiliki pertanyaan "bagaimana menuju ke sana tanpa pengalaman, jika Anda belum menghabiskan satu tahun selama kursus."- Ini pertanyaan yang sangat bagus. Saya percaya bahwa banyak perusahaan yang memadai akan mengambil ilmu komputer untuk pengetahuan dasar tanpa mengetahui kerangka apa pun. Karena Anda selalu dapat menemukan kerangka, dan mendapatkan pengetahuan dasar tentang penyelesaian algoritma, pengetahuan pemrograman berorientasi objek dan hanya penilaian yang memadai sulit didapat. Ini adalah dasarnya. Dengan fondasi Anda akan dibawa. Dan jika Anda juga memiliki bahasa Inggris, maka pintu-pintunya umumnya terbuka untuk Anda.
- Sebelumnya, Anda tertarik pada platform Android Things, dan baru-baru ini semuanya menjadi agak menyedihkan baginya. Kesimpulan apa yang harus kita tarik dari sejarah? Bahwa Anda tidak akan pernah bisa sepenuhnya memercayai perusahaan besar dan Anda perlu menggunakan platform apa pun dengan harapan bahwa esok hari tidak akan terjadi?- Kesimpulan - bahwa kita perlu memantau tren. Ini bukan tahun pertama bahwa ada tren bahwa perangkat elektronik apa pun, apakah itu penyedot debu atau microwave, mulai dikendalikan dari awan, seolah-olah kita, orang paranoid, tidak sedih dengan hal ini.
Android Things sebagai platform terlalu kelebihan untuk tugas-tugas Android sederhana, sementara itu tidak banyak membantu dalam hal cloud atau semacam pembelajaran mesin (karena, sekali lagi, masalah kinerja). Ini menunjukkan bahwa Android Things tidak terlalu keren. Tetapi saya sendiri adalah orang yang sampai saat terakhir percaya bahwa platform ini setidaknya merupakan solusi untuk masalah-masalah yang sulit diperbaiki oleh potongan-potongan besi dengan Kickstarter. Google setidaknya akan memperbarui sistem operasi dan merilis patch keamanan.
, : , Google Cloud Next , IoT Google - , — .
— , , . ?— Telegram- , , TikTok —
, - — . — . — , .
— , . , , .
— , TikTok ?— - , - , . , , — . , .
— 90 Seconds, — ? ?— . , . , Telegram, WhatsApp Google Docs, . B2B-, , . , , , — .
— , , . Twitter, — , ?— , , Telegram. , . , Twitter.
— : Mobius?— , . , over engineering, , .
, , , 60 ( Android). — , . , «2-5 2 » .