Berapa banyak aplikasi Rusia di Google Play yang mengatakan "50.000.000 instalasi"? Jelas, setiap kasus seperti itu adalah kisah unik dengan kekhasannya sendiri, sehingga akan menarik untuk berbicara dengan pengembang. Dan ketika aplikasi seperti itu juga memiliki peringkat 4,6, ini memperkuat minat.
Vladimir Tebloev adalah salah satu orang yang bekerja pada aplikasi Android
Sberbank Online . Pada musim semi, ketika Sberbank Technologies berpartisipasi dalam konferensi
Mobius kami, ia membuat laporan di sana, dan sekarang kami memutuskan untuk bertanya kepada Vladimir tentang fitur karyanya.
- Pertama, beri tahu kami apa yang sebenarnya Anda lakukan?- Dalam aplikasi Sberbank Online, saya terlibat dalam layanan Dialog, yang memungkinkan pengguna untuk mentransfer uang dalam satu klik dan melihat seluruh riwayat transfer dalam tampilan penuh. Layanan ini tersedia untuk semua pengguna aplikasi - sekarang jumlahnya 37 juta orang.
Saya telah bekerja di SberTech sejak musim panas 2016 - kemudian, sebagai bagian dari aplikasi, masih belum ada pembagian ke dalam tim yang terpisah. Dan kemudian, ketika, sebagai bagian dari transisi menuju gesit, mereka mulai menugaskan tim yang berbeda untuk memisahkan modul aplikasi, salah satu yang pertama adalah tim Dialog, dan sejak saat itu saya berada di dalamnya.
- Setiap orang memiliki kata "Sberbank" dan "pengembangan ponsel" yang terkait dengan Sberbank Online. Tetapi di perusahaan sebesar itu, apakah mungkin juga ada pengembangan ponsel internal? Apakah berbeda dari luar?- Ya, ada juga aplikasi untuk penggunaan internal. Saya tidak ada hubungannya dengan mereka, tetapi saya tahu bahwa React Native aktif digunakan di sana. Pengembangan internal memiliki persyaratan sendiri: tidak ada tinjauan desain yang ketat dan animasi yang canggih, pengembangan lebih cepat menggunakan solusi lintas platform.
Ketika keahlian tumbuh, itu akan mungkin untuk menerapkannya pada aplikasi "pertempuran". Meskipun fakta bahwa Sberbank Online akan dapat secara aktif menggunakan pengembangan lintas-platform, saya ragu. Ada banyak kesulitan, dan ketika Anda memiliki puluhan juta pengguna, bahkan masalah langka dapat melukai banyak orang.
- Dan bagaimana "bahkan masalah langka ini melukai banyak orang" mempengaruhi pekerjaan? Apakah Anda harus berurusan dengan beberapa masalah eksotis yang mungkin dilewatkan oleh aplikasi kecil di bawah radar?- Terkadang ada masalah pada beberapa perangkat "khusus". Pada satu kebiasaan, tetapi firmware yang meluas, itu melesat keras, dan kami harus mengetahuinya untuk waktu yang lama. Ternyata masalahnya ada pada driver motherboard perangkat itu sendiri - ia mencoba untuk meniru perpustakaan di bawah ARMv5, walaupun proyek itu hanya untuk ARMv7.
Ketika ada banyak pengguna dan harga kesalahan tinggi, ini mengarah pada fakta bahwa semuanya perlu diluncurkan "sedikit", dengan hati-hati mengikuti laporan. Jika sesuatu naik di sana, kami segera berhenti bergulir dan membuat perbaikan terbaru. Selain menggulirkan "dengan persentase pengguna tertentu", kami juga secara geografis meluncurkan semua bagian: Sberbank memiliki konsep "bank teritorial", dan fitur-fitur secara bertahap dapat diluncurkan berdasarkan wilayah.
- Meskipun beberapa startup hipster dapat membuat MinSdkVersion tinggi dan mengatakan "semua orang bukan audiens kami", Anda memiliki situasi yang berbeda, Anda tidak dapat melambai kepada orang-orang. Berapa nilai MinSdkVersion Anda saat ini?- Sekarang umur 16, dan kami mengangkatnya secara harfiah tahun lalu dari 14. Kami melihat jumlah pelanggan dengan SDK tertentu, dan kami dapat menaikkan versinya jika menjadi kurang dari 5%. Sejauh ini, kami memiliki banyak pengguna di Android 4.4 KitKat, sekitar 16% - kami perlu mendukung mereka.
- Apakah ada versi baru yang sedang Anda lihat saat ini dan berpikir, "Begitu kita meningkatkan MinSdkVersion, apakah kita langsung menggunakannya?"- Tentu saja, saya ingin menaikkan API minimum kami ke Android 5.0 untuk memanfaatkan sepenuhnya inovasi seperti, misalnya, animasi transisi, yang akan bekerja secara memadai dan di mana saja. Tetapi, pada prinsipnya, ini tidak berlaku untuk fungsionalitas penulisan, logika bisnis, jadi ini tidak kritis. Secara umum, animasi dikerjakan oleh desainer kami, yaitu dapat diterapkan secara manual. Jadi masalah ini tidak kritis, ini berkaitan dengan kenyamanan, "ketenangan pikiran" dari pengembang.
Ada beberapa kasus di mana kami memeriksa versi, misalnya, menyematkan SSL. Ini bekerja secara berbeda di berbagai versi Android, jadi kami menerapkan dua versi kode, untuk perangkat Android "hingga 4.4" dan "dari 4.4".
Tentu saja, saya ingin "hanya mengembangkan untuk Android P dan tidak memikirkan apa pun" - tetapi ini selalu terjadi, tidak ada cara untuk mencapai apa pun.
- Untuk pinning SSL yang disebutkan. Jelas, masalah keamanan sangat penting bagi bank. Dan bagaimana ini memengaruhi Anda, bagaimana pekerjaan Anda berbeda dari bekerja pada aplikasi non-perbankan?- Ini fitur pendekatan yang sangat ketat untuk data pribadi pengguna. Setiap kebocoran adalah risiko besar. Kami memiliki departemen keamanan yang menguji aplikasi kami sebelum setiap rilis. Jika ada komentar, kerjakan mereka meneruskannya ke tim yang bertanggung jawab atas fungsionalitas dengan kerentanan yang ditemukan.
Di perusahaan kecil, saya pikir, sering tidak ada departemen keamanan yang akan mem-pentest aplikasi. Jika beting ditemukan, mereka dapat muncul di w3bsit3-dns.com atau sumber daya serupa.
Juga terkait dengan keamanan adalah bahwa aplikasi kami menggunakan antivirus. Beberapa pengguna tidak senang dengan kehadirannya, tetapi pengenalan antivirus telah memberi kami pengurangan penipuan yang sangat nyata. Misalnya, di bank SMS kami, tempat Anda dapat menulis SMS "jumlah transfer ke kartu X," dengan antivirus, tingkat penipuan dalam arah ini dikurangi seminimal mungkin.
- Demi alasan keamanan, bank membatasi fungsionalitasnya untuk smartphone yang di-root. Apa yang dilarang untuk Sberbank Online untuk perangkat yang di-rooting?- Pada bulan Juni, kami meninggalkan fungsi terbatas untuk pemilik perangkat dengan hak root. Sekarang semua pengguna Sberbank Online di Android memiliki fungsionalitas penuh. Pada saat yang sama, perlindungan tetap pada tingkat yang sama berkat sistem pemantauan penipuan.
- Dan atas nama keamanan, perlu untuk membatasi sesuatu yang bukan pengguna, tetapi diri mereka sebagai pengembang, menolak jika mereka akan menggunakannya?- Ketika pada tahun 2015 kami ingin memperkenalkan Retrofit, ia memiliki masalah dengan kebingungan, ia bekerja secara bengkok dengan obfuscator standar. Departemen keamanan kami menunjukkan kerentanan ini, penuh dengan serangan dunia maya di bank dan risiko melanggar kode, ketika API mencuat. Lalu kami meninggalkan Retrofit dan masih tidak menggunakannya. Sejauh yang saya tahu, sekarang masalah dengan obfuscator standar sudah diperbaiki di sana. Tetapi sejak kami menulis klien HTTP kami sendiri, ia berfungsi dan memuaskan semua orang, banyak pembungkus telah ditulis untuk itu untuk tim yang berbeda yang bekerja dengan server yang berbeda. Tidak ada gunanya mengubahnya ke Retrofit.
- Pertanyaan yang tak terhindarkan: apa yang Anda miliki dengan Kotlin?- Kita menuju ke arahnya, tapi santai. Kesulitannya adalah banyak pengembang Android dari berbagai tingkatan segera mengerjakan aplikasi, seseorang mengenal Kotlin dengan sempurna, seseorang tidak. Secara umum, tidak ada hambatan yang tidak dapat diatasi untuk implementasi, tetapi sekarang kami memiliki kekurangan pengulas untuk menonton kode Kotlin. Jika kita semua mulai menulis besok dengan tiba-tiba di Kotlin, maka orang-orang akan "merobek" berdasarkan permintaan. Selain itu, dalam kasus Kotlin, ada masalah dengan penganalisa kode statis, yang digunakan dalam pipa kami.
Jadi Kotlin diimplementasikan dalam langkah-langkah kecil: misalnya, kami menulis tes di Kotlin dan menggunakan kelas data (jadi kami menghemat waktu agar tidak menulis tes untuk getter, setter, equals (), hashCode () dan sebagainya).
Sekarang perlahan-lahan berjalan, dan pada langkah berikutnya kami ingin menulis DSL kami untuk pengujian di Kotlin. Dan secara paralel, kami ingin meningkatkan tingkat pengetahuan Kotlin di perusahaan: misalnya, dengan bantuan mitaps.
- Dalam hal "Dialog" Anda terlibat dalam pengiriman pesan, tetapi bukan analog langsung dari WhatsApp. Dan itu menarik: seberapa bermanfaat solusi orang lain bagi Anda? Apakah Anda menggunakan messenger open source dalam kode?- Itu berguna ketika kami ingin menambahkan emotikon. Kami punya pertanyaan bagaimana membuat panel dengan mereka, dan di open source kami melihat opsi di mana semuanya mudah diselesaikan dengan pop-up di atas keyboard. Kemudian semuanya menyatu dalam ketinggian, dan ternyata mulus bagi pengguna.
Tetapi secara umum, melihat keputusan orang lain tidak selalu baik, lebih efisien untuk membentuk keputusan Anda sendiri, dengan mempertimbangkan pengalaman orang lain. Sebagai contoh, lebih baik untuk tidak melihat Telegram sama sekali, karena karena besarnya jumlah kelas dalam
kode sumber aplikasi Android mereka, tidak mudah untuk mengetahuinya. Kami mencoba untuk melakukannya sendiri, terutama karena interaksi dengan server dapat berbeda: dalam Telegram yang sama dengan MTProto, kami memiliki WebSockets yang biasa.
- Saya seorang pewawancara yang malas, jadi saya memutuskan untuk hanya mengambil daftar hal-hal yang berhubungan dengan Anda di tempat kerja, dan bertanya tentang setiap item "beri tahu kami dengan tepat bagaimana hal ini terjadi."
Poin pertama: Anda berada di "arsitektur modul aplikasi". Kami sudah mengatakan tentang fakta bahwa aplikasi ini dibagi menjadi beberapa modul - apa lagi yang bisa Anda katakan tentang arsitektur?- Ini sedang berkembang berulang-ulang bersama kami, versi sedang berlangsung, sekarang kami telah mencapai versi ke-17.
Pada tanggal 16, Arsitektur Bersih diperkenalkan. Kami sepakat siapa yang bertanggung jawab untuk apa (presentasi, domain, lapisan data), entitas mana dan di mana harus digunakan, di mana seharusnya konverter - secara umum, mereka melukis semua masalah arsitektur dan mengimplementasikannya.
Diimplementasikan sebagai berikut: semua fitur baru harus ditulis pada arsitektur baru kami. Jika dalam permintaan tarikan sesuatu menyimpang dari norma yang ditetapkan, maka permintaan tarikan tersebut berlaku untuk revisi. Tetapi pada saat yang sama, mereka tidak segera bergegas untuk melihat semua fungsi lama, karena ini dapat menyebabkan banyak masalah.
Untuk lapisan presentasi, kami memilih standar MVP, tetapi beberapa tim kami menggunakan MVVM. Di lapisan presentasi, kita tidak dibatasi oleh apa pun. Misalnya, kami melihat obrolan kami di MVI - lebih tepatnya, tentang penerapan MVI kami yang menarik, yang pada dasarnya berbeda dari apa yang ditulis pengembang Mosby.
Kemudian kami beralih ke versi 17 arsitektur dan mengimplementasikan RxJava, yang memerlukan perubahan arsitektur. Jika kita menggunakan definisi yang ketat, sekarang arsitektur kita telah berubah menjadi heksagonal, dari Clean kita telah “bercabang”. Tetapi keduanya serupa karena keduanya bekerja sesuai dengan prinsip-prinsip SOLID, sehingga satu mengalir ke yang lain dengan cukup lancar. Sekarang kami sedang mengerjakannya.
Dalam versi arsitektur yang akan datang, kami ingin mengabaikan kerangka Moxy yang digunakan untuk mengimplementasikan MVP, karena menyebabkan beberapa kesulitan. Proyek ini besar, menggunakan pemrosesan anotasi, dan ketika membuat perubahan pada modul "level bawah", waktu pembuatannya besar. Dan kami berusaha untuk membuat hidup lebih mudah bagi pengembang kami.
- Poin kedua adalah "optimalisasi kerja dan konsumsi memori." Seberapa akut pertanyaan ini, apakah saya harus terus-menerus memikirkannya untuk pengguna dengan perangkat yang lebih lama?- Masalah ini adalah fokus tim platform, mereka sedang mengembangkan alat yang menggunakan fitur tim. Kebutuhan untuk melakukan ini, sebaliknya, muncul sebagai kebutuhan untuk salah satu tim. Misalnya, di tim Dialog, pada tahap awal pengembangan, obrolan sangat lambat. Kemudian saya harus menyingsingkan lengan baju saya, mulai dengan profiler, melihat di mana kemacetan dalam aplikasi itu, mencari tahu alasan terjadinya mereka.
Dalam hal optimasi, misalnya, kami meninggalkan PNG dan secara bertahap membersihkannya dari proyek agar hanya menggunakan vektor. Optimalisasi grafik ketergantungan di Belati direncanakan untuk tahun ini untuk mempercepat permulaan aplikasi yang dingin.
- Mari kita beralih ke pertanyaan pengujian: bagaimana hal itu terjadi dengan Anda?- Saya hanya dapat berbicara tentang tim kami, di pihak lain proses ini dapat dibangun secara berbeda.
Tim kami awalnya memiliki satu penguji. Selanjutnya, ia menjadi bosan hanya dengan pengujian. Dan dia mulai meminta kami untuk membantu menangani penulisan unit test. Kami menunjukkan kepadanya bagaimana menulis tes untuk database, pada dasarnya, untuk parsing - dan dengan cara ini dia menurunkan kami, menghapus sebagian dari pekerjaan dari kami. Ini bagus: dia tertarik, dan kita.
Seiring waktu, kami sampai pada kesimpulan bahwa kami perlu mengotomatiskan regresi, kami perlu menulis tes UI. Pada awalnya, saya dan mitra saya mengerjakan tes UI, dan kemudian departemen kualitas bergabung dengan kami - penguji kami yang menguji backend di masa lalu. Mereka tahu Java, dan sekarang mereka terhubung ke proyek kami untuk mengotomatiskan seluruh regresi. Kami duduk dan mempertimbangkan solusi yang: Appium, Espresso, Selenium.
Kami berhenti di Espresso dan mulai mengembangkan pendekatan bersama. Untuk memfasilitasi pengujian, kami mengembangkan kerangka kerja kami sendiri, seperti Kakao. Kami memulai pekerjaan ini pada awal 2017, dan sekarang kami memiliki kerangka kerja yang besar, dan sebagian besar tes dikumpulkan sebagai konstruktor, karena banyak pertandingan dan permainan aksi telah ditulis untuk berbagai situasi.
Sekarang penguji kami secara aktif meminta kami untuk mengajari mereka cara menulis tes UI, karena lebih mudah untuk menulis tes sekali, daripada "menembus" tindakan yang sama pada lima perangkat. Tetapi, tentu saja, Anda tidak mengotomatiskan semuanya, dan beberapa kasing masih perlu diperiksa secara manual.
Adapun pengembang, retrospektif diadakan di tim kami setiap dua minggu. Di salah satu dari mereka, kami sampai pada kesimpulan bahwa pengembang harus melakukan setidaknya pengujian alpha setelah mereka menulis fitur. Agar tidak keluar bug apa pun sepenuhnya dasar dari bentuk "aplikasi crash saat startup". Dengan demikian, para pengembang juga terhubung ke pengujian. Ketika kami sedang mempersiapkan rilis utama dan kami perlu dengan cepat menguji fitur tersebut, semua orang duduk untuk regresi dan bersama-sama melewati tes regresi. Ketika bug terdeteksi, pengembang memutuskan sambungan dari regresi, memperbaiki dengan cepat, dan lagi.
- Item berikutnya: ulasan kode. Apakah Anda memiliki spesifik, atau "seperti orang lain"?- Ada kekhususan yang disebabkan oleh jumlah pengembang. Ketika ada sepuluh pengembang seluler dalam suatu perusahaan, maka dua atau tiga orang dapat meninjau semuanya. Dan bagaimana cara merevisi kode ratusan orang? Kami mengembangkan "matriks ulasan". 20-30 orang dipilih, tentang siapa yang kita tahu pasti bahwa mereka dapat mempublikasikan, meninggalkan umpan balik, dan menyelesaikan poin kontroversial dalam komentar. Mereka membawa orang-orang ini dan membagi semua tim di antara mereka.
Mengapa sebuah matriks? Ini untuk memastikan bahwa semua pengulas memiliki beban yang sama. Bagaimana ulasannya? Tim kami membutuhkan setidaknya tiga penilaian. Yang pertama adalah dari seseorang di tim. Yang kedua - dari seseorang dari luar, dari tim yang tidak berurusan dengan fungsi ini. Dan appruv ketiga - dari seseorang dari tim yang berdekatan. Dalam kasus kami, ada beberapa perintah terkait, dan semuanya melihat kode kami. Nah, karenanya, semua build harus dikumpulkan: tes unit dan tes UI harus lulus tanpa masalah. Jadi kami memiliki ulasan kode.
- Poin berikutnya adalah refactoring dari kode legacy. Seberapa sistematis hal itu terjadi: tepatnya dengan tugas-tugas yang direncanakan, atau "apakah Anda perlu melakukan perubahan pada kode lama - pada saat yang sama memperbaikinya"?- Secara umum, kami memiliki "prinsip pramuka" yang khas: jika Anda menyentuh sesuatu yang lama - berbaik hati untuk melakukannya dengan benar, Anda sekarang adalah rekan penulis. Tetapi ada refactoring yang direncanakan juga. Misalnya, untuk Dialog, refactoring dari dua arah diperlukan: buku kontak yang kami gunakan dan terjemahan. Buku kontak diambil, dibersihkan, ditulis ulang seluruh database di Kamar, dilakukan dalam modul terpisah. Dan pembayaran kami telah ditulis sejak lama menggunakan RoboSpice, jika Anda masih ingat ini, dan itu merugikan kami. Saya harus mengatakan, memotong ini adalah tugas yang tidak menyenangkan, karena ada banyak ikatan dengannya. Dan Anda harus membersihkannya secara halus, agar tidak merusak fungsi lainnya.
- Bahkan di Sbertekh, Anda terlibat dalam programer pelatihan. Seperti apa pelatihan di dalam perusahaan?- Sejak September, direncanakan untuk melaksanakan program seperti pelatihan ulang karyawan internal. Sekarang kami telah menentukan berbagai topik di Jawa dan Android. Misalnya, kami memiliki javascript, javist, dan analis yang ingin berlatih ulang di Android. Sekolah seperti itu akan diselenggarakan untuk mereka, di mana akan ada studi terfokus, sesuai dengan jadwal dan dengan kuliah.
Dan sekarang kami secara teratur mengadakan mitaps. Pilihan topik untuk mereka tidak sama dengan di konferensi, di mana sesuatu yang baru dan hype diperlukan. Misalnya, jika kita tahu bahwa pengembang memiliki masalah dengan sesuatu, penting untuk membicarakannya. Dari yang terbaru - salah satu pengembang kami berbicara tentang grafik vektor. Bukan hanya tentang perpustakaan tertentu yang menggambar vektor dengan indah di Android, tetapi mulai dengan bagaimana grafik vektor bekerja secara umum, dan kemudian berlanjut ke yang pribadi. Mereka berbicara tentang Room, dan tentang Java concurrency, yang banyak bermasalah dengan pengembang, dan tentang Dagger 2.
Tahun lalu, kami memiliki sekolah pengembangan Android, dan kami mempekerjakan mereka yang berhasil menyelesaikannya. Orang-orang seperti itu tidak boleh langsung terhubung ke beberapa proyek dan dibiarkan memasak sendiri. Oleh karena itu, seorang mentor ditugaskan untuk setiap karyawan pendatang baru dan juga kepada junior, yang akan membimbingnya, mengembangkan dan membantunya. Ini adalah pembelajaran internal.
- Wawancara: apakah Anda memilikinya "seperti orang lain", atau adakah kekhususan?- Saya dulu berpikir bahwa "seperti orang lain", tetapi pada akhirnya ternyata mereka masih sedikit istimewa. Dalam pengalaman saya, ada tiga pendekatan umum di pasar. Yang pertama ditanyakan pada tiga atau empat topik dan hanya dievaluasi pada mereka. Sebagai contoh, saya datang ke perusahaan sebagai pengembang Android, dan saya dianggap sebagai orang yang harus memiliki pengetahuan yang sangat baik tentang algoritma dan sinkronisasi di Jawa, dan pada saat yang sama tidak menghargai apa yang saya lakukan di perpustakaan super. , , - . — , 30-40 . , , . — - . , , . , .
, : , OOD (Object Oriented Design, ), Java Core Android SDK. . , , . : , , - . . , , , Dagger 2, RxJava. , Kotlin. , . - , , , . , .
— « ». - , .— — RxJava, , . , , . .
Retrofit, : , , . , — .
TinyMachine - — , , , . , «» , , . -, , - rocket science, .
— : . , , ?- Ya. — Java-. « »: Java- — - («» — Android-: , , , ). , , , — Java-. , . , , , , « payment? payment payment ? paymentTest?».
, Confluence. , material design , - , . , , Confluence. , , , , , , . : RxJava Confluence best practices — , , . : , .
, . Confluence 200 . . Confluence, , , .
