Bagaimana cara mendorong pengembang junior untuk berpartisipasi dalam tinjauan kode?


13

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?


2
Saya bertanya-tanya apakah ini mungkin bukan pertanyaan yang lebih baik untuk Workplace.SE, tetapi 2 sen saya sendiri sebagai pengembang junior. Ketika saya masih magang, saya sangat gugup untuk berpartisipasi dalam ulasan kode karena beberapa alasan: kurangnya keterampilan, kurangnya keakraban dengan basis kode, dll. Saya segera menemukan bahwa berpartisipasi dalam tinjauan kode membantu dengan kedua aspek tersebut ( khususnya keakraban), dan juga sangat membantu dengan membuat saya merasa basis kode kami adalah sesuatu yang saya minati, jadi saya ingin berkontribusi. Saya jelas tidak selalu meninggalkan komentar yang bagus, tetapi saya tidak tahu sampai saya (lanjutan)
Dannnno

2
(lanjutan) mencoba, dan itu membantu saya bekerja lebih baik dengan tim secara keseluruhan. Saya pikir jika Anda mencoba menjelaskan mengapa hal itu membantu Anda, tim, dan basis kode bagi mereka untuk berpartisipasi, bahkan jika komentar mereka salah; jika komentar mereka salah, itu hampir lebih baik karena mereka dapat belajar darinya.
Dannnno

Jawaban:


15

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.

Terima kasih banyak atas masukannya, saya akan memikirkan hal ini dan membahasnya di stand up besok
Graham S

1
Saya akan menambahkan: cara Anda menjadi seorang ahli adalah dengan membuat kesalahan dan belajar darinya. sebagai hal yang praktis, mungkin bermanfaat bagi sr. devs untuk menceritakan beberapa kisah perang tentang kekacauan masa lalu mereka.

5

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.


+1 untuk melibatkan bagian otak yang berbeda. Dalam pengalaman saya, terutama ketika saya masih seorang junior dev, hanya mengetahui kode saya akan ditinjau oleh rekan kerja membuat saya memperhatikan detail yang mungkin saya abaikan.
Laconic Droid

0

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.


-3

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.


5
1) Menugaskan "menyalahkan" untuk bug adalah cara yang bagus untuk menyebabkan staf Anda pergi 2) Menugaskan menyalahkan kepada staf junior karena gagal menemukan bug yang ditulis oleh staf senior sangat buruk.
Philip Kendall

2
@ PhilipKendall Jika kode saya memiliki bug, tidak ada yang perlu menyalahkan saya. Saya seorang profesional dan sangat bangga dan bertanggung jawab atas pekerjaan saya. Apakah ini semacam zaman baru di mana tidak ada yang melakukan kesalahan dan semua orang mendapatkan piala untuk partisipasi?
JeffO

@ PhilipKendall: Saya tidak tahu di mana Anda bekerja ... Di mana saya bekerja, saya akan mengatakan "betapa bodohnya saya membuat" dan pengulas mengatakan "dan saya juga melewatkannya" dan kemudian kami berdua tertawa. "Menyalahkan" berarti mengambil tanggung jawab, tidak berdiri di sudut dengan topi bodoh.
gnasher729

1
@ gnasher729 Yap. Tapi tidak ada yang "kesulitan" untuk itu.
Philip Kendall
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.