Untuk mengantisipasi AppsConf 2018, kami mewawancarai spesialis dari perusahaan besar tentang fitur khas dan proses tim besar yang terlibat dalam pengembangan aplikasi mobile. Pendekatan apa yang digunakan untuk bekerja, perangkap apa yang menunggu pendayung tiba di dapur besar. Apakah asal asing perusahaan meninggalkan jejak pada proses kerja - baca semua tentang ini di bawah potongan.
Philip Uvarov, pengembang Android di Spotify. Perusahaan telah bekerja selama enam bulan terakhir - di salah satu tim platform yang mendukung pengembang lain di Spotify. Tinggal di Swedia. Sebelum Spotify, ia bekerja di sebuah startup Swedia, dan bahkan lebih awal di Avito.
Artyom Olkov, Pengembang iOS Timbal di Odnoklassniki. Dia saat ini memimpin pengembangan iOS salah satu produk. Selain pengembangan itu sendiri, ia bertanggung jawab untuk arsitektur, desain, alokasi tugas, koordinasi dengan desain, API backend, dll. Secara total, Odnoklassniki sekarang memiliki sekitar 60 insinyur seluler yang dibagi menjadi tim yang lebih kecil. Tim Artem - 11 orang.
Maxim Efimov, insinyur perangkat lunak senior di Uber. Dia telah bersama perusahaan selama dua tahun, dia terlibat dalam pengembangan Android. Ini adalah bagian dari tim pembayaran pengendara, yang bergerak dalam memproses segala sesuatu yang terkait dengan pembayaran dalam aplikasi penumpang Uber. Sebelum itu, ia mengembangkan untuk Android di perusahaan lain - terutama berdasarkan pesanan, dan bahkan lebih awal - ia menulis dalam C ++ (solusi server untuk sistem SCADA). Di Uber, sebagai bagian dari departemen pembayaran, ada beberapa tim yang lebih mirip untuk aplikasi lain, serta tim infrastruktur - total beberapa lusin tim.
Evgeny Suvorov, Kepala Pengembangan Unit Seluler di Avito: Ia telah mengembangkan aplikasi seluler selama sekitar delapan tahun. Saya mencoba permainan, lepas, bekerja di perusahaan outsourcing, di perusahaan besar, setelah itu saya beralih ke pengembangan produk.
Mari kita mulai dengan fitur-fiturnya. Apa perbedaan antara kerja tim dengan staf pengembang yang besar di perusahaan?Artem Olkov (Odnoklassniki): Menurut pendapat saya, kekhasan itu terkait bukan dengan skala perusahaan, tetapi dengan bagaimana proses disusun di dalamnya dan apa peran tim dalam proses ini. Secara kasar, jika tim Anda membuat platform seluler yang menjadi dasar aplikasi atau layanan lain perusahaan, 1000 permintaan dari berbagai sudut akan terbang ke sana dan tanpa manajer produk yang baik, pengembangan akan tenggelam. Jika tim membuat layanan yang berdiri sendiri tanpa integrasi yang kompleks, prosesnya akan terlihat jauh lebih sederhana.
Maxim Efimov (Uber): Menurut saya, fitur yang paling khas adalah kecepatan kerja.
Tim kecil, pada prinsipnya, bekerja lebih cepat. Tetapi pada saat yang sama, tim-tim besar memiliki produk bruto akhir dari pengembang, secara alami, karena seluruh kelompok orang terlibat dalam hal yang kira-kira sama. Dan dari sini mengikuti pandangan yang berbeda tentang bagaimana proyek umumnya dilaksanakan.
Di perusahaan kecil, kita sering cocok secara kondisional, kondisional, hingga satu hari atau hingga satu minggu. Kami dapat menghitung dan merencanakan semuanya terlebih dahulu. Dalam tim besar, ini sulit dilakukan, karena semuanya terikat pada sejumlah besar orang. Oleh karena itu, pendekatan perencanaan agak berbeda. Proyek dilakukan dengan toleransi tertentu dalam hal waktu, dan kualitas serta fitur yang kami buat sangat penting. Dan hanya setelah itu adalah kebutuhan untuk memenuhi tenggat waktu.
Poin menarik lainnya: bagaimana tim-tim tersebut saling bersepakat. Jika lima hingga sepuluh orang mengerjakan proyek, mereka dapat dengan mudah dikumpulkan di ruang rapat dan, setelah menghabiskan dua hingga tiga jam, selesaikan semua masalah. Dan Anda dapat melangkah lebih jauh untuk melakukan proyek. Tetapi ketika ratusan orang terlibat dalam proyek, ini tidak akan berhasil. Di Uber, kami memiliki mekanisme komunikasi tertentu yang memungkinkan tim untuk tidak saling mengganggu, mengintegrasikan secara efektif, dll. Di perusahaan kecil, semua ini, pada prinsipnya, tidak ada.
Philip Uvarov (Spotify) : Saya pikir fitur utamanya adalah saya tidak tahu semua pengembang Android secara langsung. Dan kami juga memiliki tanggung jawab yang sangat berbeda. Ini memungkinkan Anda untuk selalu berada dalam konteks apa yang Anda lakukan, dan cukup cepat untuk mengantarkan produk ke arah Anda.
Bagaimana tim Anda melakukan sinkronisasi dengan orang lain di dalam perusahaan?Evgeny Suvorov (Avito): Tim kami terhubung oleh satu aplikasi seluler - Avito. Semuanya berkontribusi pada produk ini, yaitu titik sinkronisasi dalam basis kode dan fungsionalitas kami.
Philip Uvarov (Spotify) : Kami memiliki tim lintas fungsi yang menangani masalah spesifik (misalnya, bagaimana kami mengembangkan analitik untuk klien seluler) digabungkan menjadi satu departemen besar - kami menyebutnya "suku" (tribe). Sebagai aturan, tim-tim dalam satu suku cukup saling berhubungan, mereka memiliki pertukaran pengalaman yang aktif. Plus, tentu saja, kami memiliki klien - ini adalah pengembang lain, jadi kami mendukung solusi yang kami buat untuk mereka.
Maxim Efimov (Uber) : Kami memiliki tim kecil, masing-masing dengan tidak lebih dari 20 orang. Mereka disatukan dalam unit struktural yang bertanggung jawab untuk area yang luas, misalnya, aplikasi mobile. Pada saat yang sama, tim-tim itu sendiri sangat otonom, karena jika kita mereduksi semuanya menjadi sistem kontrol tunggal dengan subordinasi langsung, kita akan mendapatkan sistem yang sangat tidak efisien.
Ide produk umum disampaikan kepada masing-masing tim melalui manajer atau pemilik produk. Ada struktur terpisah yang menyatukan orang-orang ini dan membantu membangun pemahaman tentang bagaimana dan ke mana kita bergerak. Di beberapa tingkat atas, tujuan strategis seperti merawat keselamatan penumpang dapat ditentukan. Nah, detailnya diselesaikan satu atau dua level di bawah ini. Sebagai contoh, kami memiliki mekanisme keamanan tertentu di negara-negara di mana orang kebanyakan menggunakan uang tunai untuk membayar.
Artem Olkov (Odnoklassniki): Kami bergerak dalam layanan terpisah. Jadi katakanlah kita adalah perusahaan baru di sebuah perusahaan besar. Tentu saja, kita hidup di infrastruktur yang sama. Dan dalam hal lain, kami sangat terpisah. Bahkan dalam kerangka integrasi, kami sering menggunakan API publik dari alat kami sendiri.
Adakah masalah khas tim besar? Apa yang harus Anda hadapi?Evgeny Suvorov (Avito) : Menurut saya, proses dalam tim besar terutama terpengaruh.
Semua orang, sebagai suatu peraturan, berpengalaman, bahkan junior dapat memecahkan masalah teknis. Tetapi masalah dengan proses dapat dengan mudah memperlambat semua orang, jadi lebih baik untuk mengotomatiskan proses.
Dan itu berarti Integrasi Berkelanjutan berkualitas tinggi, Pengiriman Berkelanjutan, otomatisasi uji.
Philip Uvarov (Spotify) : Saya pikir masalah terbesar adalah penyebaran pengetahuan di dalam perusahaan. Saya mungkin tidak memiliki gagasan tentang apa yang terjadi di beberapa tim yang jauh. Dan hal yang sama berlaku di arah yang berlawanan: banyak tim tidak tahu bahwa kami memiliki tim analisis di Spotify. Di sinilah skala dirasakan.
Poin kedua adalah kecepatan membuat keputusan inovatif: adaptasi dari Kotlin yang sama dan teknologi baru lainnya. Adalah satu hal untuk datang dan memberi tahu lima pengembang: "Mulai hari ini kami menulis di Kotlin", tetapi cukup lain untuk mengatakannya kepada 100 pengembang. Ada infrastruktur besar yang perlu diterjemahkan, untuk mendukung inovasi-inovasi ini (CI, dll.).
Artem Olkov (Odnoklassniki): Ya, benar-benar ada dua masalah: transfer pengetahuan dan koordinasi tindakan, termasuk modernisasi.
Apakah perusahaan besar memiliki cara yang terbukti untuk menyelesaikan masalah ini?Philip Uvarov (Spotify) : Untuk memecahkan masalah pertama - berbagi pengetahuan - kami memiliki yang namanya guild. Ini adalah sekelompok pengembang berdasarkan fungsi, misalnya, guild Android, yang setiap dua minggu mengadakan beberapa acara: presentasi, makan siang, di mana Anda dapat mendiskusikan masalah mendesak atau berbagi sesuatu, dll. Kami juga memiliki, sekali lagi, guild diadakan konferensi internal. Plus ada milis, dll. Masalah manusia yang sederhana tetap ada: sulit untuk mengikuti semua ini.
Saya ingin menyoroti pelatihan internal (pelatihan lanjutan) sebagai jalur terpisah. Kami memiliki Universitas Data kami sendiri, di mana Anda dapat belajar bagaimana menjadi seorang insinyur data. Sekarang rekan kerja berpikir tentang membuat skema yang sama untuk pembelajaran mobile.
Artem Olkov (Teman Sekelas): Kami tidak memiliki guild yang diucapkan.
Dengan satu atau lain cara, orang-orang yang disatukan oleh satu tugas berpotongan pada pertemuan yang berbeda - mereka saling kenal, berkomunikasi di ruang merokok atau saat makan siang. Ada ruang obrolan terpisah, misalnya, murni untuk nama panggilan iOS. Di dalam tim, tentu saja, masalah ini diselesaikan dengan lebih mudah - kita semua duduk di "daisy" yang sama.
Jika Anda memiliki pertanyaan, angkat tangan, lambaikan tangan ke pertanyaan yang Anda butuhkan - dan dia menjawab Anda. Untuk mentransfer pengetahuan, kami juga menggunakan rapat umum pagi 15 menit, di mana setiap orang memberi tahu apa, bagaimana, mengapa, dan mengapa mereka melakukannya. Masih ada lapisan dokumentasi tertentu di mana poin utama diambil.
Masalah kedua - koordinasi tindakan - diselesaikan oleh manajemen yang kompeten.
Maxim Efimov (Uber): Sebenarnya, dalam berbagi pengetahuan yang sama, saya tidak melihat masalah. Saya melihat bahwa mekanisme berbagi itu sendiri berbeda. Dalam tim kecil, ini hanya dilakukan bagaimanapun. Berkumpul - berbicara. Dan kami memiliki proses yang nyaman yang memungkinkan kami untuk mengatur semuanya sehingga berfungsi. Ngomong-ngomong, saya akan membicarakannya dalam
pidato saya di AppsConf 2018. Idenya adalah bahwa di perusahaan kami hampir semua pengembangannya cukup transparan. Orang-orang dari tim mana pun dapat melihat apa yang dilakukan pengembang lain dan menggunakannya di rumah.
Evgeny Suvorov (Avito): Kami juga mengatur pertemuan 2 kali seminggu. Kami menyukai otomatisasi, dan tugas ini juga otomatis. Ada proses di mana selama minggu ini orang-orang membahas topik yang ingin mereka bicarakan pada pertemuan umum pengembang iOS atau Android. Dan jika ada panggilan pengadilan, kita akan pergi. Selama pertemuan, tim produk berbicara tentang fitur yang mereka terapkan dalam produk, karena kalau tidak, sulit untuk melacak segala sesuatu yang terjadi.
Kami bertemu sejak awal, tetapi dengan pertumbuhan perusahaan itulah pertemuan ini menjadi paling relevan.
Plus ada ruang obrolan di mana Anda dapat mendiskusikan masalah tertentu.
Dengan prinsip apa masuk akal untuk memecah banyak pengembang dalam perusahaan - berdasarkan platform, berdasarkan fungsi, atau dengan cara lain?Artem Olkov (Odnoklassniki): Itu masih tergantung pada apa yang Anda lakukan dan bagaimana Anda menghasilkan uang.
Secara teori, saya bisa membayangkan struktur perusahaan outsourcing di mana sebuah divisi, misalnya, akan bekerja berdasarkan platform. Tetapi untuk perusahaan makanan, saya hampir tidak bisa membayangkan bentuk pembagian yang berbeda, kecuali untuk tim fungsional.
Karena jika Anda menempatkan semua nama panggilan iOS di tumpukan, melemparkan tugas ke dalamnya, tanpa memiliki jembatan komunikasi yang sangat pendek dengan desain, backend atau pengujian, Anda harus menghabiskan terlalu banyak waktu untuk koordinasi.
Philip Uvarov (Spotify) : Kami semua berbagi tentang produk. Misalnya, tim kami terlibat dalam analitik dan mencakup iOS, pengembang backend, dan banyak lainnya. Menurut pendapat saya, ini adalah pembagian tim yang sangat masuk akal, yang juga mengarah pada masalah tertentu, tetapi pada saat yang sama bekerja dengan baik pada skala seperti itu.
Maxim Efimov (Uber): Bagi saya gagasan membagi tim berdasarkan platform - iOS, Android, backend - dalam skala besar tidak akan bekerja dengan baik. Ini memisahkan pengembang dari satu sama lain cukup banyak dan sebagai hasilnya, sinkronisasi, misalnya, dari dua aplikasi mobile untuk platform yang berbeda, akan jauh lebih mahal. Dan keuntungan dari fakta bahwa orang-orang dalam tim hanya melihat orang-orang dari platform mereka, menurut saya, tidak begitu banyak. Ya, berbagi pengetahuan lebih mudah, tetapi apakah itu layak? Saya kira tidak.
Plus, gagasan bahwa beberapa tim melakukan hal-hal dasar yang digunakan orang lain, misalnya, beberapa tombol, daftar, bidang input teks, tampaknya menarik bagi saya.
Evgeny Suvorov (Avito): Saya setuju, struktur seperti itu cukup sukses dan kami baru saja menerapkannya di Avito kami, setidaknya di bagian bisnis kelontong.
Tim kami menjadi besar, mungkin, ketika kami memiliki lima pengembang - karena walaupun dengan jumlah sendiri, mengatur diri sendiri itu sulit. Semakin sulit bagi mereka untuk melihat satu fitur, mereka harus memisahkan mereka, membiakkan mereka dalam sudut yang berbeda, dalam fitur yang berbeda. Ketidaksepakatan dimulai dalam masalah arsitektur dan lainnya, dan komunikasi menjadi lebih rumit.
Pada titik tertentu, Avito memiliki dua tim besar - iOS dan Android-development, masing-masing 15 orang. Dan pada tahap ini kami mulai membobol tim produk: kelompok "pengalaman pembeli", "pengalaman penjual", kurir instan, pengiriman, dll. Menonjol. Ini menyelesaikan masalah dengan prioritas. Sebelumnya, banyak manajer proyek datang ke tim dengan permintaan fitur, dan bagi mereka masing-masing fitur ini memiliki prioritas nomor satu. Akibatnya, kami memiliki 20 proyek dan prioritas lintas sektoralnya tidak jelas. Orang tua harus mengelola ini secara manual. Setelah menyoroti tim multi-fungsi, yang masing-masing memiliki jalur pengembangan sendiri, prioritas dan sumber dayanya, semuanya menjadi lebih sederhana.
Pada saat yang sama, kami masih memiliki tim platform kecil yang membuat, seperti kami menyebutnya, keputusan "horizontal" yang berlaku untuk semua tim produk.
Apakah reorganisasi tim sering dilakukan?Philip Uvarov (Spotify) : Beberapa jenis gerakan terjadi setiap minggu. Di perusahaan kami, timnya kecil dan otonom. Jika diinginkan, Anda dapat dengan mudah berpindah dari satu ke yang lain. Seberapa sering ini terjadi tergantung pada tim dan arah di mana Anda bekerja. Di mana saya bekerja, ini tidak diucapkan. Tetapi Spotify terkenal karena fakta bahwa kami bekerja dengan gesit dan dalam banyak hal seperti OKR, dll. Pergi dari kami. Karena itu, manajemen perusahaan tidak takut untuk mengubah prioritas, jika tiba-tiba menyadari bahwa ada sesuatu yang tidak berfungsi. Kami hanya beralih ke hal lain.
Maxim Efimov (Uber): Kami melakukan reformasi besar-besaran, terutama terkait dengan pertumbuhan kantor Amsterdam yang sangat cepat. Selama tahun ini, jumlah karyawan hampir dua kali lipat. Tim-tim tempat orang-orang direkrut menjadi sangat besar dan sulit bagi seorang manajer untuk mengelola struktur seperti itu. Dalam hal ini, tim hanya dibagi menjadi beberapa "sub-perintah", yang masing-masing terlibat dalam area yang lebih sempit. Menurut saya ini adalah proses alami.
Apakah Anda setuju dengan gagasan bahwa dalam tim besar, sehingga kualitas kode tidak menderita, ada baiknya menghindari mempekerjakan junior dan senior yang terlalu berkualitas?Philip Uvarov (Spotify) : Saya pikir tidak satu atau yang lain. Setiap tahun, Spotify merekrut lulusan universitas melalui praktik musim panas (beberapa orang setelah praktik menerima undangan untuk bekerja). Demikian pula, kami dengan mudah membawa orang dengan beberapa PhD.
Keterampilan teknis memang keren, tetapi Anda bisa mengajari mereka. Jika seseorang tidak tahu cara bekerja dalam tim, maka itu akan sangat sulit. Oleh karena itu, perusahaan semacam itu lebih memperhatikan soft skill.
Dan agar kualitasnya tidak menurun, kami membutuhkan wawancara yang baik yang memungkinkan kami memilih pengembang tidak lebih rendah dari level dasar.
Maxim Efimov (Uber): Kami mulai dari prinsip yang sedikit berbeda. Kami memiliki rasio yang diinginkan dari pengembang berpengalaman dan Juni. Hanya agar tidak ada situasi ketika ada kerumunan dzhun, dan tidak ada orang yang membantu mereka dan menjelaskan cara kerjanya. Karena itu, kami berusaha menjaga keseimbangan.
Mematuhi prinsip "tidak merekrut terlalu banyak tuan" tidak mengerti intinya. Menemukan junjungan adalah pencarian yang agak sulit. Ada banyak perusahaan di pasar, dan persaingan untuk pengembang sangat parah. Orang-orang dengan pengalaman berhasil menetap di hampir semua tempat, jadi melepaskan personel yang berkualifikasi hari ini dan kemudian merekrut mereka besok agak tidak realistis. Orang-orang ini tidak akan duduk dan menunggu sampai kami ingin mengundang mereka. Dan dalam praktik saya, jika seseorang memiliki kompetensi yang baik, maka tidak masalah untuk menemukannya di perusahaan. Tetapi kita harus melanjutkan dari situasi tertentu. Kita perlu membuat keputusan, tergantung pada ambisi apa yang dimiliki masing-masing orang dalam tim, melihat proyek yang akan datang, apakah kita dapat menariknya sendiri, siapa yang kita butuhkan. Artinya, perlu turun ke perencanaan tingkat rendah.
Evgeny Suvorov (Avito): Menurut pendapat saya, ketika merekrut senior, Anda tidak perlu takut bahwa mereka memiliki raja sendiri di kepala mereka atau bahwa mereka tidak akan patuh.
Di perusahaan kami, pengembang sendiri menawarkan cara untuk memecahkan masalah tertentu. Dan senior sering memiliki solusi berkualitas tinggi. Mereka memiliki pengalaman, oleh karena itu, dengan partisipasi mereka, masalah dapat diselesaikan lebih cepat. Ada masalah lain - tugas Anda mungkin tidak terlihat menarik atau ambisius senior.
Junior juga perlu didekati secara individual. Ketika kami masih satu tim, dari waktu ke waktu ada perasaan intuitif bahwa tim bisa mengeluarkan Juni yang lain. Dan pada saat itu adalah mungkin untuk mengambil seorang pria ambisius yang hebat yang dengan cepat tumbuh menjadi seorang insinyur yang berkualitas. Dalam tim dengan proses yang sudah mapan, pelatihan sangat cepat. Ya, dan jasanya berbeda - beberapa datang setelah universitas dengan mata menyala, tetapi mereka tidak bisa melakukan apa-apa, sementara yang lain memiliki tujuh tahun pengalaman backend di belakang mereka, mereka hanya beralih ke aplikasi seluler.
Artinya, kami tidak takut pada junior, tetapi kami fokus pada perasaan tim - apakah itu perlu atau tidak.
Penjadwalan, sinkronisasi, distribusi tugas
Apakah perencanaan dan sinkronisasi pengembang dalam perusahaan besar (bahkan dalam tim kecil) membutuhkan banyak energi?Philip Uvarov (Spotify) : Ini hanya pembagian tim berdasarkan produk dan bukan berdasarkan fungsi: kami hanya merencanakan produk kecil kami di dalam perusahaan dan kami sering tidak peduli dengan apa yang dilakukan oleh jutaan pengembang lainnya.
Artem Olkov (Odnoklassniki): Di sini saya hanya dapat berbicara tentang tim khusus kami. Kami telah memulai pengembangan, dan ini memberikan indulgensi tertentu - memungkinkan Anda untuk lebih bebas. Saat ini, kami hanya memiliki rapat harian 15 menit tentang status saat ini dan penutupan per jam dari rencana sebelumnya / sprint berikutnya seminggu sekali. Yang lainnya diputuskan berdasarkan pribadi.
Maxim Efimov (Uber): Dalam kasus kami - tidak terlalu besar. Mungkin 1,5-2 kali lebih banyak daripada yang saya rasakan ketika saya mengerjakan outsourcing.
Benar, ada beberapa proses dalam perusahaan, seperti review kode, yang menghambat pengembangan. Secara kasar, sampai beberapa tim yang bertanggung jawab atas kode mereka melihat komit Anda, mungkin hanya perlu waktu. Tetapi saya tidak berpikir bahwa ini mengacu pada biaya sinkronisasi. Lebih lanjut tentang bagaimana keseluruhan skema ini diatur pada tingkat rendah - siapa yang merevisi siapa, bagaimana penantiannya diatur, dll.
Evgeny Suvorov (Avito): Kami awalnya memecahkan masalah sinkronisasi dengan rilis yang sering. Akibatnya, sinkronisasi itu sendiri sekarang butuh sedikit. Semuanya hampir otomatis.
Apakah saya perlu mendistribusikan tugas dengan cara khusus sehingga kualitas kode tidak terganggu?Philip Uvarov (Spotify) : Dalam tim besar, masuk akal untuk mendistribusikan produk berdasarkan bidang tanggung jawab. Dengan demikian, akan selalu ada orang yang akan secara bertanggung jawab mendekati mereka karena mereka akan hidup dengannya nanti. Konteksnya tidak berubah, mis. , ( 10 , 5 , ).
« », - , backend- .
(Avito): , code review. , backend- — Python, PHP, Go — Avito. , .. , — .
- , ?(): , . , , , — : , , , , .
(Avito): , , — , , .
, . , - , . . .
backend- , — — . , .
- / ? ?(Spotify) : . , , Gradle Bazel Teamcity , . , .
(Uber): Uber- , . , , Kotlin. , , . . . , « » : « Kotlin-». Kotlin , .
, . , - , . , .
(Avito): , . . , , ().
Technology Radar. : « , 5 , .. ». , Technology Radar, , , , - , , - , - , - . , , . , Technology Radar .
?(Uber): , . , 10 - - . . 100 , , 99. , , , .
( )?(Avito): , — , , , . — .
- , , .
. Android- — IDE early adopted preview . , .
(Spotify) : , Kotlin — - . , Java Android, Kotlin . , — Facebook — Kotlin- , , , Kotlin .
Flutter.
(): , iOS — , Apple. . , . .
, , — . Unidirectional Data Flow.
Swift?(): . Swift, 150 Objective-C, .. Swift , .
Objective-C , Swift? , , Swift — HR-PR-, , Objective-C .
(Avito): . Swift . , , , . . Swift , Objective-C, , , .
( )?(): . Apple , , Swift , open source. , . Objective-C .
( ) — — - , , . , . , — . iOS — , , .
? TDD ?(Spotify) : , Android , . , .
(): , . Unit- .
Unit- , ( ). (API, UI ..) — .
(Uber): , TDD, . , , — .
(Avito): . , , -. UI- unit- . , — , UI-.
. — . TDD.
TDD . Android- , .
AppsConf 2018 TDD.
, .
- ?(Spotify) : , . 100% - unit- .
(Uber): , . , . .
- «» ?(Spotify) : — .
, - (proof of concept ), , . , , , .
(Avito): , , QA-, , backend, frontend . . , , QA.
?(Spotify) : , code review — . CI: , code style —
AppsConf 2018.
: pull request, code style, ; , . , git-. — , : , .
(Uber): Code review — , . , . .
(Avito): code review- -. , , -, , , . -.
, . . , . , , (« ?»). , , .
. , . , , . . , - code review. , .
?(Spotify) : , .
(): , , . , «» «». — , . — — . . - .
. , Android- .
(Uber): , , — . .
build train, . - — . .
. , : . , .
(Avito): — 12 . , . , - ( , -).
-, . . . — . . , — , . , - . .
. , , . . . , , , . .
. AppsConf 2018ApplsConf 2018 . , .