Bagaimana cara berurusan dengan seseorang yang tidak menyukai gagasan ulasan kode?

26

Jelas, jika manajemen mau menghabiskan waktu dengan ulasan kode, maka semua orang harus melakukannya.

Tetapi selalu ada orang-orang (atau perempuan) yang menolak dengan setiap ons dari keberadaan mereka.

Bagaimana Anda mengelola secara efektif berurusan dengan skenario ini ketika menghadapinya sebagai peer reviewer?

development-process code-reviews

— ozz
sumber

19

Mungkin dengan cara yang sama Anda berurusan dengan orang-orang yang mempermasalahkan hal-hal lain seperti kode pakaian, ketepatan waktu, hari sakit, dll.

— Josh K

hehe .... Saya mencoba untuk memenuhi syarat bahwa sedikit tentang manajemen mengatakan semua orang harus melakukannya, apa yang saya cari adalah ketika Anda peer reviewer rendahan harus mencoba dan menyelesaikannya.

— ozz

3

Jujur: Katakan pada mereka untuk tutup mulut dan lakukan itu. Ini untuk kebaikan mereka sendiri.

— Steven Evers

1

Menolak apa? Membiarkan Anda melihat kode mereka atau mereka melihat kode Anda? Mereka mungkin menghindari konflik, bisakah mereka mengharapkan konflik? Apakah Anda tahu mengapa mereka ragu-ragu?

— Martin Maat

46

Dia menolak karena takut . Pengondisian ini mungkin merupakan hasil dari pengalaman buruk sebelumnya tentang ditinjau, sebagai seorang anak, di sekolah, di tempat kerja atau bahkan di tim Anda saat ini. Dalam masyarakat modern kita, sangat umum bagi kita untuk membingungkan hasil kerja seseorang dengan nilainya sebagai manusia. Itu sebabnya ulasan di tempat kerja tidak diterima dengan baik. Itu juga mengapa berbicara di depan umum di salah satu fobia yang paling menyebar (takut akan hukuman).

Untuk menghindari perilaku seperti itu, Anda perlu beberapa psikologi. Anda harus membuktikan kepada otak kadal itu bahwa hal itu tidak akan terjadi (dia tidak akan dihakimi, dihina, dibunuh, apa pun ...) dengan membuat dia pingsan terhadap kode ulasan.

Salah satu metode paling efektif yang saya temukan untuk membuka blokir seseorang adalah memintanya untuk meninjau kode Anda , sebelum meminta untuk meninjau kodenya.

Setelah beberapa saat, usulkan dia untuk membaca kode untuk belajar darinya dan mengapa tidak menyarankan perbaikan. Ketika Anda menemukan sesuatu untuk diubah, berhati-hatilah dengan apa yang Anda tulis. Dia akan mengerti tidak ada yang perlu ditakuti, dan dia akan mengambil bagian positif dari proses peninjauan saja: belajar dan meningkatkan pengetahuannya .

— Michael K.
sumber

3

Anda mungkin ingin menambahkan definisi untuk "otak kadal" untuk orang-orang yang tidak terbiasa dengannya.

— Adam Lear

@ Anna: Saya baru saja menambahkan tautan ke definisi.

Jawaban yang luar biasa Pierre! Terpilih untuk saat ini sebagai pengganti jawaban akhir.

— ozz

1

@ Harun: Saya merujuk ke "seseorang" yang disebutkan dalam pertanyaan. Ya, saya masih memiliki ketakutan yang tidak rasional karena mengkondisikan kehidupan anak dan dewasa saya, seperti kebanyakan dari kita. Contoh: Saya punya ketakutan irasional terhadap harga tertinggi. Saya membuat diri saya peka ketika saya bisa. Akhir pekan lalu saya mengunjungi benteng (sangat umum di negara saya karena perang berturut-turut antara Prancis dan Jerman) dan harus naik trem.

1

Seperti biasa jawaban Pierre yang luar biasa.

— Josh K

5

Saya akan mencoba bekerja berpasangan - tim seseorang yang membenci ide dengan seseorang yang menyukainya, dan minta mereka meninjau kode masing-masing selama beberapa minggu. Jelas ini mungkin atau mungkin tidak membantu, tetapi berada di kedua ujung review akan setidaknya memberikan pandangan yang lebih menyeluruh dari proses. Memiliki kerja sama pasangan akan memungkinkan mereka untuk mengenal gaya masing-masing dan kesalahan umum dan akan memberi mereka waktu untuk benar-benar membantu satu sama lain menjadi lebih baik, daripada stempel karet. Ini juga dapat membantu Anda mempromosikan pemrograman pasangan di lingkungan kerja Anda, karena saya pikir Anda mungkin melihat kecenderungan yang berkembang untuk tidak hanya meninjau, tetapi juga mengkode ulang atau bahkan merencanakan dan kode dari awal.

Selama pihak-pihak yang berkepentingan bersedia untuk mencoba, ini bisa membantu. Jika mereka menolak untuk mempertimbangkannya, tidak banyak yang dapat Anda lakukan selama mereka berada di tim.

— Michael K.
sumber

Pemrograman pasangan adalah topik lain, tetapi saran yang bagus!

— ozz

Komentar Anda membuat saya berpikir lebih banyak tentang PP, jadi saya memulai Q - programmers.stackexchange.com/questions/39878/… terima kasih lagi!

— ozz

4

@ Jawaban Pierre tepat untuk seseorang yang takut akan tinjauan kode. Saya bisa membayangkan situasi lain. Seorang programmer bintang yang merasakan review kode adalah buang-buang waktu karena ada kode mencapai standar kualitas dan kebenaran yang dapat diterima. Dalam hal ini mereka mungkin merasa review kode adalah pemborosan waktu dan perburuan. (Itu adalah pencarian masalah ketika tidak ada.)

Dalam hal ini saya akan mengarahkan kembali tujuan ulasan. Alih-alih tinjauan kode menjadi tentang menemukan "masalah" dalam kode, memperlakukannya sebagai pencarian target anjak piutang atau potensi peningkatan di masa depan, atau fitur desain tambahan. Dengan cara ini, baik coder dan reviewer terlibat dalam proses dan mudah-mudahan programmer ini akan merasa seperti ada waktu dimanfaatkan dengan baik.

— Hogan
sumber

5

Dengan tipe orang ini, Anda dapat mencoba memberi tahu mereka bahwa Anda bersemangat untuk meninjau kode mereka karena Anda pikir Anda akan belajar banyak dari mereka. Peninjauan kode tidak hanya tentang kode yang diperbaiki tetapi tentang mengekspos orang lain di tim ke kode yang lebih baik yang akan membantu mereka dalam pengembangan di masa depan.

— HLGEM

2

Terus terang, pertanyaan ini tidak masuk akal jika Anda memiliki toko yang dikelola dengan baik:

1) Jika itu bagian dari pekerjaan, Anda harus melakukannya, atau Anda tidak patuh. Seseorang yang dengan tegas menolak untuk melakukan bagian dari pekerjaan yang harus mereka lakukan harus dikalengkan. Pemrograman adalah keahlian dan profesi - pengulas dan manajer ada untuk membantu menyelesaikan pekerjaan, tidak berurusan dengan anak-anak manja (dari segala usia.)

2) Jika Anda memiliki sistem kontrol sumber yang dikelola dengan baik, (yang merupakan keharusan di setiap toko perangkat lunak profesional), maka kode mereka dapat ditinjau apakah mereka suka atau tidak. Jadi tinjau kode mereka:

Jika itu baik, beri tahu mereka dan beri mereka tepukan di punggung - itu akan mendorong partisipasi.
Jika tidak bagus, beri tahu mereka juga. Ini harus memiliki efek memotivasi mereka untuk berpartisipasi, untuk membela diri. Jika tidak, Anda dapat menggunakan langkah-langkah hukuman: Denda keuangan, penurunan status, dll. Jika upaya Anda tidak berhasil, karyawan ini gagal datang, IMO Anda memiliki karyawan yang buruk dan mereka harus ditunjukkan pintu.

— Vektor
sumber

Itu benar-benar saran yang sia-sia, saya meramalkan "toko" dengan lingkungan kerja yang sangat buruk untuk Anda. Urgghh!

— cognacc

@cognacc - Anda tidak perlu 'mengabaikan' apapun. Saya telah bekerja dalam kelompok selama 25 tahun di mana kami memiliki lingkungan kerja yang sangat baik : Kita semua orang dewasa dan mengerti apa yang diperlukan untuk menjadi profesional dan memiliki akuntabilitas untuk pekerjaan kita.

— Vektor

1

Saya harus setuju dengan Vector. Jika itu bagian dari proses, semua orang melakukannya dan saya yakin mereka dengan cepat melihat bahwa "itu tidak menggigit". Selalu ada risiko beberapa orang bersikap "kasar" dalam komentar mereka dalam tinjauan kode, tentu saja, tetapi orang-orang itulah yang perlu ditangani - sama seperti jika mereka bersikap kasar kepada rekan kerja mereka secara langsung.

— MetalMikester

Saya setuju dengan cognacc, tidak ada gunanya menyarankan karena tidak menyarankan strategi atau solusi. Itu hanya mengatakan "mereka harus karena mereka harus". Duh. Pertanyaannya adalah bagaimana menghadapinya, seperti bagaimana membalikkannya. Hanya membuat orang melakukan sesuatu yang bertentangan dengan keinginan mereka (atau yang lain) tidak memperbaiki masalah, kemungkinan membuat yang baru. Anda harus terlebih dahulu memahami asal usul perlawanan.

— Martin Maat

Anda merindukan toko saya yang dikelola dengan baik dan semua yang mengikuti darinya: Itu berarti Anda berurusan dengan orang dewasa: Orang-orang yang tahu apa arti pekerjaan mereka. Anda gagal memahami jawaban saya yang sangat jelas.

— Vektor

1

Apakah mereka memiliki pengalaman negatif di tempat-tempat di mana ulasan kode tidak dilakukan dengan benar? Mereka mungkin memiliki masalah yang sah.

Jika mereka benar-benar tidak melihat manfaat dari latihan ini, mintalah mereka untuk bersabar dan melihat apa yang terjadi pada kode mereka dan terutama yang lain (jika mereka pikir mereka sempurna) sebagai hasilnya.

Tinjauan Kode 'harus' meningkatkan pengembangan, tetapi sampai Anda memiliki sistem yang benar-benar berfungsi, mengapa ada yang mau melakukannya?

— JeffO
sumber

Terima kasih Jeff, setuju, jika prosesnya tidak baik, itu akan sulit, dan mengatasi ketakutan irasional siapa pun bisa sulit - beberapa orang tidak akan berubah!

— ozz

1

tetapi sampai Anda memiliki sistem yang benar-benar berfungsi, mengapa ada yang mau melakukannya? Biarkan saya mengambil menusuk liar di ini: Lakukan sehingga Anda dapat mengetahui mengapa sistem Anda tidak berfungsi ?

— Vektor

1

@Vektor - Jika Anda programmer tidak tahu cara membuatnya bekerja, mereka mungkin memiliki masalah yang lebih besar. Saya juga berpikir manajemen harus mengambil tanggung jawab dan membuat definisi kode kualitas yang jelas. Jika kode yang dirilis tidak memiliki terlalu banyak bug, mereka mungkin memiliki alasan yang baik untuk tidak memasukkan ulasan kode. Untuk proyek dengan segala jenis kompleksitas, saya ragu itu terjadi tanpa peninjauan kode kualitas atau mungkin waktu dan biaya pengembangan yang tidak proporsional.

— JeffO

@ Jeffoff - OK, saya mengerti maksud Anda: Jika sistem benar-benar tidak berfungsi, itu bukan pertanyaan "review kode", pertanyaannya adalah kompetensi pemrogram, dan "tinjauan kode" yang sederhana bukanlah solusi. Saya setuju dengan itu.

— Vektor

1

Saya pribadi bahwa ada beberapa perkelahian yang tidak bisa dimenangkan dengan 100% populasi.

Saya dapat melihat alasan yang cukup mengapa pemrograman pasangan tidak bekerja ketika seseorang dipaksa untuk melakukannya.

Tetapi review kode berbeda - mereka mengubah produktivitas Anda, belum tentu kebiasaan kerja Anda.

Manajemen dapat melakukan beberapa hal untuk mengurangi resistensi karena produktivitas: 1) Menerima pengurangan kecepatan untuk semua pengembang. 2) Menyediakan alat yang tepat untuk menangani manajemen dan penggabungan berbagai versi karena siklus peninjauan (mis., Memungkinkan pengembang memiliki repositori git lokal) 3) Menegakkan beberapa tekanan sosial atau bentuk lain untuk memastikan distribusi muatan dan kualitas dan ketepatan waktu ulasan.

Jika mereka melakukan itu, itu sah untuk meminta semua orang untuk berpartisipasi, IMHO. Perusahaan saya sekarang bekerja untuk kekuatan ini secara global - Anda tidak bisa mengirimkan tanpa persetujuan pemilik. Dan sementara ini memperlambat segalanya, itu mencegah banyak kecelakaan.

— Uri
sumber

Sepenuhnya setuju Uri ... hanya ada beberapa orang yang tidak bisa Anda menangkan. Mungkin mereka diatur dalam cara mereka, malas, berpikir cara mereka benar, atau sekadar tidak peduli !!

— ozz

0

Kami menggunakan langkah-langkah teknis untuk membuat peninjauan kode wajib.

Cara kami memperkenalkan tinjauan kode adalah bahwa dalam kontrol sumber kami, tidak mungkin untuk menggabungkan kode yang tidak ditandatangani oleh orang lain daripada orang yang mendorongnya.

— Pieter B
sumber

-1

Pecat mereka

Sesederhana itu - apakah mereka mendapatkan proyek sendirian, atau mereka harus pergi. Singkirkan mereka dari tim Anda. Mereka tidak hanya tidak melakukan bagian mereka, mereka mengikis moral dan praktik tim.

Sekarang, jika tampaknya Anda harus memecat 50% dari tim Anda, maka ...

Memahami

Mengapa ada yang menolak? Apakah mereka tidak punya waktu? Apakah mereka terbakar? Apakah ulasan tentang sesuatu yang tidak mereka alami? Apakah mereka pikir itu buang-buang waktu, kalau begitu mengapa?

Metodologi Agile akan membantu di sini - Saya mengasumsikan Anda terus bekerja melawan silo (yaitu untuk mengurangi faktor bus), dan individu dalam tim Anda terlibat dalam apa yang dilakukan orang lain.

Bekerja untuk memastikan permintaan gabungan individu cukup kecil. Jika lebih dari 1 layar perubahan, perlu bicara siaga atau kilat untuk menjelaskan apa yang sedang dilakukan. Jika 10 halaman, perlu presentasi dengan slide dan diagram arsitektur.

Apakah semua orang yang bersangkutan bekerja di proyek yang sama?

Apakah proyek sudah terkubur di bawah gunung utang teknis?

Apakah mereka percaya pada proyek dan perbaikan berkelanjutan?

— Dima Tisnek
sumber

1

Hmmmm .... jadi tidak percaya ulasan kode memberikan lebih banyak manfaat daripada biaya secara otomatis berarti seseorang tidak melakukan bagian mereka dan mengikis moral tim, sedemikian rupa sehingga mereka harus dipecat? Itu sikap yang agak berani berdasarkan tidak ada bukti yang mendukung klaim tersebut.

— Dunk

@Dunk, apakah Anda seorang anti-resensi? Maka Anda tidak akan berada di tim saya. Apakah Anda pro-resensi? Maka Anda sudah tahu dukungan untuk klaim saya. Apakah Anda ragu-ragu? Harap

— putuskan

Saya bukan anti-resensi buku tetapi saya juga mengenali ketika ada sesuatu yang tidak memberikan manfaat yang wajar relatif terhadap biaya. Beberapa proyek / tim benar-benar membutuhkan tinjauan kode resmi sementara proyek / tim lain hanya melakukannya ketika dianggap bermanfaat. Asumsi Anda bahwa tinjauan kode selalu diperlukan memberi tahu saya bahwa Anda bahkan tidak tahu manfaat dan keterbatasan sebenarnya. Jadi kamu benar. Saya tidak akan berada di tim Anda dan itu akan menjadi kerugian besar bagi Anda.

— Dunk