Masalah apa yang muncul saat menambah tim seluler sebanyak 10 kali? Untuk alasan apa, di perusahaan yang sama, pengembang Android lebih suka menggunakan perpustakaan terkenal, dan di iOS mereka sering menulis solusi mereka sendiri? Seperti apa kehidupan pengembang ponsel di fintech?
Pusat Teknologi Finansial ikut serta dalam konferensi Mobius kami, dan dalam hal ini, kami bertanya kepada dua karyawan CFT:
Kirill Zuev bertanggung jawab atas iOS, dan
Mikhail Emelyanov bertanggung jawab untuk Android.
Teks tersebut ternyata berkembang sangat luas sehingga kami bahkan membuat daftar isi sehingga mudah untuk pergi ke bagian tertentu:
Tentang perusahaan
JUG.ru Group: Pertanyaan pengantar: beri tahu kami tentang perusahaan dan apa yang Anda lakukan secara pribadi di dalamnya.Kirill : Tidak mungkin dikatakan secara singkat, karena area bisnis CFT sangat beragam. Tetapi cobalah "sentuhan besar" tentang produk dan layanan paling populer.
CFT telah beroperasi di pasar fintech Rusia selama dekade ketiga, dan kami mengatakan bahwa kami melakukan fintech ketika konsep seperti itu tidak ada.
Saat ini, CFT adalah pemrosesan dan produksi perangkat lunak untuk sejumlah besar berbagai organisasi keuangan, perusahaan asuransi, perusahaan negara, dan ritel.
Ini adalah ekosistem Golden Crown, yang mencakup kumpulan layanan dalam format b2c dan b2b: pertukaran mata uang online, transfer uang tunai dan online, pembayaran pinjaman, program loyalitas, transportasi dan kartu sosial.
Pusat pemrosesan "KartStandart": menerbitkan dan mengakuisisi kartu sistem pembayaran Mastercard, Visa, dan "Mir".
Sistem Federal "City" mengumpulkan puluhan ribu berbagai layanan: mulai dari membayar taman kanak-kanak dan utilitas hingga melakukan pembayaran pajak dan mengisi kembali kartu transportasi.
Layanan perbankan online Faktura.ru digunakan oleh lebih dari 130 bank. Sistem perbankan otomatis CFT digunakan oleh organisasi yang bahkan lebih berbeda.
CFT mempekerjakan divisi R&D, ML dan AI yang besar, yang terintegrasi ke dalam hampir semua bidang perusahaan. Kami memiliki tim keamanan informasi yang kuat. Secara umum, ini lebih dari 3.000 orang yang sibuk menyelesaikan tugas fintech selama 26 tahun terakhir.
Salah satu produk "muda" CFT didasarkan pada layanan "Mahkota Emas - Transfer Uang" (yang sudah berusia 16 tahun) - yaitu "Transfer Uang Online", arah yang kami luncurkan pada tahun 2016. Dan hari ini merupakan lokomotif pengembangan ponsel di CFT: secara total, 70 orang bekerja di iOS dan Android. Dan jumlah ini terus bertambah, kami berencana untuk tumbuh hingga ratusan pada akhir tahun.
Ada juga petunjuk arah seluler di divisi “kartu prabayar” (mereka mengembangkan solusi untuk kartu “Jagung”, “Langsung”, “Kari”, dll.), Di Faktura.ru, Sistem “Kota”.
Dan Misha dan saya hanya berada di divisi "Transfer Uang Online" yang terlibat dalam pengembangan tim, ekspansi, dan pengenalan proses pengembangan. Awalnya, kami bekerja di Direktorat "Kartu Prabayar", tim-timnya kecil, platform, dan kami hidup dalam konsep-konsep yang ada di 2014-2015.
Mikhail : Ketika semua orang duduk di kantor yang sama, mereka bekerja, berkomunikasi.
Kirill : Tim kecil yang hangat dan lampu, untuk 10-15 orang, memperhitungkan semuanya - baik pengujian maupun backend. Dan sekarang kami memiliki tantangan baru.
Michael : Ya, mengorganisir pekerjaan 10 pengembang adalah satu hal, dan 50 adalah hal lain. Ini mencakup semua proses untuk pengembangan, penskalaan tim, pengembangan profesionalnya, dan proyek itu sendiri: jika teknisi kami memecahkan masalah teknis, kami terlibat dalam pengembangan arsitektur proyek. Kami mencari masalah yang akan mengganggu skala proyek ini, dan mencoba menyelesaikannya dengan segala cara.
JUG.ru Group: Kami akan kembali ke masalah pertumbuhan, tetapi untuk sekarang katakan padaku ini: bagaimana perkembangan ponsel di CFT berbeda dari perusahaan lain, dan apa yang mirip? Apa yang perlu Anda ketahui tentang hal ini bagi mereka yang belum pernah bekerja di fintech? Apakah Anda memerlukan pengetahuan khusus pada tahap wawancara?Kirill : Ketika kami berbicara dengan kandidat yang berasal dari outsourcing, mereka memiliki keinginan untuk bekerja dalam tim produk, keinginan untuk stabilitas. Tetapi mereka selalu memiliki kekhawatiran: apakah fintech semacam rawa, diatur secara ketat dan dikelilingi oleh keamanan, di mana akan tidak nyaman untuk terlibat dalam pengembangan diri dari sudut pandang pengembang.
Kami selalu memberi tahu bahwa dalam kasus kami pengembangan ponsel persis sama dengan pengembangan produk pasar apa pun. Fintech bukanlah kata untuk menggambarkan cara hidup, tetapi hanya garis pekerjaan, sesuatu yang kita hadapi setiap hari.
Ini adalah klien mobile banking yang sama, berbagai pembayaran, layanan pembayaran tanpa kontak, dan sebagainya. Tetapi ini tidak berarti bahwa Anda memerlukan keterampilan atau pengetahuan khusus: pengembang ponsel mana pun yang keren dapat mulai melakukan fintech jika ia tertarik.
Tentu saja, kita membutuhkan pengetahuan minimal di tingkat primer: seperti apa bentuk kartu bank, apa itu rekening bank. Tetapi jika ada pengetahuan yang lebih dalam, maka ini membuatnya lebih mudah dan lebih cepat untuk memahami keinginan analis. Ada pengembang yang ingin memahami tidak hanya "bagaimana melakukan tugas", tetapi juga "mengapa."
Ada juga kekhususannya sendiri, misalnya, persyaratan regulator yang diwakili oleh Bank Sentral. Tetapi, sebagai suatu peraturan, ini semua diperhitungkan dalam persyaratan bisnis dan cukup untuk membacanya, mengajukan pertanyaan yang diperlukan, dan semuanya akan jelas.
Ada beberapa titik tertentu dari sudut pandang keamanan informasi, ini bisa dimengerti: fintech adalah tentang keamanan. Tapi saya tidak bisa mengatakan bahwa pengembang seluler adalah garis pertahanan pertama. Meski demikian, produk fintech dirancang sedemikian rupa agar aman di sisi belakang dan sisi penyimpanan data.
Ya, kebetulan pengembang berasal dari startup dan mulai mengatakan bahwa API dapat dirancang lebih baik: mereka mengatakan, di sini Anda dapat membuat satu permintaan, dan kami melakukan tiga. Tetapi ini disebabkan oleh fakta bahwa API dirancang sedemikian rupa agar tidak memberikan keseluruhan informasi. Dan ketika pengembang memahami bahwa ini adalah keputusan rekayasa, dan bukan langkah bodoh dari pihak pengembang, ia langsung menerimanya.
Dan dari sudut pandang keamanan aplikasi mobile, kami memiliki laporan tentang Mobius masa lalu. Kami tidak menemukan Amerika di sana dan tidak menunjukkan trik meretas, tetapi menunjukkan daftar periksa yang harus dilalui pengembang aplikasi fintech agar tidak membuat kesalahan konyol:
Kami tidak melakukannya, karena ada tinjauan kode dan ada rekomendasi dari tim keamanan yang membuat kami daftar periksa yang sangat baik. Ini menyatakan di mana kerentanan harus dikerjakan dan oleh siapa (di sisi intelijen bisnis, pengembang backend, pengembang ponsel atau tester ) Semua bidang tanggung jawab ini diketahui oleh kami, kami hanya mengikuti aturan.
Penting untuk dipahami bahwa kita tidak hanya menggergaji kaleng yang membosankan, tetapi juga berusaha mengubah wajah kita menjadi pelanggan, termasuk sisi teknologi. Karena itu, kami selalu untuk inovasi seperti pembayaran tanpa kontak.
"Bank" iOS kami pada tahun 2018 mengambil tempat ke-4 dan ke-5 dalam
peringkat Markswebb dalam kategori perbankan harian.
Kami mencoba untuk menjadi aplikasi yang "tidak malu menunjukkan ibu", yang dapat digunakan oleh orang-orang yang jauh dari smartphone, dan mereka yang mengerti banyak tentang teknologi. Mengapa beberapa bank seluler berhasil dan beberapa tidak? Karena mereka dibuat secara teknologi, dengan animasi, bahkan mungkin dengan semacam referensi budaya.
Michael : Saya akan menambahkan secara singkat bahwa kami benar-benar fokus pada pelanggan - orang-orang hidup yang berjalan di jalanan. Karena kami melakukan operasi dengan uang, kami berusaha membuatnya semaksimal mungkin, lebih mudah bagi orang-orang.
Pada saat yang sama, ketika karyawan mendatangi kami, mereka perlu memahami apa yang benar-benar “dilakukan untuk orang-orang” dan tidak mencoret-coret "seperti yang saya lihat" di atas lutut mereka. Sebelum bekerja di CFT, saya melakukan hampir semua desain dan UX sendiri tanpa seorang desainer. Tetapi perusahaan tidak bekerja untuk kita seperti itu. Ada laboratorium UX lengkap dengan desainer yang melakukan percobaan, dan ada kelompok fokus yang menguji hipotesis.
Dan ketika seseorang mendatangi kita, dia harus mengerti bahwa semuanya akan difokuskan untuk memudahkan klien untuk menggunakan produk, agar tidak mati ketika mengisi formulir 50 bidang. Pekerjaan difokuskan pada kebutuhan pengguna akhir.
Yang kedua adalah persyaratan kualitas kode. Kami memiliki persyaratan sangat tinggi untuk kualitas, ulasan, arsitektur bersih, penerapan prinsip SOLID di semua lapisan. Tidak dapat diterima bagi kita untuk mengorbankan kualitas demi waktu.
Dan ini berbatasan dengan teknologi modern, tidak ada lag di belakang industri. Semua produk Android sekarang ditulis dalam Kotlin, dan iOS di Swift. Di Android kami menggunakan Rx, Dagger, di beberapa proyek coroutine. Ketika pengembang baru datang, kami secara teratur meminta umpan balik untuk memahami apa yang disukai dan tidak disukai orang. Dan saya tidak ingat bahwa karyawan mengeluh bahwa ada sesuatu yang sudah ketinggalan zaman dan menawarkan untuk mengubah sesuatu. Kami hanya punya waktu untuk melemparkan ide, "mari kita coba MVI dalam modul ini dan itu", dan semua orang mulai menghasilkan.
Ketika seseorang datang ke tim kami, ia harus siap untuk memahami tumpukan teknologi modern dan dapat menavigasi itu. Kami menyambut ini. Ini, mungkin, bahkan merupakan sebuah paradoks: seseorang pergi ke fintech, ke perkembangan perbankan, mengharapkan konservatisme, dan dia dituntut untuk tahu bagaimana Rx dan Kotlin bekerja dengan semua barang. Ini, menurut saya, adalah fitur unik.
Pertumbuhan tim seluler
JUG.ru Group: Anda sudah mengatakan bahwa Anda sedang memecahkan masalah yang muncul dengan pertumbuhan tim. Apakah ada contoh nyata?Michael : Misalnya. Ketika enam orang dalam tim melakukan peninjauan permintaan tarik, 3-4 orang dalam permintaan tarik, mereka lulus cukup cepat (terutama jika orang-orang di kantor yang sama). Situasi berubah secara dramatis ketika karyawan bekerja di berbagai kota dan zona waktu, dan tim tumbuh dan memisahkan sel-sel di dalamnya (tim pengembangan disatukan oleh satu pemimpin tim).
Kami perhatikan bahwa dengan peningkatan jumlah pengulas yang organik, permintaan tarik mulai bertahan hingga 5-6 hari. Ini adalah masalah: kami tidak dapat mengirimkan fitur ke bisnis tepat waktu.
Ada juga masalah dengan aliran git: jika Anda duduk di satu cabang dan melihat untuk waktu yang lama, pada saat itu tim lain juga dapat melihat 2-4 fitur di cabang lain, dan kemudian semua ini dibekukan di cabang dengan tanggal rilis, kami mendapatkan kesakitan dalam bentuk konflik penggabungan.
Masalah kedua diselesaikan dengan mengubah aliran git. Mereka mulai menerapkan pendekatan pengembangan berbasis trunk, yaitu, menuangkan langsung ke cabang pengembangan, cabang fitur yang ditinggalkan. Tetapi karena menuangkan fungsional yang tidak beroperasi tidak mungkin, ini akan merusak proyek, maka kami menerapkan fitur toggle approach. Dan dengan demikian mengurangi jangka waktu untuk mengeluarkan fungsionalitas ke cabang rilis beberapa hari. Saya berbicara lebih banyak tentang ini di Twitter
@mobileunderhood .
Ada masalah dengan ulasan. Sebelumnya, sekitar 4-5 orang ikut serta dalam kami, karena kualitas kode penting bagi kami, kami memiliki prinsip dan pendekatan kualitas yang cukup ketat. Kami takut jika kami mengurangi jumlah pengulas, kualitas kami akan menurun. Dalam hal ini, untuk 50 pengembang, misalnya, 30 melakukan tinjauan kualitas, dan sisanya adalah pengembang junior atau menengah yang belum mengembangkan keterampilan nyata.
Oleh karena itu, kami mengambil jalur yang berbeda dan menghasilkan rumus "1 pemimpin + 1 pengembang senior + 1 pengembang apa pun". Pada awalnya, kami menggunakan formula ini dalam kerangka kerja tim: misalnya, pengembang tim "A" mengeluarkan permintaan tarik, memberikan ulasan kepada kurator dan beberapa pengembang individu. Sekitar 20 potong permintaan tarik muncul dalam satu setengah hari: jika di pagi hari kami melakukan peninjauan terhadap semua orang, maka pada pertengahan hari berikutnya akan ada sekitar 20 permintaan baru.
Tapi kami mengalami masalah lain. Jika pengembang terus-menerus menempatkan keunggulannya dan keunggulan tetangga dari tim lain, maka kelebihannya menjadi kelebihan. Mereka kurang terlibat dalam pengembangan dan menghabiskan lebih banyak waktu untuk meninjau. Sekitar 20 permintaan tarik merupakan pekerjaan serius jika Anda mendekatinya secara kualitatif.
Dan kami melangkah lebih jauh. Mereka meninggalkan tiga slot untuk pengulas, meninggalkan peran yang sama (tim teknologi, pengembang senior, dan lainnya), tetapi tidak peduli bahwa itu haruslah orang-orang dari tim Anda. Dan sekarang kami memiliki permintaan tarik yang dilakukan dalam sehari, maksimal satu setengah. Tidak ada lagi cerita panjang.
Dan semua ini dalam kombinasi dengan fitur toggle: ketika seorang pengembang mengambil fitur, ia pertama-tama membuat tanda penonaktifan dalam kode sehingga berada pada awal yang dingin. Dan kemudian mulai pengembangan. Semua ini diperiksa dalam satu hari, tidak peduli di kota mana tim itu berada.
Cerita terpisah dengan zona waktu. Jika kami melakukan permintaan tarik di St. Petersburg, kami menyumbang pada malam hari, kemudian di Novosibirsk +4 jam, dan sementara kami memiliki malam yang lain, mereka sudah menonton permintaan tarik di pagi hari. Mereka pergi kerja - kami menerima permintaan tarik dan menonton. Ternyata aliran terus menerus konstan di mana zona waktu bekerja di tangan.
Kirill : Ya, kembali ke pertanyaan tentang perusahaan: selain fakta bahwa kami memiliki lebih dari 3.000 karyawan, pusat pengembangan kami berlokasi di tiga kota (Tomsk, Novosibirsk dan St. Petersburg), dan tim seluler didistribusikan di antara mereka. Agak rumit bahwa ada jeda empat jam, tetapi total hari kerja perusahaan diperpanjang hingga 12 jam.
Michael : Zona waktu membantu lebih dari sekadar ulasan. Kami telah membentuk pengembangan Android tunggal, tidak ada hal seperti itu di kota yang berbeda semuanya terpisah. Tim kami adalah lintas fungsi, tetapi disatukan oleh karakteristik platform, sebagai komunitas. Ada standar, prinsip umum dan praktik yang diterima, termasuk gaya kode dan sejenisnya. Dan karena itu, jika tiba-tiba muncul masalah yang memerlukan perbaikan panas atau tindakan mendesak lainnya, saya dapat mengambil mereka yang sekarang memiliki jam kerja, bahkan jika mereka awalnya tidak bertanggung jawab atas kode ini. Orang-orang di kota lain dapat membantu saat kita tidur, dan sebaliknya.
Grup JUG.ru: Ketika sebuah tim tumbuh, tidak ada pengembang yang dapat mengetahui seluruh basis kode atau mudah untuk memperjelas apa pun dari seseorang yang duduk di dekatnya. Dalam hal ini, mungkin, tantangan lain muncul: pencatatan?Kirill: Ini pantas untuk dikatakan: ketika kami merencanakan pertumbuhan tim 10 kali, kami menyadari bahwa kami tidak akan merilis fitur 10 kali lebih banyak (atau bahkan 7 kali). Dengan pertumbuhan seperti itu, hanya untuk mempertahankan tingkat kualitas sebelumnya, upaya tambahan diperlukan. Dan salah satu latihan untuk pengembang baru hanya menulis dokumentasi sebelum mulai melakukan sesuatu.
Dengan demikian, dalam waktu singkat kami membahas komponen utama aplikasi dalam dokumentasi. Dan mereka mulai membiarkan jones masuk ke dalam komponen-komponen seperti itu, karena dengan dokumentasi semacam itu sudah memungkinkan untuk melakukan tinjauan dan pengujian kode. Itu adalah zoom "knalpot tertunda".
Sekarang setelah satu tahun berlalu, kami telah menyiapkan basis, dan sekarang kami membawa pengembang yang datang setahun yang lalu ke tingkat produktivitas penuh. Semakin jauh kita melangkah, semakin mudah jadinya. Berdasarkan dokumentasi yang dibuat, kami membuat daftar periksa dengan struktur dan interaksi komponen, dengan integrasi kami dengan layanan utama, dan sekarang semua ini tidak menimbulkan kepanikan: "Saya datang ke sini untuk memprogram, dan Anda memiliki perusahaan di sini."
Michael : Saya akan melengkapi Cyril. Setelah tim memiliki lebih dari 30 karyawan, ada periode ketika pemimpin tim dan pengembang senior menghabiskan banyak waktu pada satu atau dua pengembang yang diawasi, karena mereka terus-menerus mengirimkan informasi. Kami memahami ini sebelumnya dan mulai bertindak. Oleh karena itu, Android mengalokasikan ruang terpisah di Confluence dan di sana mengumpulkan semua prinsip, praktik, dan konvensi untuk pengembangan tidak hanya dalam proyek ini, tetapi juga pada yang lain.
Ketika seorang karyawan datang ke sebuah tim, dia pertama-tama duduk dan mempelajari bagaimana kita melakukan pengembangan, apa aturan dan praktiknya, dan arsitektur proyek apa. Dia bahkan tidak menerima kode saat belajar. Kemudian jawab pertanyaan kontrol. Pelatihan apa pun tanpa pertanyaan keamanan tidak cukup efektif.
Sekarang kami telah melangkah lebih jauh dan menciptakan sistem pelatihan otomatis Galileo. Esensinya ada dalam beberapa tingkatan gradasi pendidikan, dari prinsip-prinsip pembangunan dan metodologi, dari prinsip-prinsip arsitektur hingga prinsip-prinsip bahasa Kotlin.
Setelah perendaman seperti itu, setengah dari pertanyaan tersapu. Apa yang pemimpin lakukan sebelumnya sekarang terotomatisasi. Ketika pengembang langsung menuju ke produksi, dalam satu atau dua minggu, ia mengajukan pertanyaan tajam, yang bukan masalah. Dan sebelum itu benar-benar ada masalah.
Saya percaya bahwa meskipun proyek ini untuk 10 orang, Anda masih perlu membuat dokumentasi terlebih dahulu. Jangan mengalami masalah ini, tetapi berikan beberapa prinsip. Akan ada penskalaan - tidak akan, dan dalam kasus apa pun, ketika pengembang baru tiba, dokumentasi menghapus banyak pertanyaan dan menghemat banyak waktu kurator.
Kami memiliki dokumentasi platform (untuk Android dan iOS), dan ada proyek (skenario bisnis dan sejenisnya).
Kirill : Kami beralih ke beberapa crowdsourcing. Ketika seorang pendatang baru tiba, mereka berkata kepadanya: "Lihat, ini yang harus dibaca pada hari pertama, di sini di hari kedua." Di sana, mengatur, menyediakan berbagai akses, alat, dan sebagainya. Dan jika seseorang dihadapkan dengan masalah, salah satu tugasnya adalah menulis masalah pada daftar periksa yang sama untuk pendatang baru berikutnya. Hal-hal seperti mengejar tujuan yang berbeda sekaligus: kami juga menyiapkan dokumentasi untuk generasi berikutnya, dan mengajarkan kepada para pemula nilai mendokumentasikan apa yang dia lakukan. Dan dia tidak takut apa yang harus ditulis.
Terutama bersemangat segera mulai menggambar diagram UML, yang dianjurkan. Begitu seseorang memberi contoh yang baik, semua orang terlibat. Dan kami tidak mengalahkan siapa pun, karena kami mengerti bahwa waktu diperlukan, dan kami memberikan waktu ini.
Perpustakaan pihak ketiga menentang pengembangan internal
Grup JUG.ru: Saya ingin berbicara sedikit lebih banyak tentang "dapur dalam" dalam konteks iOS dan Android. Sejauh yang kami pahami, di iOS Anda memiliki kebijakan untuk menolak solusi pihak ketiga, tetapi Android pada awalnya juga mencoba menulis semuanya sendiri, tetapi kemudian meninggalkannya. MengapaMichael : Android secara historis seperti ini. Pada 2013, ketika kami membuat bank seluler untuk kartu Kukruza, hampir tidak ada standar untuk arsitektur dan perpustakaan dalam pengembangan Android. Bahkan Google sendiri tidak mengerti harus mengembangkan Android di mana. Kami memulai pengembangan ketika belum ada Android 5, kami memiliki KitKat 4.4 sebagai versi maksimum.
Karena tidak ada perpustakaan, kami menulis sendiri. , , . : , HTTP-
Volley , API- Retrofit ( ). , . , . Dagger , , Retrofit, «», .
- , , , - . Volley . , , - .
, - . , , Rx , . , . . . , - .
, : «, , », : «- - , », .
, , , -. Kotlin, - 1.0 . , best practices . .
« » « », . , -. .
, : , - , , . , , , , , - . , . , -, .
: iOS, , . . - — , . - AFNetworking, — 40-50 ( ). .
Mobius (
): third-party . , , , , . , , .
— , SSL- , - , .
, , . , ReactiveCocoa, 4-5 . -, , -, , ? , Swift, .
, , , . Android Dagger , , Google. Apple - , . , Swift, , , Swift.
6 , 2011 . 6-8 : , ? , , — SnapKit ( ) , , — , -, . , , .
— . , , , , , , .
: iOS Swift. — , , , . UI-, , -.
Swift — , Objective-C , . , , , , , , …
3 « » VIPER -, : «, MVP, VIPER». MVP- - . , , .
Swift Kotlin
Grup JUG.ru: Michael di @mobileunderhood menulis "kami meninggalkan Jawa sama sekali, kami menulis ulang semuanya di Kotlin". Biasanya, bahkan ketika kode baru sudah ditulis di Kotlin, yang ada di Jawa diubah sangat lambat, dan dapat tetap diproduksi selama bertahun-tahun. Mengapa Anda memutuskan untuk melakukannya lebih aktif? Dan apakah Anda menyingkirkan kode Objective-C secara aktif di iOS?Michael : Saya selalu menyukai Java. Saya selalu mencintainya, bahkan lulus sertifikat Oracle, dan dia baik-baik saja dengan saya. Tetapi pengembangan Java di Android dan pengembangan Java di enterprise adalah dua hal yang berbeda. Dan beberapa tahun yang lalu, ketika Kotlin baru saja mulai, menggunakan Java dalam bentuknya yang tanpa perpustakaan mulai melelahkan. Konstruksi panjang, sedikit gula sintaksis, di sini beberapa rekan kerja dengan C # juga melempar apa yang mereka miliki, tetapi kami tidak, itu umumnya terdemotivasi. Saya ingin menulis kode yang menjalankan logika, dan menghabiskan lebih sedikit waktu untuk menulis kode ini sendiri, menggunakan lebih banyak barang, lebih mudah untuk memahami dan membaca kode.
Kemudian datang hal-hal seperti Lombok. Pada awalnya saya menyukainya, dan kemudian berhenti, karena itu adalah semacam perpustakaan tambahan yang memungkinkan Anda untuk menyederhanakan kode, membungkusnya dengan gula sintaksis, tetapi ini hanya sebuah plug-in, bukan kompiler Java itu sendiri. Dan Kelas Data Kotlin dan kelas Java reguler dengan semua properti dan dapatkan / set metode enkapsulasi adalah hal yang sangat berbeda.
Dan kami memutuskan untuk waktu yang lama untuk pertama kalinya untuk mencoba Kotlin di tingkat satu proyek. Kami menulisnya, beberapa hal membingungkan kami - yah, Kotlin dan Kotlin, kami agak mencobanya, oke, ada satu proyek, kami kembali ke Jawa. Mereka kembali, dan setelah beberapa waktu saya menyadari bahwa saya tidak bisa lagi berkembang di Jawa. Itu saja, saya bosan dengannya, saya tidak bisa melihatnya lagi.
Rupanya, saya terbiasa dengan beberapa hal sintaksis, dengan minimalisme kode. Dan pada akhirnya, diputuskan bahwa kita perlu menggunakan Kotlin. Lebih baik dipahami dan dibaca. Beberapa pengembang menentangnya, tetapi menurut saya ini adalah kebiasaan. Praktik yang diperkenalkan: menulis proyek baru di Kotlin. Dan proyek-proyek lama tetap di Jawa. Tetapi ketika beberapa refactoring besar terjadi, kami menyalin semuanya ke Kotlin. Kami telah memperoleh pengalaman untuk melakukan ini dengan cepat. Ini tidak berarti bahwa kami mengonversi file Java ke Kotlin dengan hot key, dan kemudian memperbaiki kode ini - kami sendiri menulis ulang segera dalam gaya Kotlin.
Ada dua proyek Java yang tersisa, dan transisi secara bertahap juga terjadi di sana: modul-modul baru ditulis di Kotlin, tes-tes baru di Kotlin, dan logika lama di Jawa. Jika logika berubah karena refactoring, kami menulis di Kotlin. Dan salah satu proyek ini sedang menjalani banyak refactoring sekarang. Jadi, kami menempatkan migrasi di sungai, dan setelah dua tahun dengan Jawa, masih ada satu setengah proyek.
Tidak ada yang secara khusus menentang. Ada beberapa keraguan "Kotlin hanya hype", tentu saja, tetapi itu sangat membantu kami ketika Google secara resmi mengakui Kotlin untuk pengembangan Android, bagi kami itu hanyalah sebuah bom. Tidak perlu lagi meyakinkan insinyur: apakah Anda berada di gelombang semua pengembang modern, atau di luar pasar ini.
Kirill : Dan dengan Swift, pertemuan pertama adalah seperti ini: Saya perlu membuat presentasi kecil untuk salah satu konferensi kami di Novosibirsk, dan ketika saya membawa sepotong kode ke layar di Objective-C, menjadi jelas bahwa itu tidak dapat dibaca pada ukuran layar apa pun. Dan kemudian saya menulis sepotong kode untuk presentasi di Swift, meskipun tidak ada satu baris "cepat" dalam proyek ini.
Kemudian kami mencoba Swift pada proyek Kartu Transportasi Golden Crown, yang kami tulis dari awal. Kami menjalankan beberapa momen bahasa di sana. Sangat menarik apa yang kami lakukan salah, sedikit mulai bekerja untuk menciptakan styleguide kami sendiri. Dari Swift kedua kami juga "pindah" ke yang ketiga, menyesap kesedihan, yang kemudian menghantui semua orang.
Dan jika Anda melihat permintaan tarikan yang kami miliki sekarang, 95% dari kode Swift ditulis di sana. Kami tidak memiliki tugas super untuk mentransfer semua kode yang tersedia dari Objective-C ke Swift dengan biaya berapa pun. Namun demikian, bagian dari kode Swift dalam aplikasi seluler Money Transfer adalah 60-65%, kami mengeluarkan "intisari swift" di mana kami menggambar grafik untuk file Swift / Objective-C, untuk baris kode, dan tergantung pada rilis dan tanggal semuanya terlihat. Pangsa 65% tidak berarti bahwa kami menyalin 6 file dari 10 - terutama pertumbuhan karena file baru.
Kami mencoba berbagai teknik transisi, misalnya, di bank seluler untuk kartu Corn, kami membuat transisi satu arah (yaitu, kode Swift kami didasarkan pada Objective-C, tetapi kami tidak mentransfer konstruksi Swift kembali ke Objective-C). Kami tidak menyeret fungsionalitas Swift untuk mempercepat proses beralih ke Swift dengan cara ini. Dalam hal ini, ketika benar-benar menjadi tajam dan kode Objective-C memerlukan semua dependensi Swift, kita dapat mengatakan bahwa sudah waktunya bagi komponen untuk sepenuhnya beralih ke Swift.
Karena produk untuk Golden Crown - layanan Pengiriman Uang lebih penting daripada kecepatan pengembangan daripada sekadar meningkatkan pangsa Swift, kami memiliki kisah dua arah. Mereka mungkin terlihat kurang cantik dari sudut pandang penganut Swift, tetapi karena pendekatan ini memberi produk kemampuan untuk bergerak lebih cepat.
Pengembang datang tanpa sepengetahuan Swift, bahasa dikuasai dalam dua minggu, mulai bekerja. Terkadang mereka takut kita memiliki 60% Swift, tapi tidak apa-apa, belum ada kasus di mana seorang karyawan tidak dapat menguasainya. Ada cerita yang berlawanan - ketika mereka mengetahui bahwa kita memiliki 40% Objective-C, mereka mulai mengatakan bahwa kita mundur, dan Anda harus terlebih dahulu menulis ulang semuanya di Swift, dan kemudian memotong fitur. Tapi di sini semuanya individual, dan kami bekerja dengan masing-masing individu.
Ada proyek campuran, proyek campuran searah, ada proyek bersih di Swift, kami mencoba semuanya. Semuanya bekerja dengan sangat baik, tidak ada peluru perak.
JUG.ru Group: Tentang Swift dan Kotlin mereka mengatakan "karena mereka mirip, telah menjadi nyaman bagi pengembang untuk Android dan iOS untuk melihat kode masing-masing." Apakah Anda memiliki pengembang untuk platform berbeda yang mencari kode masing-masing atau tidak?Kirill : Saya ingat cerita ketika pengembang Android yang menulis di Jawa melihat kode pengembang iOS di Objective-C dan sebaliknya, ketika kami menulis salah satu komponen paling kompleks dari aplikasi seluler untuk peta Corn - perancang bentuk terkenal, Contoh arsitektur UI Backend Driven. Ada interaksi yang sangat intens dengan backend melalui protokol tertentu, dan tidak melakukan hal yang sama hanyalah kriminal. Tentu saja, kami mengintip.
Dan sekarang kami memiliki pendekatan arsitektur yang berbeda dalam aplikasi, aplikasi didasarkan pada arsitektur UI yang berbeda. Maksimum di mana kita dapat mengintip adalah lapisan bisnis, dan bahkan kemudian kita harus menggali ke arah alat pengujian yang memungkinkan Anda untuk menulis dalam salah satu bahasa pemrograman.
Aplikasi, pada kenyataannya, adalah klien untuk layanan ini. Sebagian besar, ia merespons input pengguna dan menampilkan data dari server. Di suatu tempat untuk menulis sesuatu yang salah sepenuhnya cukup sulit. Dan dalam pengertian ini, mungkin, ada beberapa contoh.
Michael : Saya punya contoh. Karena kami sekarang memiliki tim lintas fungsi, pengembang iOS dan Android hampir secara bersamaan melakukan fungsi bisnis yang sama pada platform yang berbeda, mereka semakin jarang melihat kode masing-masing, karena tidak ada yang perlu dilihat, dan seluruh pengembangan berjalan dengan lancar.
Tetapi ketika seseorang melangkah maju, pada saat yang sama, orang tersebut menyadari bahwa sebagian besar chip diimplementasikan, ketika bisnis mengisyaratkan "lihat bagaimana Android dilakukan," dan analitik belum siap, ada kalanya pengembang dari kedua belah pihak dapat mampir dan melihat bagaimana hal itu dilakukan. Dan di sini sangat membantu Swift dan Kotlin sangat mirip.
Di mobileunderhood, saya berbagi pengalaman yang saya miliki ketika saya bekerja pada sebuah proyek di mana kami tidak memiliki tim lintas fungsi, tetapi semacam startup untuk membayar pinjaman. Dan saya suka melihat perkembangan iOS, menarik bagaimana mereka memecahkan masalah tertentu, bahkan mungkin melemparkan sesuatu kepada mereka. Dan mereka suka sekali melemparkan saya. Dan kami terus-menerus, selama berjam-jam bisa berdiri di papan tulis dan berbicara tentang bagaimana polimorfisme murni terlihat di iOS dan Android, cara memasaknya.
Itu datang untuk membahas apa itu abstraksi, untuk beberapa jenis konsep formal, dan itu semua terjadi agak menyenangkan, dan dimulai dengan kode yang biasa. Anda melihat dan berpikir: mengapa Anda melakukan ini, apakah ada banyak biaya overhead? Dan mereka menjelaskan kepada saya bahwa semuanya telah direncanakan dan secara sadar berjalan untuk itu, agar tidak menghabiskan 2-3 hari mencari solusi terbaik, jika, misalnya, kode ini berubah melalui sprint. Saya pikir: orang pintar, kita perlu melakukan ini kadang-kadang, dan tidak memikirkan selama lima hari semacam arsitektur internal, yang kemudian ternyata tidak diperlukan.
Akibatnya, saya sering muncul dan melihat kode Swift. Melihat Objective-C juga, tapi saya lebih suka Swift. Meskipun saya tidak mengembangkannya, saya tidak berpikir akan ada kesulitan dalam menulis kode. Pengembang Android memiliki hal yang sama.
Kirill : Secara umum, kami tidak hanya memiliki tim platform, yang di dalamnya kami katakan kepada mereka: "Anda adalah yang terbaik karena Apple memberikan alat seperti itu." Orang-orang dari iOS dan Android berinteraksi, berpartisipasi dalam perencanaan bersama, dan menangani masalah dengan analis sistem.
Dan mereka juga bertindak bersama dalam kaitannya dengan pengembang backend jika mereka mencoba membuat beberapa API yang tidak begitu cocok. Dan dalam simbiosis ini, mereka dapat memata-matai semua yang ada di repositori, kami memiliki sistem terbuka, dan semua pengembang memiliki akses ke repositori.
Di direktorat “kartu prabayar”, kami punya cerita ketika backend dijahit, dan kemudian pengembang Android mengatur lingkungan, lingkungan dan memfilmkan beberapa perbaikan bug, hanya untuk membantu.
Michael : Saya mengingat kasus yang sangat baru. Di sana, agar klien menjadi lebih halus bagi kami, backend perlu melakukan lebih banyak pekerjaan, maka trik seluler kami bergabung bersama dan mulai mendorong gagasan umum mereka. Mereka semua berkumpul, membahas bagaimana mereka akan merasa nyaman di kedua platform, pergi ke pengembang backend dan mengumumkan bagaimana mereka lebih nyaman bekerja dan apa yang melanggar konsep thin client. Para pendukung setuju dengan mereka.
Sekarang, jika satu platform berkata: "Kami akan melakukan segalanya", dan yang kedua menolak, mengatakan bahwa itu sulit, maka mereka akan memaksa yang kedua untuk menyetujui dan melakukannya. Dan semuanya terjadi bersamaan. Oleh karena itu, sinergi, pengembangan tim bekerja. Dan bahasa sangat membantu dalam hal ini. Lagi pula, jika Java dan Objective-C adalah belahan yang sama sekali berbeda dalam hal sintaks dan prinsip, maka Kotlin dan Swift benar-benar jauh lebih dekat.
Cyril : Ngomong-ngomong, ada contoh ketika mereka menjadi switchers, dan bahkan switchers ganda, beralih antar platform. Ada satu yang beralih ke iOS, berkenalan, "mengambil alih", dan kembali ke Android. Dan kemudian dia pergi sama sekali di DevOps. Dalam hal ini, kami juga terbuka, momen seperti itu disederhanakan.
Sangat menyenangkan bahwa para pria menginginkan pengembangan profesional, bahkan di pesawat yang berbeda. Kami memberikan peluang, dan mereka sendiri memilih jalan mana yang ingin mereka kembangkan, dan hampir semua orang kami termotivasi oleh produk, oleh tugas-tugas yang mereka kerjakan, yang sangat keren.
JUG.ru Group: Pertanyaan terakhir: bagaimana dengan pengembangan lintas platform?Kirill : Perusahaan kami memiliki produk yang sedang dikembangkan untuk sistem Kota Federal. Di situlah React Native dipilih untuk implementasi. Dan kami tidak merasakan kecemburuan untuk ini, karena selalu menarik untuk melakukan percobaan dan mencari tahu bagaimana itu akan berakhir. Selain itu, kami memiliki pengembang front-end yang sangat memahami bisnis mereka, dan menarik untuk mencoba sesuatu yang baru dan memasuki platform baru.
Michael : Kami memiliki proyek tentang React Native, tetapi ini agak salah, karena dilakukan oleh pengembang front-end, dan pengembang iOS dan Android tidak tumpang tindih.
Adapun lintas-platform, saya pribadi melihatnya untuk tim kecil: ketika ada beberapa sumber daya di iOS dan Android, dan proyek perlu dilakukan untuk kedua platform, mengapa tidak. Kami memiliki sumber daya yang cukup, dan produk-produknya berteknologi canggih, kami mampu mengembangkan terpisah untuk iOS dan Android.
Secara historis juga terjadi bahwa ketika kami melakukan sebagian besar proyek kami, belum ada lintas platform. Sekarang, tentu saja, kita akan berpikir tentang memisahkan bagian dari logika bisnis dan logika abstrak ke dalam modul umum, karena tidak ada yang suka melakukan satu pekerjaan. Namun secara historis, kami tidak memiliki ini.
Namun, ini tidak berarti bahwa akan selalu begitu. Kami memiliki banyak tugas dan proyek yang menjanjikan dari bisnis, ada prototipe, dan cepat atau lambat kami akan mencoba Kotlin Multiplatform dari JetBrains atau Flutter, yang lebih menarik bagi kami.
Cross-platform belum distandarisasi dalam bentuk industri, di mana Anda dapat mengambil dan menggunakannya dalam suatu perusahaan. Dilihat oleh komunikasi dengan pengembang lintas platform dan laporan mereka, sekarang ada "rake run" dan pemecahan masalah yang konstan. Oleh karena itu, Anda dapat mengambil dan mengajukan proyek, tetapi lebih sering itu hanya pertarungan melawan penggaruk, dan saya tidak berpikir bahwa fitur bisnis dapat digergaji secara efisien. Baru-baru ini, JetBrains ditanya di laporan apakah mungkin menggunakan versi multi-platform Kotlin dalam produksi, dan mereka mengatakan bahwa itu masih dalam bentuk percobaan.
Di ujung lain ada Flutter, yang lepas landas di tahun lalu, hal ini sangat menarik, Google tidak lemah berinvestasi dalam bisnis ini. Dan saya tahu banyak yang melakukan proyek kesayangan di Flutter, yang sudah ditata di toko aplikasi. Dan ini lebih menarik bagi kita. Kami sudah muak dengan Kotlin sedikit, dengan Kotlin / Asli kita harus mengumpulkan banyak garu, tetapi Flutter dengan Dart adalah hal yang sama sekali baru.
Kami menyukai semuanya yang baru, jadi kami pasti akan memiliki pengembangan lintas platform. Tidak secara khusus dalam aplikasi Pengiriman Uang, tetapi dalam beberapa aplikasi kecil yang terpisah akan.
JUG.ru Group: Terima kasih atas jawaban terperinci!