Seberapa penting umpan balik positif dalam ulasan kode?


48

Apakah penting untuk menunjukkan bagian yang baik dari kode selama ulasan kode dan alasan mengapa itu baik? Umpan balik positif mungkin bermanfaat bagi pengembang yang sedang ditinjau dan bagi orang lain yang berpartisipasi dalam ulasan.

Kami sedang melakukan tinjauan menggunakan alat online, sehingga pengembang dapat membuka ulasan untuk kode komitmen mereka dan orang lain dapat meninjau kode mereka dalam periode waktu tertentu (misalnya 1 minggu). Orang lain dapat mengomentari kode atau komentar pengulas lainnya.

Haruskah ada keseimbangan antara umpan balik positif dan negatif?


3
Hei, jika lewat, itu umpan balik positif. :)
Adrian J. Moreno

1
Sebagian besar, saya pikir itu tergantung pada orang yang kodenya sedang ditinjau. Jika mereka akan bereaksi negatif dengan hanya menerima kritik, maka penting untuk menemukan keseimbangan; jika tidak, umpan balik positif berlebihan karena ulasan yang lewat pada dasarnya positif. Jika mereka melakukan sesuatu yang baru dan luar biasa Anda dapat menyebutkannya, tetapi memasukkannya ke dalam praktik terbaik tim Anda juga akan menjadi umpan balik positif.
Matt

SE mencakup baik upvotes dan downvotes, jadi umpan balik positif harus penting untuk membuat hal-hal berfungsi dengan baik. Bagaimana hasilnya jika pertanyaan dan jawaban Anda yang terbaik di sini adalah nol? Ini adalah perbedaan stereotip antara pria dan wanita: untuk pria, tidak ada umpan balik berarti "tidak apa-apa". Bagi wanita itu berarti: "tidak ada yang baik untuk dikatakan." Ini mungkin sangat membantu dalam menjelaskan daya tarik relatif bidang ini untuk pria dan wanita.

Jawaban:


41

Tingkatkan Kualitas dan Semangat Menggunakan Peer Code Reviews
http://www.slideshare.net/SmartBear_Software/improve-quality-and-morale-using-peer-code-reviews

Hal Yang Harus Dilakukan Setiap Orang: Tinjauan Kode
http://scientopia.org/blogs/goodmath/2011/07/06/things-everyone-should-do-code-review/

Kedua artikel ini menyatakan bahwa salah satu tujuan dari tinjauan kode adalah untuk berbagi pengetahuan tentang teknik pengembangan yang baik, bukan hanya menemukan kesalahan.

Jadi menurut saya ini sangat penting. Siapa yang ingin pergi ke pertemuan dan hanya dikritik?


26
Saya! Saya! Selain sarkasme, saya benar-benar menjadi sangat jengkel dengan ulasan kode di mana tidak ada kritik terhadap kode saya; Saya tahu saya tidak melakukan hal-hal dengan sempurna dan kurangnya kritik membuat saya merasa seperti membuang-buang waktu bahkan meminta ulasan. Jadi saya setuju bahwa tidak ada yang lain kecuali kritik itu buruk, tetapi tidak ada yang baik.
Jimmy Hoffa

3
Saya cenderung setuju dengan Jimmy Hoffa. Secara umum (bukan hanya dalam ulasan kode), saya merasa sangat menjengkelkan untuk berurusan dengan orang-orang yang mencoba untuk membuat banyak umpan balik positif. Umpan balik positif harus bermanfaat: tidak perlu mencemari ulasan dengan mengatakan hal-hal yang sudah diketahui oleh pembuat kode. Secara pribadi, saya lebih suka sikap: "Anda hebat dan pintar, tetapi ada beberapa masalah kecil dalam kode Anda."
Arseni Mourzenko

6
@MainMa: "Terlihat baik-baik saja" bekerja untuk saya, jika tidak ada masalah yang ditemukan. Untuk kode yang sangat berguna atau ditulis dengan baik: "Ini bisa berguna. Mari kita masukkan ke arsip berbagi kode kita dengan beberapa catatan, atau cobalah untuk memasukkannya ke dalam praktik pengkodean harian kita."
Robert Harvey

2
Kami pernah meminta seseorang untuk berhenti karena dulu ulasan kode kami sangat mengerikan. Kami sejak itu beralih ke menggunakan tinjauan kode sebagai lebih dari sebuah lokakarya, dengan sedikit kritik kode untuk masalah serius, tetapi sebagian besar untuk pendidikan. Pria yang berhenti terlibat pertengkaran dengan manajer kami selama peninjauan karena perbedaan pendapat. Orang-orang dapat menjadi sangat defensif selama ulasan, jadi saya sangat merekomendasikan memberikan umpan balik positif untuk meredakan ketegangan dan membuat momen "Anda harus mengubah ini" lebih mudah bagi orang yang ditinjau untuk ditangani, jika tanpa alasan lain daripada kadang-kadang menyuntikkan ego
Brian

2
@Brian Saya harus mengatakan, jika seseorang terlibat dalam pertengkaran karena kritik kecil, mereka kemungkinan besar akan mencela budaya perusahaan dan moral kantor, saya pikir Anda lebih baik.
Jimmy Hoffa

29

Ketika saya melakukan review kode, saya cenderung hanya memiliki monolog yang sedang berjalan, jadi ketika saya memahami apa yang saya baca akan ada banyak "Ok, saya mengerti apa yang terjadi .. Bagus terhubung dengan ini dan memanggil itu, baiklah .. dan bagian itu tergantung pada keduanya baik - baik saja. "

Saya pikir dengan cara ini bukan "oo la la ini begitu hebat!", Itu bisa menjadi kode membosankan sepele, tetapi mendengar orang lain benar-benar mengurai dan menunjukkan pemahaman tentang apa yang Anda tulis adalah bentuk umpan balik positif di dalam dan dari dirinya sendiri, umpan baliknya adalah "Kode ini masuk akal", ketika saya menemukan bagian-bagian yang saya tidak mengerti, saya meminta penjelasan dan ketika saya memahaminya berseru, "Ah, saya mengerti".

Saya pikir transfer pemahaman yang sederhana adalah pujian untuk insinyur lain karena kita semua ingin kode kita dipahami oleh orang lain, itu memberikan bentuk validasi implisit.

Yang mengatakan, jika Anda melihat bagian dari kode yang karakteristik baik atau positif (bahkan kode sepele yang membosankan dapat menjadi baik jika itu bentuk minimal dari dirinya sendiri) Saya pasti cenderung menyatakan karakteristik itu, sekali lagi saya tidak menganggapnya sebagai "Wow Bagus!" sama seperti "Saya melihat ini adalah implementasi minimal" atau "Ok, algoritma yang kompleks ini memiliki banyak komentar", fokus pada atribut kode tidak begitu banyak sifatnya baik atau buruk.

Setiap kali Anda mengaitkan "kebaikan" atau "kejahatan" dengan kode dalam tinjauan kode untuk menghindari membuat insinyur merasa diremehkan atau dipegang di atas alas tidak mengatakan sesuatu itu baik atau buruk, tetapi lebih baik membicarakan sebab dan akibat dari kode mereka.

"Ok bagian ini masuk akal, ah ada angka ajaib di sini, arti dari nilai itu mungkin tidak dipahami dengan baik oleh insinyur berikutnya untuk menyentuh ini"

"Aku tahu kamu punya wadah DI di sini ok jadi kamu akan kehilangan kopling dengan repositori itu"

"Ah ada kamus statis di sini, jika banyak utas menyentuh kamus itu kita bisa mengalami beberapa kondisi lomba"

Perhatikan, saya tidak mengatakan sesuatu yang baik atau buruk, tetapi apakah insinyur harus mengubahnya atau tidak akan dipahami oleh insinyur yang kodenya sedang ditinjau. Jelas Anda harus mengakhiri tinjauan kode dengan yay atau nay, tetapi mengumpulkan pernyataan ini selama itu akan melunakkan nay sebagai penjelasan telah dibuat dalam bentuk sebab dan akibat pernyataan ketika Anda memberi tahu mereka "Saya ingin angka-angka ajaib diperbaiki sebelum memeriksa ini di ".


4
+1 untuk "transfer pemahaman sederhana adalah pujian untuk insinyur lain ... ini memberikan bentuk validasi implisit"
Roy Tinker

Saya ingin memberi ini +1 dua kali. Satu untuk alasan yang sama dengan @RoyTinker, dan satu untuk "Jangan mengatakan sesuatu itu baik atau buruk, tetapi lebih baik bicarakan sebab dan akibat". Keduanya poin yang sangat bagus!
Ben Lee

7

Jika saya melihat sesuatu dalam ulasan kode yang sangat saya sukai dan berada di atas dan melampaui kode "cukup baik", saya akan memberikan umpan balik positif.

Secara umum, saya berpikir bahwa jika seseorang menulis sepotong kode yang benar-benar membuat Anda berkata "Wow, ini sangat bagus!" maka ya, umpan balik positif itu penting - itu membuat penulis tahu bahwa apa yang mereka lakukan dinikmati oleh orang lain, dan mereka harus mencoba melakukannya lagi. Itu harus lebih dari sekadar mengikuti pedoman dan praktik standar. Memberikan pujian karena seseorang membuat indentasi dengan baik atau menambahkan komentar boilerplate dapat mengatur bar agak rendah.


6

Ini bukan pertanyaan pemrograman seperti pertanyaan manajemen umum dan interaksi manusia. Umpan balik positif dalam ulasan kode sama pentingnya dengan umpan balik positif dalam segala jenis ulasan.

Apakah ini diperlukan atau tidak (dan sejauh mana diperlukan) adalah fungsi dari disposisi dan susunan emosional orang yang Anda ajak bicara. Beberapa orang merespons koreksi dengan lebih efektif ketika ditambah dengan pujian. Orang lain melihat pujian sebagai tidak tulus ketika disampaikan dengan koreksi.

Formula umum kadang-kadang disebut "Sandwich Umpan Balik": Barang bagus dulu, barang buruk kedua, barang bagus lalu. Idenya adalah untuk menjaga nada keseluruhan positif sementara pada saat yang sama memastikan bahwa umpan balik negatif diterima. Ini dapat membantu mencegah stres saat mengantisipasi peninjauan, dan membantu mencegah merenung sendiri setelahnya. Keduanya sangat penting sehubungan dengan produktivitas dan kualitas. Ini bukan hanya omong kosong emosional yang sensitif; Itu perilaku manusia 101.

Sekali lagi, Anda harus tahu orang yang bekerja dengan Anda dan memahami apa yang mereka tanggapi. Berurusan dengan orang adalah tentang manajemen, dan manajer yang baik tahu bagaimana membuat orang merespons.


4

Saya pikir umpan balik positif sangat penting dan itu terutama dari pribadi, dinamika realpolitik. Kita semua duduk dan menulis kode selama berjam-jam, berhari-hari, berminggu-minggu, berbulan-bulan, dan kebanyakan dari kita bangga dengan apa yang kita lakukan. Ulasan kode adalah kesempatan untuk menunjukkan hal itu.

Jika Anda pergi ke tinjauan kode dan hasil terbaik yang dapat Anda harapkan adalah "tidak ada komentar" (yaitu tidak ada keseimbangan umpan balik positif), rapat dapat dengan mudah diberi judul dalam pandangan "Cari Tahu Bagaimana Orang Buruk Mengira Anda Mengisap". Akibatnya, pengembang akan mulai merasa terganggu oleh atau bahkan takut kode ulasan, dan itu jelas merugikan tim. Pengembang akan "lupa" untuk memeriksa kode mereka atau akan mengembangkan ketidakberdayaan yang dipelajari dan hanya meminta kritik terus-menerus mereka apa yang harus dilakukan tentang setiap hal kecil untuk menghindari terkutuk dalam pertemuan ini.

Semuanya baik dan bagus untuk mengatakan bahwa, secara teoritis, paling logis untuk memperbaiki yang buruk dan meminta semua orang meninggalkan emosi di depan pintu, tetapi justru sikap seperti itulah yang bertanggung jawab terhadap pengembang rep yang menjadi tuli nada interpersonal. Di luar teori, kita manusia dan manusia suka mendapatkan tepukan di punggung dari waktu ke waktu, bahkan yang nominal. Itu penting.


Ini mengingatkan saya pada konsep yang disebut "Appreciative Enquiry", yang mencari cara untuk meningkatkan dan memperluas apa yang sudah berfungsi, daripada berfokus pada masalah yang harus dipecahkan.

3

Ini lebih penting jika Anda melakukan review berdampingan atau tim. Dalam ulasan tertulis, tidak ada berita adalah kabar baik. Tujuannya adalah memasukkan kode ke dalam produksi. Ketika itu adalah kode Anda, Anda harus merasa nyaman dengan diri sendiri.

Peninjauan kode harus digunakan sebagai sumber informasi untuk membantu membimbing dan mengelola tim. Ada banyak peluang untuk memberikan umpan balik positif tanpa mengacaukan basis data tinjauan kode. Contoh dapat ditarik untuk dibagikan kepada orang lain.

Ada lebih banyak untuk meninjau pengembang selain kode mereka. Waktu tinjauan kode pembajakan bisa kontraproduktif untuk mengeluarkan aplikasi. Tetapkan waktu yang khusus untuk membantu pengembang di luar tinjauan kode, tetapi itu tidak berarti Anda harus mengecualikan umpan balik ulasan kode.


2

Satu-satunya cara yang bisa saya pikirkan di mana memberikan umpan balik positif tentang kode bisa menjadi bumerang bagi Anda adalah jika Anda tidak hati-hati untuk menghindari "pujian backhand." Kebanyakan orang akrab dengan ini ... itu ditandai dengan frasa seperti, "Kerja bagus, tapi ..."

Jika semua orang datang ke pertemuan dengan sikap bahwa ini bukan ulasan pribadi programmer, tetapi upaya untuk meningkatkan praktik pengkodean untuk kualitas seluruh sistem, maka semua umpan balik adalah umpan balik "baik". Umpan balik yang menyoroti cara untuk meningkatkan praktik pengkodean menjadi sama pentingnya dengan umpan balik yang menyoroti metode baru yang berguna untuk menangani masalah.

Paling tidak, jika seseorang tidak sampai sejauh itu, harus ditekankan bahwa berusaha untuk melakukan siklus "umpan balik yang baik, umpan balik yang buruk, umpan balik yang baik, umpan balik yang buruk" dalam proses peninjauan hanya akan menemukan dengan perasaan pujian backhand yang sama. Jangan mencoba memaksakan umpan balik yang baik, mencoba untuk memperkuat upaya yang baik, dan menopang lubang pengetahuan.

Frase yang paling saya pelajari dari, selama bertahun-tahun:

  • "Itu pendekatan yang menarik. Apa yang terjadi jika kita harus mengakomodasi [beberapa use case lain]?"
  • "Percobaan yang bagus! Apakah kamu tahu kita sudah memiliki metode untuk melakukan itu? Mungkin kita harus melakukan pembandingan untuk melihat pendekatan mana yang lebih efisien."

2

Alur kerja yang paling saya sukai dengan ulasan kode adalah ini:

  1. Dev mengirimkan tambalan pada milis / alat online.
  2. Setiap orang yang perlu memperhatikan patch, menyarankan perbaikan.
  3. Dev kembali ke # 1
  4. Jika tidak ada perbaikan yang diperlukan, orang-orang mengatakan, "Kerja bagus, silakan berkomitmen." <- UMPAN BALIK POSITIF. Semua kode yang diterima adalah baik. Semakin sedikit orang harus memberi tahu Anda untuk mengubah sesuatu, semakin baik yang Anda lakukan.
  5. Dev berkomitmen, beralih ke item berikutnya.

Biasanya yang akan terjadi adalah para pengembang baru akan mendapatkan lebih banyak umpan balik 'koreksi' karena mereka terbiasa dengan basis kode.

Manfaat dari pendekatan ini adalah:

  1. Semua orang tahu apa yang dilakukan semua orang. Tidak ada pengetahuan yang dimonopoli atau misteri.
  2. Semua orang belajar dari umpan balik orang lain. Ini penting. Jika umpan balik hanya terjadi antara 2 orang dalam percakapan tatap muka saat berpasangan, maka seseorang di sisi lain ruangan tidak mendapat manfaat dengan cara yang sama seperti jika terjadi di milis.
  3. Pengembang lain biasanya dapat menemukan beberapa bug sebelum mereka berada di kontrol versi.

Jadi, pada dasarnya, Anda berharap tidak mendapat umpan balik sama sekali. Kenapa repot-repot pergi bekerja? Anda bisa tidak terlihat di rumah.

1

Saya tidak bisa setuju dengan ini sama sekali. Apa perbedaan antara Teknik Pengembangan Baik dan apa yang disebut Ninja Coders yang dapat menulis kode manusia yang luar biasa tetapi tidak bisa dijelaskan? Pengembangan Perangkat Lunak saat ini (IMO) merupakan disiplin yang paling rendah di mana penyerang dan kelicikan dijauhi demi kelestarian dan kemudahan pemahaman. Terlalu berisiko.

Saya tidak dapat memikirkan waktu yang pernah saya lihat kode dalam ulasan yang akan membuat saya pergi 'Oh itu keren'. Saya hanya bisa berasumsi bahwa jika saya menemukan kode seperti ini, itu akan jatuh ke kamp Cool-Yet-Unacceptable.

Anda juga memiliki masalah dengan orang-orang yang tidak mendapat umpan balik positif mungkin berusaha terlalu keras dan akhirnya membuat kekacauan "Percayalah padaku, itu berhasil!".

Peninjauan kode ada untuk menyebarkan tanggung jawab kualitas kode di antara tim, yaitu pengembang individu tidak dapat disalahkan jika masalah serius muncul kemudian. Gunakan untuk menemukan masalah, gunakan untuk mendapatkan penjelasan dari pengembang asli tentang hal-hal aneh jika Anda akhirnya harus memeliharanya. Secara pribadi, saya lebih tertarik untuk menerima umpan balik negatif. Pelanggan tidak peduli dengan kesejukan kode Anda, hanya saja ia melakukan apa yang mereka inginkan.

Biarkan backslapping ke pub.


1
"Pelanggan tidak peduli dengan kesejukan kode Anda, hanya saja ia melakukan apa yang mereka inginkan." Pelanggan juga tidak peduli dengan keterbacaan kode. Mereka mungkin peduli tentang berapa lama waktu yang diperlukan untuk memperbaiki bug, menambahkan fitur, atau mengubah beberapa perilaku, tetapi mereka tentu tidak peduli tentang keterbacaan kode per se.
CVn

1

Itu penting bagiku. Saya tidak ingin komentar atau kepositifan hanya demi kepositifan. Jika semua kode yang saya tulis jelek, Anda memberi tahu saya alasannya dan mari kita perbaiki dan pelajari. Tetapi jika saya melakukan sesuatu dengan benar, senang mendengarnya sekali dan sementara waktu. Saya tidak perlu penguatan positif untuk semua yang saya lakukan yang "benar", tetapi bahkan jika itu adalah "mari kita tingkatkan X, Y, dan Z, tetapi sisanya terlihat bagus" itu penting.


0

Tidak sepenting umpan balik yang jujur. Saya bekerja untuk perusahaan finansial besar, dan pelanggan kami tidak peduli jika programmer berusaha keras atau orang yang baik, atau biasanya menulis kode yang baik! Mereka membutuhkan perangkat lunak yang berfungsi.


Pengalaman saya adalah bahwa programmer yang berusaha keras, adalah 'orang baik' dan senang dengan tim yang mendukung cenderung menulis perangkat lunak yang berfungsi.
c_maker

Ayam dan telur kurasa. Tetapi pertanyaannya adalah tentang tinjauan kode ... yang menurut saya bukan waktu untuk melakukan ego ...
aserwin

Peninjauan kode bukan waktu untuk menentukan apakah bagian yang terlihat oleh pengguna dari perangkat lunak bekerja sesuai dengan spesifikasi.
CVn

0

Saya pikir penting untuk sepenuhnya objektif. Berusaha meningkatkan moral dengan membuat komentar positif adalah buang-buang waktu di pikiran saya.

Ini dapat berarti bahwa ulasan kode terlalu kritis - tetapi bukankah itu intinya. Kita juga harus kritis terhadap diri kita sendiri. Saya menemukan bahwa asumsi bahwa kode yang saya tulis mungkin adalah sampah lengkap dan pasti dapat ditingkatkan mendorong saya untuk meningkatkan kode dan tingkat keahlian saya.

Jika Anda tidak mendapat komentar maka Anda dapat mempertimbangkan bahwa Anda telah melakukan pekerjaan dengan baik.


Mungkin inilah sebabnya kebanyakan programmer adalah pria.

-1

Mantra sederhana: Jika seseorang menginginkan Kode kualitas (yang sebenarnya kurang) maka metode peninjauan yang tepat harus dipraktikkan. Karena itu, umpan balik positif membantu pengembang / programmer untuk berpikir dan menghasilkan ide / solusi / perbaikan. Jangan terlalu keras, tapi tegaslah pada intinya. T&J Manajer harus mengetahui metodologi dan praktik yang baik sehingga ia dapat membimbing tim (atau anggota) ke arah yang benar. Ini menghasilkan kualitas. Titik.


-3

Ketika kode untuk kompetisi atau diajukan untuk wawancara kerja (dengan kata lain, kode yang ditulis dan tidak dapat ditulis ulang), maka komentar positif adalah suatu keharusan. Bahkan, Anda harus memastikan bahwa ada umpan balik positif (jika mungkin!) Dan juga negatif. Dengan begitu, pembuat kode tahu di mana kekuatan dan kelemahannya berada, dan bisa mengimbanginya.

Namun, Anda tampaknya berbicara di lingkungan tempat kerja, tempat kode dapat ditulis ulang. Dalam hal ini, Anda mencoba mengeluarkan bug dari sistem Anda. Jadi, dalam situasi itu, hanya bug negatif yang berharga.

Jika Anda merasa tidak nyaman tentang hal itu, lakukan rapat tinjauan kode mingguan, di mana semua orang dapat mendiskusikan kode baik dan kode buruk.

EDIT: Meskipun saya akan mengatakan bahwa, jika sesuatu cukup membuat Anda terkesan, tidak ada yang menghentikan Anda untuk mengekspresikan pujian secara langsung. Namun, pelacak tampaknya hanya untuk tinjauan kode produksi.


6
"Jadi, dalam situasi itu, hanya serangga negatif yang berharga." - Saya tidak bisa setuju dengan itu sama sekali. Jika seseorang menemukan cara yang bagus untuk memperbaiki bug / mengimplementasikan fitur, itu sama sekali tidak berharga. Dan menjaga motivasi tetap penting. Jika Anda hanya menyoroti kegagalan, Anda akan mengalami masalah.
Mat

Pilihan kata yang buruk di pihak saya. Meskipun hal-hal yang baik tidak ada nilainya (setelah menulis cukup sampah di waktu saya), bug, kemungkinan besar, untuk apa pelacak diatur. OP dapat, jika dia memilih, memberikan komentar positif. Tapi, secara pribadi, saya akan meninggalkan itu untuk percakapan tatap muka, karena mencegah pelacak tersumbat. Juga, saya sangat kesal saya tidak bisa memberikan komentar. :)
KBKarma

1
@KBKarma - jika Anda merasa bahwa jawaban asli Anda tidak diutarakan sebaik mungkin, silakan kembali dan edit jawaban Anda untuk mencerminkan pikiran Anda dengan benar. Cari tombol edit di bawah jawaban Anda.
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.