Manusia adalah nilai utama dari setiap perusahaan. Keberhasilan semuanya tergantung pada bagaimana orang berkomunikasi satu sama lain, bagaimana mereka mencapai tujuan bersama, dan pada kerja tim. Keterampilan, proses, dan alat yang terus diasah memungkinkan Anda untuk bekerja lebih efisien.
Kami di Pasar bekerja untuk memberikan fitur baru kepada pengguna kami secepat mungkin. Untuk melakukan ini, kami terus-menerus mempelajari proses kami dan mengoptimalkan semua tahapan tugas. Hari ini kami akan memberi tahu pembaca Habr tentang optimalisasi salah satunya, yaitu proses peninjauan kode.
Pertama, Anda perlu membayangkan aliran apa dalam pembangunan yang telah kami adopsi:
Hal yang sama, hanya poin demi poin dan kata-kata:
- Pengembang mengambil tugas.
- Membuatnya.
- Mengisi Github dan membuka PR.
- Melewati tinjauan kode.
- Mengumpulkan dudukan demo dan memberikannya kepada penguji.
- Penguji memeriksa demo stand.
- Tugas yang diverifikasi dikumpulkan dalam rilis.
- Menguji dalam rilis.
- Layout pada prod.
- Pengujian akhir dalam pertempuran.
Berdasarkan bidang tanggung jawab, tugas dibagi menjadi langkah-langkah berikut:
1-5 - tanggung jawab pada pengembang;
6-7 - tanggung jawab pada tester;
8-10 - tanggung jawab pada master rilis.
Jadi, mereka mulai menganalisis apa yang paling memakan waktu bagi kita. Untungnya, ada alat analisis internal. Semua orang mengandalkan apa yang akan memakan waktu paling lama, tentu saja, proses pengembangan itu sendiri (status "Dalam Pekerjaan") ... dan ternyata seperti itu. Tapi satu saat yang paling mengejutkan kami. Durasi rata-rata ulasan adalah dua minggu!
Langkah 1. Parsing PR
Mulai mempelajari permintaan tarik, mereka langsung menghadapi satu fakta yang sangat menarik. Ternyata kami memiliki kuburan besar permintaan tarik tertutup. Sebagian besar penulis PR ini tidak lagi bekerja untuk perusahaan, tetapi warisan mereka masih bersama kami. Siapa yang belum pernah melihat dinosaurus, ini dia:
Permintaan penarikan ini menambah kebisingan dan mengganggu analisis waktu peninjauan kode yang benar. Dengan pikiran tenang, kami menutupnya. Tinggal menghitung waktu. Tapi itu masih di daerah 2-3 hari. Itu tidak baik.
Langkah 2: Membongkar dengan Browner
Reviewer adalah sistem yang dikembangkan di Yandex yang memanggil PR dua orang acak dengan keahlian dalam kode yang bisa berubah dan mempertimbangkan liburan dan absen. Analisis PR mingguan mengungkapkan sekelompok orang yang terus-menerus menyeret keluar tinjauan kode. Setelah mewawancarai kolega, kami menemukan masalah lain dalam proses kami. Kolega mengeluh bahwa mereka menerima terlalu banyak permintaan tarik per hari dari cemburu, dan mereka tidak punya cukup waktu untuk pekerjaan utama mereka.
Ini tidak sesuai dengan indikator kami: satu atau dua PR per hari per orang. Penelitian ini mengarah ke Github, di mana kami memiliki tim peninjau yang terpisah. Tim ini belum diperbarui selama beberapa tahun. Sejak itu, jumlah karyawan meningkat dua kali lipat, tetapi tidak ada satu pun pendatang baru yang termasuk dalam tim peninjau. Dengan kata lain, setengah dari tim tidak berpartisipasi dalam peninjauan kode sama sekali! Memperbaiki kesalahpahaman yang menjengkelkan ini.
Langkah 3. Memperluas Alat
Pada tahap ini, kami mencoba untuk menyederhanakan kehidupan pengulas yang sudah sederhana, seperti yang kami pikirkan. Alat-alat berikut ada di gudang front-end:
- checker gaya kode;
- uji coba;
- berbagai pemeriksaan kutu buku dalam PR itu sendiri;
- revisionis;
- peringatan pada pelacak surat dan tugas.
Tampaknya semuanya ada di sana. Ambil dan ulas!
Hal pertama yang ternyata salah: proses peninjauan kode yang berbeda dalam repositori yang berbeda. Kami menyatukan dan sekaligus membuktikan pembubuhan label untuk pencarian PR yang mudah melalui antarmuka Github.
Hal kedua yang mereka perhatikan: surat bukanlah alat terbaik untuk melaporkan status ulasan kode dengan cepat. Banyak, agar tidak terganggu dari pekerjaan, mem-parsing suratnya beberapa kali sehari. Utusan adalah masalah yang sama sekali berbeda. Reaksi terhadap pesan di messenger jauh lebih tinggi. Dan diputuskan untuk menghubungkan bot ke messenger kami. Bot mengirimkan peringatan tentang status ulasan kode untuk penulis permintaan tarik dan mendorong orang untuk meninjau. Sangat nyaman
Langkah 4. SLA Pertama
Sejalan dengan tindakan 2 dan 3, kami mulai bekerja sama dengan karyawan dan menjelaskan bahwa tinjauan kode tidak dapat dipisahkan dari tugas itu sendiri. Mereka menjelaskan bahwa membawa ke "Terverifikasi" adalah tanggung jawab pengembang. Selain itu, tanggung jawab tidak hanya untuk kolega, tetapi juga untuk pengguna! Pengiriman cepat fitur ke penjualan - itulah yang ingin saya capai. Dan tim bersimpati pada proses perbaikan.
Pada tahap ini, ide pertama tinjauan kode ideal lahir. Tentu saja, semua orang ingin itu terjadi dalam 5 menit, tetapi ini tidak selalu mungkin. Mempertimbangkan bahwa kami memiliki tim multi-regional (dengan perbedaan waktu empat jam), kami sepakat bahwa SLA kami akan menjadi satu hari, yaitu. 24 jam Perjanjian Tingkat Layanan ini diumumkan kepada semua karyawan dan, sambil menggosok-gosok tangan mereka, mulai menunggu hasilnya.
Namun situasinya belum berubah. Dalam minggu-minggu terbaik, setengah dari permintaan tarik masuk ke dalam 1 hari. Sisanya keluar untuknya.
Kami memiliki skrip kecil yang mengevaluasi ulasan kode waktu pada PR. Kami mulai menyalahkan mereka setiap hari untuk semua PR yang mencari "tertinggal". Hampir setiap hari ada paket seperti itu.
Butuh waktu lama untuk mengurai mereka. Paling sering, skrip itu sendiri secara tidak jujur menghitung waktu peninjauan. Dia tidak memperhitungkan bahwa beberapa PR dibuat di luar jam kerja (ya, beberapa orang yang memiliki ketrampilan tinggi suka bekerja selama satu atau dua jam di malam hari, datang kepada kami untuk bekerja!). Semua ini memberi tahu kami bahwa alat pemantauan permintaan tarik kami bukan yang paling efektif, karena tidak jujur. Saya harus menemukan alat baru.
Langkah 5. Pelacak SLA
Bantuan datang dari tempat mereka tidak menunggu. Rekan kami dari Tracker mengumumkan hal yang luar biasa: sekarang Anda dapat menginstal SLA di Pelacak itu sendiri. Selain itu, Anda dapat mengonfigurasinya dengan sangat berbeda. Timer tertentu dihidupkan oleh beberapa peristiwa dalam tugas. Untuk beberapa acara, itu bisa berhenti. Dan berhenti di beberapa acara. Ya, inilah yang kami butuhkan!
Mereka segera masuk ke studi rinci dokumentasi (omong-omong, ini dia ) dan mengatur antrian kami (ada beberapa dari mereka, karena ada beberapa repositori). Kami mengatur timer untuk menyala ketika beralih ke status "Need code review" dan berakhir ketika beralih ke status lain, kecuali untuk "Ada komentar" - ketika ia pergi, timer berhenti, mis. tidak kehilangan waktu.
Itu juga keren bahwa timer memperhitungkan jam kerja dan kalender! Kami menetapkan bahwa 9 jam ditugaskan untuk peninjauan kode, mis. satu hari kerja. Dalam hal ini, peringatan dipicu 2 jam setelah dimulainya, atau jika tenggat waktu sembilan jam dilanggar. Hasilnya adalah semacam pemantauan yang jujur. Pada awalnya, kami menyalakan timer untuk percobaan, mengumpulkan satu paket bug dan diekspor ke Pelacak.
Perlu dicatat bahwa timer diaktifkan hanya untuk tugas-tugas yang dibuat setelah implementasi timer itu sendiri. Karena itu, efek instan tidak dapat dilihat. Tetapi sudah pada tahap ini, dinamika positif dimulai. Kami mendapat efek sebulan kemudian, ketika aliran tiket baru dengan timer mulai memadatkan yang lama. Terlihat bahwa perkiraan waktu tinjauan kode terkonsentrasi di bidang pesan pengingat, mis. menandai 2h dan 9h.
Pada saat penulisan ini, kami memiliki 415 tugas di mana timer telah dimulai. Dari jumlah tersebut, 29 melampaui batas sembilan jam. Meskipun, jika Anda melihat lebih dekat, Anda juga akan menemukan tugas-tugas seperti itu, yang peninjauan kodenya selesai dalam waktu satu jam berikutnya. Jika kita membuangnya juga, maka 17 tugas tetap ada. Dan ini sekitar 4,1%!
Hasilnya Samurai terus menerus mengasah pedangnya
Melihat ke belakang dan mengingat kembali semua tindakan kita, satu kesimpulan dapat ditarik - semua cara adalah baik. Semua langkah kami menghasilkan hasil yang diinginkan: lebih dari 92% permintaan tarik mulai memuaskan SLA kami ! Tugas yang kurang dan kurang robek, review kode lebih cepat. Perlahan, sedikit demi sedikit, 75% dari tinjauan kode mulai masuk ke dalam 5 jam ! Dan dinamika untuk perbaikan masih positif. Selain indikator numerik, kami mulai menerima lebih banyak umpan balik positif dari subkontraktor. Bahkan lebih senang dengan kenyataan bahwa tim bereaksi terhadap seluruh proses ini. Bahkan proses seperti akselerasi tinjauan kode semakin meningkatkan semangat tim. Setiap peserta mulai memahami tanggung jawab yang dipikulnya di depan orang lain, karena kode ulasan cepat memungkinkan kami untuk memberi manfaat lebih cepat kepada pengguna kami.
Tentu saja, 9h bukan impian utama, tetapi masih sukses. Tapi di situ kita tidak berniat berhenti. Kami terus memantau proses peninjauan kode dan menyelesaikan semua masalah teknis dan bahkan psikologis yang dihadapi karyawan sehingga proses kami seproduktif mungkin dan pada saat yang sama nyaman bagi tim.
T&J. Bagaimana jika ...?
T : Bagaimana jika saya pikir mereka memperhatikan saya? Untuk apa timer ini?
A : Kami memantau tidak secara khusus untuk seseorang, tetapi untuk prosesnya. Ada dua sisi permintaan tarik: penulis dan pengulas. Jika pengulas mengeluarkan cek, maka penulis menderita. Di sisi lain, itu juga tidak manusiawi untuk merobek inspektur dari pekerjaan segera. Penting untuk menemukan keseimbangan agar kedua belah pihak merasa nyaman. Pengatur waktu diperlukan bukan untuk menghukum seseorang, tetapi untuk merekam semua penyimpangan. Sebagian besar penyimpangan ini tidak terjadi karena kesalahan pengulas, tetapi karena kesalahan masalah teknis. Tantangannya adalah untuk memperbaiki masalah ini. Sehingga orang lain tidak menemui mereka. Perbaikan diri terus menerus
T : Dan bagaimana jika ada PR kompleks, 100500+ baris kode, dan ada "ubah hurufnya." Dimana keadilannya?
A : Ya, ini benar. Ketika kami mengerjakan ulasan kode standar, kami hanya membawanya sepanjang batas atas, mis. review kode PR kompleks harus sesuai dengan SLA. Tetapi pada saat yang sama, kami tidak memiliki tujuan untuk mengarahkan semua orang ke batas-batas ini. Kami selalu bersimpati untuk menarik permintaan, di mana ada diskusi yang hidup dan bermanfaat, meskipun ada bilah yang rusak dalam satu hari.
Kami memiliki rencana untuk nilai SLA pada titik penyimpanan. 1SP - 1h, 3SP - 5h, 5SP - 2d, misalnya. Untungnya, Pelacak sudah mampu melakukan ini. Kami belum siap untuk ini - kami masih memiliki jalan panjang.