Saya adalah pengembang Java terkemuka di Yandex.Money.

Setiap pagi di tahun 2018, saya bertemu dengan sekitar 30 permintaan tarik yang menunggu untuk ditinjau, dan saya tidak punya cukup waktu untuk memilah semuanya dalam sehari. Pada akhir musim panas, saya pergi berlibur, dan ketika saya kembali, saya menemukan antrian 50 PR ditugaskan untuk saya. Tidak ada keinginan untuk menyapu mereka, tetapi sebenarnya itu hanya puncak gunung es, yang saya lihat dengan mata kepala sendiri. Hari itu saya memutuskan bahwa sudah waktunya untuk mengubah sesuatu.

Ini adalah kisah tentang bagaimana kami mempercepat peninjauan kode, menurunkan pengembang terkemuka dan meningkatkan alat yang kami gunakan setiap hari.

Ulasan Kode 1.0. Bagaimana sebelumnya?

Di Yandex.Money, tinjauan kode telah lama menjadi tahap pengembangan wajib, dan semua orang sudah terbiasa dengannya. Beberapa orang menyadari bahwa ini sama halnya dengan pengujian; yang lain menganggap ini sebagai kejahatan yang perlu, dan seseorang menemukan ulasan kode hanya sebagai penulis permintaan tarik, tetapi menghindari tinjauan kode orang lain. Saya pikir banyak yang melakukan perjalanan secara berurutan dari yang terakhir ke yang pertama, dan ini normal.

Untuk ulasan kode, kami menggunakan Bitbucket dari awal. Untuk setiap repositori komponen, daftar 3-4 pengulas default telah ditambahkan, yang ditambahkan ke semua PR. Biasanya daftar ini disusun dan diedit oleh kepala departemen, dan kadang-kadang sukarelawan yang ingin meninjau komponen tertentu ditambahkan di sana. Dalam repositori perpustakaan itu sedikit lebih mudah - daftar pengulas adalah sama untuk semua perpustakaan, dan pengembang senior dimasukkan di sana.

Akibatnya, hampir seluruh beban ditanggung oleh pengulas dari antara pengembang senior, yang secara bertahap berhenti menjadi cukup, dengan mempertimbangkan pertumbuhan departemen menjadi 60 orang, peningkatan jumlah repositori (60+ komponen, 100+ perpustakaan) dan percepatan CI / CD kami.

Selain beban kerja yang berat dan kurangnya sumber daya pengulas, ada masalah lain:

• dalam beberapa komponen, orang dapat mengharapkan reaksi pengulas lebih dari satu hari,
• beban kerja yang tinggi dari mereka yang ditunjuk sebagai peninjau dalam beberapa komponen,
• sulit untuk menarik pengulas baru, termasuk karena paragraf sebelumnya,
• jika peninjau utama sakit atau sedang berlibur, peninjauan kode waktu komponen mulai meningkat secara nyata,
• pengulas yang ditunjuk tidak selalu memiliki keahlian yang nyata dalam komponen, karena kualitas review kode yang diderita.

Sebelum menyelesaikan masalah ini, Anda perlu memutuskan apa yang umumnya kami harapkan dari tinjauan kode.

Ulasan kode yang benar adalah bagaimana caranya?

Kami telah mengidentifikasi empat poin yang harus ada dalam tinjauan kode yang diperbarui:

1. Validasi arsitektur solusi . Hal yang sangat jelas. Kami mengharapkan ini dari pengembang senior yang memiliki keahlian dalam komponen ini.
2. Verifikasi implementasi teknis , yang kami harapkan dari spesialis senior dan menengah dengan keahlian dalam komponen ini.
3. Transfer pengetahuan , yang terdiri dalam studi logika bisnis dan basis kode oleh pemula dan Juni melalui ulasan kode.
4. Kemampuan menilai kemampuan keras pengembang . Saya ingin setiap pengembang diberi mentor yang mengevaluasi pertumbuhan, menentukan vektor pengembangan, memperhatikan beberapa kekurangan, membuat komentar, dan sebagainya. Karena itu, mentor juga harus melihat kode bangsanya.

Mungkin seseorang melihat tujuan lain atau tidak setuju dengan tujuan kita - bagikan dalam komentar. Sementara itu, saya akan beralih dari merumuskan tujuan menjadi menemukan cara untuk mencapainya - kami memutuskan bahwa kami ingin mencapai semuanya dan (hampir) segera.

Ulasan Kode 2.0. Bagaimana itu?

Apa yang kita hasilkan? Kami mulai memikirkan langkah demi langkah.

Di Yandex.Money, pengembang bekerja dalam tim di bidang bisnis, biasanya 2-4 pengembang backend dalam sebuah tim.

Katakanlah saya akan membuka permintaan tarik, yaitu, saya penulisnya . Saya memiliki tim saya , yang para pengembangnya sangat sadar akan logika bisnis dari apa yang saya lakukan, karena kita semua berpartisipasi dalam proyek-proyek umum, sering menyinkronkan dan umumnya aktif berinteraksi. Oleh karena itu, saya ingin menambahkan mereka ke permintaan tarik saya pertama-tama, sehingga mereka setidaknya up to date dengan apa yang saya lakukan.

Setiap komponen di Yandex.Money memiliki tim yang bertanggung jawab dan menyertainya dalam produksi.

Jika saya memodifikasi komponen yang menjadi tanggung jawab tim lain, maka tampaknya logis untuk menambahkan pengembang dari tim ini ke pengulas - mereka bertanggung jawab atas komponen ini dan harus memantau kualitas kodenya. Tetapi agar tidak membebani pengulas, kami hanya mengambil satu orang secara acak dari tim ini - kami yakin ini sudah cukup.

Mungkin saja tim yang bertanggung jawab atas komponen tersebut tidak memiliki keahlian yang memadai di dalamnya. Ini terjadi ketika pendatang baru muncul di tim atau mereka baru saja dipercayakan dengan komponen ini. Namun, saya tahu bahwa kami memiliki pakar nyata di perusahaan ini dalam repositori ini, dan akan sangat bagus jika salah satu dari mereka melihat kode saya! Tentu saja, pengetahuan saya sulit untuk diformalkan, tetapi Anda dapat mengambil sejarah repositori dan menghitung tinjauan kode berdasarkan jumlah PR dan statistik, yang sering mengerjakan kode ini dan / atau sering memeriksanya. Kami menghitung metrik keahlian dalam repositori, memilih pengembang teratas untuk metrik ini, memanggil mereka pakar dan menambahkan satu pakar acak ke pengulas.

Pada tahun 2018, kami memperkenalkan lembaga pendampingan di perusahaan, jadi sekarang satu mentor dari antara pengembang senior mengawasi setiap tim. Juga, setiap pendatang baru di perusahaan pada awalnya memiliki mentor pribadi.

Biarkan mentor saya memperhatikan kode saya! Dia akan dapat membantu jika terjadi masalah pada tinjauan kode, dan juga akan memiliki gagasan tentang kekuatan dan kelemahan saya dalam keterampilan teknis.

Secara total, lima hingga enam orang dapat ditambahkan ke pengulas setiap permintaan tarik. Tetapi pada kenyataannya, biasanya mereka sedikit lebih kecil, karena peran yang berbeda dapat digabungkan dalam satu orang. Mentor saya dapat menjadi ahli pada saat yang bersamaan, dan tim saya dapat bertanggung jawab atas komponen tersebut. Secara subyektif, 3-4 pengulas akan optimal untuk menarik permintaan.

Ulasan Kode 2.0. Apa yang ada di bawah tenda?

Intinya kecil: buat semuanya bekerja. Ini membantu di sini bahwa semua jajaran kami sudah diatur dalam sistem terpisah yang menyediakan API REST untuk menerimanya. Oleh karena itu, setelah beberapa minggu pengembangan santai di waktu luang saya, versi pertama plug-in untuk Bitbucket lahir, yang secara bertahap dikembangkan dan memperoleh semua set fungsi yang diperlukan selama musim gugur.

Cara kerja plugin

Biasanya, saat membuat PR, Bitbucket menyediakan pengunjung yang ditentukan dalam proyek atau pengaturan repositori. Dari sudut pandang pengguna, tidak ada yang berubah di sini - semua pengulas juga sudah diisi sebelumnya saat halaman ini dibuka, kecuali bahwa bidang telah ditambahkan dengan deskripsi pengulas mana dalam peran apa yang ditambahkan. Dan peran pengulas telah muncul sebagai berikut:

• rekan tim adalah anggota tim penulis PR, mudah ditambahkan berkat REST API dengan komposisi tim,
• pemilik repositori - anggota acak dari tim yang bertanggung jawab atas komponen; dalam pengaturan repositori itu perlu untuk memberikan kesempatan untuk memilih tim yang bertanggung jawab,
• ahli repositori - ahli repositori acak; Saya akan memberi tahu Anda lebih banyak tentang ini nanti
• mentor - mentor untuk tim atau pemula, juga tersedia melalui REST API dari layanan dengan komposisi tim.

Ahli Repositori

Saya akan memberi tahu Anda sedikit lebih banyak tentang bagaimana kami mempertimbangkan para ahli. Setiap hari, plugin melewati semua repositori, melihat semua permintaan tarik untuk tahun lalu dan mempertimbangkan dua metrik sederhana:

• jumlah permintaan tarik yang dibuat oleh pengembang,
• jumlah PR yang dia tinjau dan setujui, perlu bekerja atau menolak.

Kami menambahkan bobot ke metrik ini berdasarkan fakta bahwa dari sudut pandang keahlian dalam kode, penyempurnaan kode ini lebih penting daripada tinjauan. Pertama, kami memperkirakan jumlah permintaan tarik yang dibuat satu setengah kali lebih penting daripada ulasan, dan kemudian kami meningkatkan rasio menjadi tiga banding satu. Kami meringkas metrik yang dikalikan dengan bobotnya dan mendapatkan peringkat pengembang.

Selanjutnya, kami mengurutkan semua pengembang ini berdasarkan peringkat, pilih 5 teratas, di sepanjang jalan, potong mereka yang peringkatnya di bawah ambang batas untuk memotong orang yang lewat biasa. Dan kami biasanya mendapatkan dari tiga hingga lima ahli untuk setiap repositori.

Di atas, saya menjelaskan kepada Anda pendekatan untuk pemilihan pengulas, yang kami pilih dan terapkan, tetapi sepanjang jalan kami menerapkan beberapa perbaikan kecil sekaligus, yang membuat proses peninjauan kode lebih cepat, lebih mudah dan lebih menyenangkan.

Larangan permintaan tarik gabungan sampai tugas diperiksa di Jira

Suatu hal yang jelas dan perlu, yang, sayangnya, tidak keluar dari kotak. Kami hanya mendapatkan kode stabil di dev, yang lulus tidak hanya pemeriksaan statis dan tes pengembang, tetapi juga pengujian integrasi bersama dengan layanan lain. Status pengujian seperti itu bagi kita hanya tercermin dalam tugas Jira, dan karena itu, sebelum, pengembang harus secara manual melihat apakah tugas itu diperiksa untuk memperlambat permintaan tarikan.

Otomatis permintaan tarik gabungan

Tarik-permintaan dapat menghabiskan sebagian besar hidupnya dalam keadaan di mana tidak ada yang mencegahnya dari mengambil waktu, tetapi seseorang lupa untuk melakukan ini atau tidak segera. Contoh yang mencolok adalah harapan menguji suatu tugas, yang tanpanya kita tidak menyimpannya di dev. Di sinilah penggabungan otomatis berguna, yang bekerja sesuai dengan prinsip sederhana: jika PR dapat dibekukan, maka kita melakukannya.

Semua kondisi yang diperlukan untuk penggabungan dicakup oleh cek. Kami memeriksa keberhasilan perakitan, tingkat cakupan tes, tidak adanya snapshot dependensi dari perpustakaan, status tugas di Jira dan keberadaan semua pembaruan yang diperlukan. Artinya, kami memiliki segalanya untuk menggunakan fungsionalitas seperti itu dan melupakan PR dari saat melewati tinjauan kode dan menyerahkan tugas untuk pengujian (kecuali tentu saja QA menemukan masalah di dalamnya).

Dan kami menerapkan ini dengan cara yang lebih mudah: kami memperkenalkan bot AutoMergeBot khusus, yang hanya perlu ditambahkan ke pengulas, sehingga dapat mulai memantau permintaan tarik ini dan membekukannya ketika saatnya tiba.

Akuntansi untuk tidak adanya pengulas

Jika pemilik komponen atau pakar sedang berlibur atau cuti sakit, ia tidak akan ditambahkan oleh pengulas, dan tempatnya akan diambil oleh orang yang ada di tempat kerja. Sebagai bonus, segunung permintaan tarik orang lain tidak akan jatuh pada pengulas ini setelah meninggalkan liburan. Untuk menyadari ini tidak sulit karena fakta bahwa semua kekurangan karyawan dengan kami diajukan dengan aplikasi di Jira.

Akuntansi untuk pekerjaan pengulas

Seseorang mengulas sepuluh PR sehari, dan lima PR. Seseorang telah mengumpulkan 20 PR yang tidak ditinjau, sementara seseorang hampir tidak memilikinya. Kami memperhitungkan semua ini untuk mendistribusikan beban yang lebih merata pada pengulas. Semakin banyak beban, semakin sedikit itu ditambahkan ke PR baru - semuanya sederhana.

Menandai ukuran PR saat membuat

Pada halaman pembuatan permintaan tarik, penulis dapat memilih ukuran perkiraannya: S, M atau L. Ini membantu pengulas untuk memperkirakan perkiraan waktu yang akan mereka habiskan pada ulasan kode. Sebagai contoh, saya punya waktu 5 menit gratis, dan saya mengerti bahwa saya dapat mengatur untuk melihat ukuran permintaan tarik-permintaan S. Tidak masuk akal untuk membuka M atau L, karena saya tidak punya waktu untuk menontonnya dan waktu berikutnya saya harus mulai dari awal.

Di masa mendatang, kami ingin mempertimbangkan atribut ini saat menghitung statistik PR.

Pelabelan PR yang Mendesak

Juga, ketika membuat PR, penulis dapat menunjukkan bahwa tugas itu sangat mendesak dengan menambahkan simbol seperti itu ke nama PR. Ini akan segera dilihat oleh pengulas dan akan mencoba melihatnya terlebih dahulu. Tampaknya sedikit, tetapi sangat berguna dan nyaman.

Pelacakan awal dan akhir kode review

Jika sementara meningkatkan proses tidak mungkin untuk memahami berapa banyak yang telah ditingkatkan, maka tidak ada gunanya memulai.

Begitu pula dengan tinjauan kode - kita dapat mencoba memperbaikinya sebanyak yang kita suka, tetapi bagaimana kita bisa yakin akan dinamika positif tanpa metrik dan statistik? Dalam kasus kami, ini bukan tugas termudah - di luar kotak, Bitbucket dan Jira tidak memberikan kesempatan untuk melacak waktu peninjauan kode. Kami hanya dipersenjatai dengan metrik seumur hidup PR, yang tidak sesuai dengan kami, karena kami hanya menarik-permintaan setelah tugas pengujian berakhir, oleh karena itu indikator-indikator asing dicampur dalam metrik ini.

Jira menyimpan dan memungkinkan Anda untuk mengunggah semua titik kontrol dari siklus hidup tugas, jadi kami pikir benar untuk memperkaya data ini dengan dua label tambahan: waktu mulai dan akhir dari tinjauan kode. Itu hanya perlu untuk mengajarkan plugin untuk Bitbucket untuk mendorong tag ini di Jira. Dengan demikian, Jira adalah, dan tetap, satu titik kebenaran untuk tugas tersebut, dan dengan kumpulan data ini kita dapat memisahkan waktu tinjauan kode dari saat pengujian tugas.

Titik tertipis di sini adalah bagaimana menentukan kapan harus mengakhiri tinjauan kode? Mungkin ini saatnya untuk mendapatkan aplikasi pertama, mungkin yang terakhir, atau mungkin ini saatnya untuk perubahan terakhir yang dilakukan oleh penulis PR? Saya tidak punya jawaban untuk pertanyaan ini, di sini saya hanya perlu menyetujui di antara kita sendiri dan memilih satu hal atau menutupi ketiga peristiwa dengan metrik dan mengikuti penyimpangan.

Melacak unduhan pengulas

Metrik lain yang bermanfaat adalah beban kerja pengulas. Seperti yang saya tulis di atas, kami memperhitungkannya ketika menugaskan pengulas ke PR baru, tetapi kami juga menerbitkan informasi ini untuk memantau dinamika tim, departemen, atau perusahaan. Kadang-kadang ini membantu mendeteksi anomali dan masalah potensial: jika jelas bahwa satu atau lebih orang dalam tim menggantung 10 atau lebih PR yang tidak ditinjau setiap hari, maka ada alasan untuk mengetahui apakah semuanya beres.

Lihat metrik di Grafana

Membuat laporan tentang data dari Jira berguna, tetapi tidak terlalu nyaman, jadi kami juga menambahkan pengiriman metrik untuk acara utama di StatsD untuk membuat grafik pada data operasional di Grafana. Kami memantau waktu rata-rata hingga tes pertama, waktu hidup rata-rata PR, dan juga melihat nilai-nilai anomali untuk metrik ini agar dapat dengan cepat menemukan dan memecahkan masalah.

Pada saat penulisan, dasbor kami terlihat seperti ini:

Apa yang Anda dapatkan pada akhirnya?

Sayangnya, kita semua kuat di belakang, jadi kami tidak memperkenalkan metrik tinjauan kode yang disebutkan di atas sebelum proses itu sendiri mulai berubah (September-Oktober 2018), tetapi sudah di sepanjang jalan, sehingga kami hanya dapat melacak peningkatan atau penurunan yang dapat diandalkan dari awal Desember 2018 Apa yang berhasil kami perhatikan?

Hal pertama yang menarik perhatian Anda adalah pengurangan beban pada pengulas senior, dan saya merasakan ini dengan contoh saya sendiri. Seperti yang telah saya sebutkan, adalah normal bagi saya untuk melihat sekitar 30 PRs sejalan di pagi hari, tetapi sekarang jumlah ini berfluktuasi antara 10 dan 15. Statistik dari departemen mengkonfirmasi hal ini: sejak Desember 2018, jumlah maksimum PR yang menunggu tinjauan belum diajukan oleh siapa pun di atas 15. Rata-rata, kami mengamati gambar yang menunjukkan bahwa rata-rata setiap pengembang mengharapkan 4-5 PR yang tidak ditinjau di pagi hari, yang tampaknya merupakan angka yang cukup memadai.

Adapun relevansi pemilihan pengulas dan kualitas ulasan kode, di sini kita hanya dapat mengandalkan indikator subjektif. Menurut jajak pendapat kolega, kami benar-benar mulai mendapatkan pilihan pengulas yang sangat baik, sekarang tidak ada yang harus menambahkan secara manual, dan tidak ada PR yang ditinggalkan dan dilupakan.

Jika kita berbicara tentang waktu yang diperlukan untuk lulus tinjauan kode, maka terlalu dini untuk menghitung statistik pada indikator ini, karena kami mulai mengumpulkannya baru-baru ini. Yang kami miliki hanya ada waktu permintaan tarik, yang sebenarnya tidak naik atau turun. Metrik ini mencakup waktu pengujian tugas, sehingga sulit untuk membuat kesimpulan yang jelas tentangnya, selain itu, mengubah kode ulasan, kami tidak membuatnya lebih lama.