Bagaimana cara mendorong pengembang junior untuk berpartisipasi dalam tinjauan kode?

Saya saat ini bekerja sebagai dev senior dengan 3 junior di bawah saya dan telah memperkenalkan proses peninjauan kode untuk membantu mengelola kualitas kode menjadi produksi.

Saya merasa sangat bermanfaat bagi kita semua untuk saling meninjau pekerjaan masing-masing, namun setelah sekitar 5 minggu proses saya adalah satu-satunya yang memberikan komentar dalam alat (BitBucket).

Saya pikir ada bagian masalah budaya di tempat kerja, dan mungkin keengganan alami jika komentar mereka salah, tetapi apakah ada cara dan saya dapat membantu junior merasa lebih nyaman mengkritik saya dan masing-masing bekerja?

Bagi saya, pertanyaannya di sini adalah "apa yang Anda cari dari pengembang junior Anda untuk keluar dari ulasan kode?". Bagi saya, berpotensi hal yang paling penting bagi para pengembang junior untuk belajar dengan melihat apa yang semoga kode yang baik; jika mereka menemukan masalah dalam kode Anda juga, itu bonus.

Jika Anda mencari staf junior Anda untuk belajar dari ulasan kode, hal terpenting yang harus Anda lakukan adalah menciptakan lingkungan di mana pembelajaran dihargai, dan tidak dipandang sebagai pemborosan waktu. Ini berarti sejumlah hal:

• Tidak ada yang namanya pertanyaan bodoh . Jika seseorang tidak mengerti sedikit kode, mengapa Anda menggunakan pola tertentu atau apa pun, mereka perlu merasa bebas untuk bertanya, tanpa pernah dibuat merasa bahwa mereka membuang-buang waktu Anda atau pengembang lainnya. .
• Waktu yang dihabiskan untuk belajar adalah waktu yang dihabiskan dengan baik . Anda ingin pengembang junior Anda menghabiskan waktu melihat kode dan belajar darinya, karena itu akan membuat mereka menjadi lebih baik, lebih banyak staf yang produktif di masa depan. Kecuali itu perbaikan kritis yang perlu ditinjau sekarang , dorong mereka untuk menghabiskan lebih banyak waktu, bukan lebih sedikit, pada ulasan kode.
• Staf senior tidak selalu benar . Hanya karena Anda telah melakukan ini lebih lama bukan berarti Anda benar. Jika mereka merasa telah menemukan bug, mereka mungkin benar. Jika mereka berpikir pola desain lain akan sesuai untuk kode ini, maka mereka perlu merasa bebas untuk mengatakannya tanpa mendapat umpan balik negatif.

Adakan pertemuan tinjauan kode secara langsung pada waktu yang ditentukan setiap minggu. Saya menjual ini kepada rekan setim saya seperti ini (kami sebenarnya adalah pengembang senior, tapi apa pun):

"Peninjauan kode sebagian ada di sana bagi saya untuk mengetahui kode Anda sedikit lebih baik dan tahu apa yang terjadi di pihak Anda jika Anda tertabrak truk suatu hari nanti dan saya diperintahkan untuk menyelesaikan sprint Anda. Tapi terutama itu ada bagi Anda untuk menjelaskan kode Anda kepada orang lain, karena ketika Anda melakukannya, itu melibatkan bagian otak Anda yang berbeda, dan sering kali penjelasan Anda kepada mereka, dan / atau pertanyaan atau komentar mereka, dapat menyebabkan Anda mengingat sesuatu yang Anda lupa melakukan dalam kode, atau mungkin menyebabkan Anda menyadari cara yang lebih baik untuk membuatnya lebih mudah dibaca atau arsitek lebih baik. Itu mengarah pada kode yang lebih indah. "

Saya suka menganggapnya sebagai pertunjukan-dan-katakan. Orang-orang bisa memamerkan pekerjaan mereka kepada rekan-rekan mereka. Ini bukan tentang teman Anda yang menemukan kesalahan dalam pekerjaan Anda, yang tidak disukai oleh siapa pun. Ini tentang mengesankan rekan-rekan Anda dengan kode Anda yang luar biasa, yang disukai semua orang.

Namun saya pikir menggunakan alat review kode di mana tidak ada interaksi manusia, tidak ada pertemuan di sebuah ruangan, tidak ada papan tulis .. itu hanya menjadi "hal" yang mengganggu untuk dilakukan. Bukannya seharusnya tidak ada alat seperti itu, tetapi itu harus menjadi sesuatu yang Anda gunakan jika, selama pertemuan tinjauan kode, disadari bahwa tinjauan yang lebih mendalam tentang bagian kode tertentu mungkin diperlukan. Kemudian Anda dapat menugaskan salah satu dari yayasan pengembang untuk meninjau kode yang lain di area tertentu.

Anda dapat membantu dengan memberikan contoh yang baik. Anda tidak bisa bersikap defensif ketika seseorang menunjukkan kesalahan Anda. Lakukan tinjauan kode pada kode Anda sendiri dan perhatikan bidang-bidang perbaikan. Bagikan ini dengan tim. Akhirnya, mereka akan belajar bahwa ini dianjurkan dan tidak ada yang akan mendapatkan pukulan karena memiliki bug dalam kode mereka.

Memiliki pekerjaan berarti bertanggung jawab dan bangga pada pekerjaan Anda. Jika review kode adalah bagian dari itu, maka partisipasi dalam review kode harus dimasukkan dalam evaluasi. Saya telah mengambil kelas online di mana partisipasi dalam diskusi online adalah bagian dari kelas. Komentar perlu dijabarkan lebih lanjut. "Saya setuju" tidak dapat diterima.

Peninjauan kode harus meningkatkan kode. Tergantung pada situasi Anda, ini dapat diukur dengan angka penjualan, keluhan pengguna, atau peringkat lain jika Anda menulis kode untuk penggunaan internal. Kenyataannya adalah kode Anda melayani beberapa tujuan dan tim Anda harus diukur dengan seberapa baik mereka melayani tujuan itu. Orang-orang yang Anda tentukan berkontribusi untuk kesuksesan, dapatkan untuk berbagi secara proporsional dalam hadiah.

Fokus pada merilis kode kualitas. Tujuannya bukan untuk semua orang merasa nyaman dengan diri mereka sendiri dengan menjauh dari serangga. Saya menulis kode yang buruk; Saya harus memperbaiki kode yang salah. Itu pekerjaan dan kehidupan. Saya benci memperbaiki bug, jadi saya mencoba menghindarinya. Saya bangga dengan pekerjaan saya, jadi itu mengganggu saya ketika kode saya tidak berfungsi. Saya merasa tidak enak bagi para pengguna atau siapa pun yang harus meluangkan waktu untuk menunjukkan hal-hal ini dan itu memotivasi saya untuk ingin memperbaikinya.

Sebagai catatan tambahan, jika Anda memiliki lingkungan di mana tidak ada yang dapat memberi atau menerima kritik yang membangun, Anda memiliki masalah.

Prosesnya: Seseorang ingin melakukan perubahannya. Seseorang ditugaskan sebagai peninjau dan meninjau perubahan. Kemudian perubahan yang ditinjau dan diperbaiki pergi ke pengujian.

Jika pengujian menemukan bug yang diperkenalkan dalam perubahan, maka penulis dan pengulas sama-sama harus disalahkan.

Jadi melakukan tinjauan tanpa komentar akan membuat Anda kesulitan kecuali kodenya sempurna.