Frekuensi Tinjauan Teman / Kode


27

Saya tidak akan menyebut diri saya seorang superstar dev, tetapi yang relatif berpengalaman. Saya mencoba untuk menjaga kualitas kode ke level yang tinggi, dan saya selalu mencari untuk membuat perbaikan pada gaya pengkodean saya, mencoba untuk membuat kode efisien, mudah dibaca dan konsisten serta mendorong tim untuk mengikuti pola & metodologi untuk memastikan konsistensi. Saya juga mengerti perlunya keseimbangan antara kualitas dan kecepatan.

Untuk mencapai ini, saya telah memperkenalkan konsep peer review kepada tim saya. Dua acungan jempol di github pull-request untuk penggabungan. Hebat - tapi tidak menurut saya tanpa cegukan.

Saya sering melihat komentar ulasan sejawat dari kolega yang sama seperti -

  • Akan lebih baik untuk menambahkan spasi setelahnya <INSERT SOMETHING HERE>
  • Garis tambahan yang tidak diinginkan antara metode
  • Pemberhentian penuh harus digunakan pada akhir komentar di docblock.

Sekarang dari sudut pandang saya - peninjau secara dangkal melihat kode estetika - dan tidak benar-benar melakukan tinjauan kode. Ulasan kode kosmetik dianggap oleh saya sebagai mentalitas arogan / elitis. Itu tidak memiliki substansi, tetapi Anda tidak dapat benar-benar berdebat terlalu banyak karena itu secara teknis resensi benar . Saya lebih suka melihat lebih sedikit dari jenis ulasan di atas, dan lebih banyak ulasan sebagai berikut:

  • Anda dapat mengurangi kompleksitas cyclomatic dengan ...
  • Keluar lebih awal dan hindari jika / lainnya
  • Abstraksi permintaan DB Anda ke repositori
  • Logika ini sebenarnya bukan di sini
  • Jangan ulangi diri Anda sendiri - abstrak dan gunakan kembali
  • Apa yang akan terjadi jika Xditeruskan sebagai argumen untuk metode Y?
  • Di mana unit test untuk ini?

Saya menemukan bahwa selalu ada jenis orang yang sama yang memberikan ulasan kosmetik, dan jenis orang yang sama yang menurut saya memberikan ulasan sejawat "Kualitas & Logika".

Apa (jika ada) adalah pendekatan yang tepat untuk peer review. Dan apakah saya benar karena frustrasi dengan orang yang sama pada dasarnya membaca kode mencari kesalahan ejaan & cacat estetika daripada cacat kode yang sebenarnya?

Jika saya benar - bagaimana saya mendorong kolega untuk benar-benar mencari kesalahan dalam kode dengan menyarankan perbaikan kosmetik?

Jika saya salah - mohon beri tahu saya. Apakah ada aturan praktis untuk apa yang sebenarnya merupakan tinjauan kode yang baik? Apakah saya melewatkan inti dari tinjauan kode apa?

Dari sudut pandang saya - tinjauan kode adalah tentang tanggung jawab bersama atas kode. Saya tidak akan merasa nyaman memberikan acungan jempol ke kode tanpa mengatasi / memeriksa logika, keterbacaan dan fungsionalitas. Saya juga tidak akan repot-repot memblokir penggabungan untuk sepotong kode yang solid jika saya perhatikan seseorang telah menghilangkan berhenti penuh di blok dokumen.

Ketika saya meninjau kode, saya menghabiskan mungkin antara 15-45 menit per 500 Loc. Saya tidak dapat membayangkan ulasan dangkal ini membutuhkan waktu lebih dari 10 menit jika itu adalah kedalaman ulasan yang mereka lakukan. Selanjutnya, berapa nilai acungan jempol dari reviewer dangkal? Tentunya ini berarti bahwa semua ibu jari tidak memiliki bobot yang sama dan mungkin perlu proses review 2-pass. Satu jempol untuk ulasan mendalam dan jempol ke-2 untuk "pemolesan"?


2
Sudahkah Anda mencoba menyebutkan ini kepada orang itu?
Bryan Oakley

11
Saya memiliki atasan yang membutuhkan pemberhentian penuh dalam semua komentar, serta kapitalisasi dan tanda baca dan tata bahasa yang tepat. Dia juga sangat anal tentang ruang putih. Itu membuat saya gila, tetapi juga menyebabkan kode yang sangat mudah dibaca dan konsisten.
Bryan Oakley

4
Tiga peluru pertama di posting Anda adalah sepeda-shedding, kecuali mereka adalah bagian dari standar toko gaya pengkodean. Jika Anda menulis dokumentasi, saya harapkan ejaan dan tata bahasa yang sempurna. Itu tidak sulit untuk dicapai saat ini, mengingat banyaknya pemeriksa ejaan dan pemeriksa tata bahasa dalam pengolah kata. Demikian pula, masalah gaya pengkodean sering dapat diotomatisasi dalam editor kode yang sesuai. Saya tidak akan berharap melihat hal-hal semacam ini dalam ulasan kode; waktu semua orang terlalu berharga.
Robert Harvey

2
ulasan arogan / elitis itu mudah dan hampir tidak memerlukan usaha. Untuk membuat tinjauan teknis Anda harus membaca dan memahami kode dan kemudian memikirkan solusi yang lebih baik ... itu berarti Anda harus bekerja. Saya tidak terkejut dengan hasil proposal Anda. Anda harus mengatur proses peninjauan dengan tugas yang terukur dan terdefinisi dengan baik untuk mencapai sesuatu.
JoulinRouge

2
Jika Anda menggunakan Agile, ini adalah sesuatu yang dapat Anda tampilkan di retros tanpa menunjukkan satu target. Sebutkan bahwa fungsi utama dari tinjauan kode adalah kebenaran kode, dan bukan estetika kode. Dalam hal itu menjadi 'kebutuhan untuk berubah', dan sesuatu yang dapat Anda teruskan sampai benar-benar berubah.
Canadian Coder

Jawaban:


22

Jenis ulasan

Tidak ada satu cara sejati untuk melakukan peer review. Ada banyak cara untuk menilai apakah kode berkualitas tinggi. Jelas ada pertanyaan apakah itu buggy, atau apakah ia memiliki solusi yang tidak skala atau yang rapuh. Masalah kesesuaian dengan standar dan pedoman lokal, sementara mungkin tidak sepenting beberapa yang lain, juga merupakan bagian dari apa yang berkontribusi pada kode berkualitas tinggi.

Jenis-jenis pengulas

Sama seperti kita memiliki kriteria berbeda untuk menilai perangkat lunak, orang yang melakukan penilaian juga berbeda. Kita semua memiliki keterampilan dan kecenderungan kita sendiri. Beberapa orang mungkin berpikir bahwa mematuhi standar lokal sangat penting, sama seperti yang lain mungkin lebih mementingkan penggunaan memori, atau cakupan kode pengujian Anda, dan sebagainya. Anda ingin semua jenis ulasan ini, karena secara keseluruhan mereka akan membantu Anda menulis kode yang lebih baik.

Tinjauan sejawat adalah kolaborasi, bukan permainan tag

Saya tidak yakin Anda memiliki hak untuk memberi tahu mereka cara melakukan pekerjaan mereka. Kecuali Anda tahu sebaliknya dengan pasti, anggaplah bahwa orang ini sedang berusaha berkontribusi sesuai keinginannya. Namun, jika Anda melihat ruang untuk perbaikan, atau curiga mungkin mereka tidak mengerti apa yang diharapkan dalam ulasan sejawat, berbicaralah dengan mereka .

Inti dari peer review adalah untuk melibatkan rekan-rekan Anda . Keterlibatan tidak melempar kode ke dinding dan menunggu jawaban dilemparkan kembali. Keterlibatan bekerja bersama untuk membuat kode yang lebih baik. Terlibat dalam percakapan dengan mereka.

Nasihat

Menjelang akhir pertanyaan Anda, Anda menulis:

bagaimana saya mendorong kolega untuk benar-benar mencari kesalahan dalam kode dengan kesalahan estetika yang mencolok?

Sekali lagi, jawabannya adalah komunikasi. Mungkin Anda dapat bertanya kepada mereka, "hei, saya menghargai Anda mengetahui kesalahan ini. Ini akan sangat membantu saya jika Anda juga dapat fokus pada beberapa masalah yang lebih dalam seperti apakah saya menyusun kode dengan benar. Saya tahu ini membutuhkan waktu, tetapi itu akan sangat membantu."

Pada catatan yang lebih pragmatis, saya pribadi membagi komentar ulasan kode menjadi dua kubu dan frase mereka dengan tepat: hal-hal yang harus diperbaiki, dan hal-hal yang lebih kosmetik. Saya tidak akan pernah mencegah solid, kode kerja tidak diperiksa jika ada terlalu banyak baris kosong di akhir file. Akan saya tunjukkan, tetapi saya akan melakukannya dengan sesuatu seperti "pedoman kami mengatakan memiliki satu baris kosong di akhir, dan Anda memiliki 20. Ini bukan show-stopper, tetapi jika Anda mendapat kesempatan Anda mungkin ingin memperbaikinya ".

Ada hal lain yang perlu dipertimbangkan: mungkin Anda kesal karena mereka melakukan review dangkal terhadap kode Anda. Mungkin yang paling membuat mereka kesal adalah bahwa Anda (atau rekan setim lainnya yang mendapat ulasan serupa) ceroboh sehubungan dengan standar pengkodean organisasi Anda sendiri, dan ini adalah cara mereka memilih untuk berkomunikasi dengan Anda.

Apa yang harus dilakukan setelah peninjauan

Dan terakhir, sedikit saran setelah peninjauan: Ketika melakukan kode setelah peninjauan, Anda mungkin ingin mempertimbangkan untuk mengurus semua hal kosmetik dalam satu komit, dan perubahan fungsional pada yang lain. Menggabungkan keduanya dapat membuat sulit untuk membedakan perubahan signifikan dari yang tidak signifikan. Buat semua perubahan kosmetik dan kemudian lakukan dengan pesan seperti "kosmetik; tidak ada perubahan fungsional".


Terima kasih atas jawaban yang bagus. Saya rasa frustrasi saya terletak di mana biggermasalah tidak ditangani. Seperti indeks yang hilang pada tabel DB. Atau mencoba menggunakan metodologi atau algoritme tanpa memahami alasannya dan melakukannya dengan salah. Bagi saya - ini lebih penting dan harus ditangani dan diselesaikan terutama - dengan estetika menjadi perhatian sekunder.
Gravy

1
apakah Anda tahu masalah yang lebih besar sedang dilewatkan, atau apakah Anda hanya takut akan terjadi? Ketika masalah besar tidak terjawab, dalam rapat retrospektif atau tim Anda dapat mengemukakan bahwa ini adalah hal-hal yang harus ditangkap dalam tinjauan kode. Anda bahkan mungkin mempertimbangkan untuk bertanya siapa di tim yang berfokus pada perubahan basis data, dan jika tidak ada yang mengangkat tangan, mungkin menunjuk beberapa untuk mencoba fokus hanya pada perubahan db untuk ulasan berikutnya.
Bryan Oakley

Sejujurnya - sebagian besar komentar kosmetik umumnya tidak ditargetkan pada kode saya. Ketika saya meninjau kode orang lain, saya melihat komentar terhadap PR yang berkaitan dengan kosmetik, tepat di sebelah kode yang saya anggap sebagai masalah besar. Selanjutnya, banyak bahasa pertama tim ini bukan bahasa Inggris. Jadi dari sudut pandang saya - kesalahan ejaan / tata bahasa yang aneh bisa dimaafkan. Saya di sini bukan untuk meninjau penggunaan bahasa Inggris mereka dalam komentar doc-block, tetapi kode mereka.
Gravy

2
Nah, komentar mereka adalah bagian dari kode sumber, dan jika mereka sulit untuk diurai, menyesatkan atau bahkan salah, memiliki mereka sama sekali dapat merugikan bagi siapa saja yang kemudian memiliki kesempatan untuk melihat kode itu karena alasan apa pun. Mereka tidak perlu formal atau karya seni untuk mencapai tujuan mereka, tetapi bahasa Inggris yang rusak, terlepas dari kemahiran penulis dalam bahasa, menghambat tujuan. Lebih baik tidak memiliki komentar daripada yang buruk.
Deduplicator

1
Kebanyakan orang menghargai ketika kesalahan dalam bahasa ditunjukkan kepada mereka sehingga mereka dapat meningkat.
gnasher729

7

Orang-orang berkomentar tentang pemformatan kode dan kesalahan ketik karena mudah dikenali dan tidak memerlukan banyak upaya dari mereka.

Bagian ini mudah diperbaiki - hampir semua bahasa memiliki linter atau alat pemeriksa gaya. Plugin itu dalam proses membangun Anda, sehingga akan gagal membangun jika ada ruang yang berlebihan. Akibatnya tidak akan ada masalah gaya untuk dikomentari.

Membuat mereka menemukan masalah nyata mungkin cukup sulit. Tidak hanya ini membutuhkan pola pikir khusus yang ingin tahu dan berorientasi pada detail, tetapi juga motivasi yang signifikan.

Dan motivasi ini berasal dari pengalaman. Pengalaman mencoba bekerja dengan kode jelek yang ditulis oleh pengembang sebelumnya. Insinyur senior memiliki banyak hal. Berenang di lautan kotoran memberi Anda cukup keinginan untuk tidak sampai di sana lagi.

Jika saya perlu memilih satu hal utama untuk diperiksa selama peninjauan kode, itu adalah pemeliharaan kode. Setiap saat, pengembang yang meninjau kode ini harus memahaminya, dan siap untuk meningkatkan dan memodifikasinya. Jika dia tidak memiliki petunjuk tentang apa yang terjadi di sini, dia harus segera mengatakannya, dan kode harus ditulis ulang.


Saya setuju dengan Anda atas komentar Anda. Dan jika Anda melihat itu ocean of shitditulis oleh saya - maka saya akan mendorong Anda untuk menyarankan saya menulis ulang. Tetapi jika Anda mengabaikan shittetapi meminta saya untuk memperbaiki barang-barang kosmetik - itulah yang membuat saya frustrasi.
Gravy

4

Inilah jawaban praktisnya:

Skenario 1 : Anda adalah anggota senior dan seseorang yang dapat memutuskan praktik tersebut

Panggil rapat dan jelaskan aturan dan pedoman Peninjauan Kode. Percayalah, pedoman yang jelas bekerja lebih baik daripada sistem atau pelatihan 'kehormatan' apa pun. Jelaskan bahwa masalah pemformatan kode tidak boleh diangkat sama sekali. Beberapa anggota akan keberatan. Dengarkan mereka dan minta mereka untuk mengikuti pedoman selama beberapa bulan pertama sebagai percobaan. Tunjukkan kesediaan untuk berubah jika pedoman saat ini tidak berfungsi.

Skenario 2 : Anda bukan seseorang yang memutuskan latihan atau Anda adalah anggota yang relatif junior di tim

Taruhan terbaik Anda adalah dengan hanya menyelesaikan masalah ulasan kode sampai Anda berhasil mencapai skenario 1 .


2

Jawaban sederhana untuk mencegah komentar ulasan kode "sepele" adalah bersikeras (demi efisiensi) bahwa peninjau harus menjadi orang yang memperbaikinya. Jadi, jika peninjau menemukan bahwa Anda (horor!) Melewatkan fullstop atau mengeja komentar dengan keliru, mereka harus memperbaikinya dan melanjutkan.

Dalam pengalaman saya ini berarti:

  • pengulas Anda berhenti membuat komentar ulasan yang relatif tidak berguna ini dan meneruskannya untuk diperbaiki.
  • hanya sebagian besar pengulas OCD yang akan memperbaikinya, artinya sebagian besar ulasan Anda akan berlalu. ini memiliki efek knock-on yang mengharuskan pengembang untuk melakukan tinjauan yang lebih substantif, mereka yang melaporkan hal-hal sepele karena mereka tidak benar-benar meninjau kode akhirnya akan membenarkan mengapa semua ulasan mereka lolos tanpa komentar.

Either way, ini bermanfaat. Biaya ulasan yang gagal sangat tinggi dalam hal membuat pengembang menghentikan apa yang sedang dikerjakannya dan meninjau kembali kodenya, dan ulasan tindak lanjut selanjutnya. Jika ulasan menemukan kualitas kode nyata atau masalah arsitektur maka biaya ini bernilai setiap sen, tetapi membayar biaya ini untuk hal-hal sepele tidak.


0

Tinjau Proses Peninjauan

Selain ulasan kode, saya juga menyarankan untuk meninjau Proses Review secara teratur. Tentunya ada banyak hal yang dapat dipelajari orang di sini, misalnya bagaimana memberikan ulasan kode yang tepat.

Biasanya beberapa pemilik sepeda hanya tidak berpengalaman dan tidak tahu harus mencari apa. Mereka membutuhkan sedikit panduan tidak hanya terkait dengan kode mereka, tetapi juga vis-á-vis melakukan tinjauan kode bermanfaat. Memberikan umpan balik tentang ulasan akan mengarah pada proses pembelajaran yang (berharap) menghasilkan ulasan yang lebih baik, dan kode yang lebih baik.

Selanjutnya, mungkin ide yang baik untuk (secara longgar) memformalkan seperangkat nilai dan kriteria, apa yang organisasi atau tim anggap sebagai Good Code ™, dan apa yang merupakan pola-anti yang harus dihindari. Ini bukan tentang pengaturan sth. dalam beton, tetapi tentang mendapatkan konsensus bersama tentang kualitas kode dari awal .


0

Sebagai seseorang yang berada di kedua sisi ini (meninjau kode yang ditulis oleh orang lain, serta memiliki kode yang telah saya tulis ditinjau), saya akan mengatakan bahwa saya memiliki tiga kategori yang termasuk dalam setiap umpan balik. Nah, empat, ada juga kasus menyenangkan "semuanya baik-baik saja".

"Akan menyenangkan, tetapi itu tidak akan menghalangi Anda" (jika semua umpan balik termasuk dalam kategori ini, saya dapat mengirimkan permintaan penggabungan dengan "akan bergabung di XX: XX, kecuali jika Anda memberi tahu saya bahwa Anda ingin memperbaikinya" , atau "yakin, silakan cek, blok apa pun yang dilempar sistem telah dinonaktifkan"):

  • Lupa berhenti penuh di akhir kalimat (dalam string dokumen, atau komentar). Tata bahasa yang kikuk dalam hal apa pun yang tidak dipancarkan kepada pengguna dengan cara atau bentuk apa pun (sekali lagi, string dokumen dan komentar)
  • Kode yang memiliki cara yang lebih elegan, tetapi apa yang ada bisa dimengerti dan idiomatis (saya mungkin akan memasukkan saran saya, jadi mudah untuk pergi atau memperbaiki)

"Hal-hal yang perlu diperbaiki, tetapi saya akan memercayai Anda untuk melakukan itu" (jika semua hal termasuk dalam kategori ini atau sebelumnya, saya akan menjawab dengan "perbaiki ini, saya akan bergabung ketika Anda memberi tahu Anda ' sudah selesai "(dan pada saat itu saya mungkin akan dengan cepat memindai untuk melihat tidak ada lagi yang muncul)):

  • Minor quibbles ("Anda membandingkan boolean dengan true, itu agak paranoid ...", ...)
  • Pelanggaran gaya minor, ("panduan gaya mengatakan X, apa yang Anda lakukan di luar itu; saya akan melakukan Y atau Z, tergantung pada cara apa yang ingin Anda tuju")
  • Beberapa test case hilang, yang seharusnya tidak sulit untuk ditulis

Dan akhirnya, "hal-hal yang bermasalah, saya perlu meninjau kode Anda lagi setelah Anda memperbaiki masalah ini" (jika ada dalam kategori ini, perlu ada putaran review lain, jadi berikan komentar yang mengatakan " ada juga beberapa hal kecil, akan menyenangkan untuk melihat beberapa dari mereka diperbaiki saat Anda sedang melakukannya "jika ada sesuatu dari dua kategori pertama yang hadir):

  • Ini akan menjadi hal-hal seperti "tidak, benar-benar ada cara JAUH yang lebih baik untuk menulis bahwa", "Anda tidak menghitung apa yang Anda harapkan, karena uji unit Anda melewatkan kasus tepi ini" dan semua masalah berat lainnya.

0

Tampaknya beberapa orang telah melupakan pertanyaan paling penting: Apa yang ingin Anda capai dengan ulasan kode?

Tujuan dari tinjauan kode adalah untuk mendapatkan kode yang bebas bug dan dapat dipelihara lebih cepat. Ulasan kode mencapai ini dalam beberapa cara: Pengembang menulis kode yang lebih baik di tempat pertama karena mereka tahu itu akan ditinjau, pengetahuan dibagikan sebagai bagian dari proses peninjauan, bug akan ditemukan karena pengulas tidak buta terhadap kesalahan mereka sendiri sebagai pengembang dapat.

Jika Anda melihat proses peninjauan sebagai kesempatan untuk menjatuhkan rekan kerja Anda, atau untuk menciptakan pekerjaan untuk mereka, maka Anda melakukan kesalahan.

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.