Ulasan kode sering menimbulkan kontroversi. Dalam mempersiapkan ceramah, “Kita Mengosongkan Perilaku Beracun dalam Tinjauan Kode” di konferensi AlterConf, saya siap mendengar banyak keberatan dan kritik. Tetapi dia tidak berharap masyarakat untuk mendukung gagasan itu. Saya menerima perlawanan, tetapi komunitas menerima dan menyetujui saya dengan sangat baik.

Saya diminta untuk membagikan slide , tetapi sekarang saya berpikir bahwa slide itu sendiri tidak banyak berguna dan dikeluarkan dari konteks: mereka tidak memiliki penjelasan. Karena itu, saya memutuskan untuk menerbitkan artikel ini. Kemudian, panitia konferensi mengunggah video .

Di bawah ini tercantum beberapa jenis perilaku ulasan kode tidak produktif dan rekomendasi tentang cara membuat proses lebih ramah dan menghilangkan toksisitas. Semua model perilaku telah diuji oleh saya atau di perusahaan yang saya kenal. Di masa lalu, dosa-dosa seperti itu juga dibawa kepada saya.

Perilaku Tidak Produktif No. 1: Menyampaikan Opini sebagai Fakta

Jangan membuat pernyataan jika Anda tidak dapat merujuk pada dokumentasi, rekomendasi yang diformalkan, dan contoh kode untuk mendukung pernyataan ini. Orang-orang harus tahu mengapa mereka diminta untuk melakukan perubahan, dan preferensi pribadi pengembang lain tidak cukup argumen.

Alih-alih mengatakan:

Komponen ini harus dibuat tanpa kewarganegaraan.

... lebih baik menyediakan beberapa konteks:

Karena komponen ini tidak memiliki siklus hidup atau metode negara, dapat dibuat stateless. Ini akan meningkatkan kinerja kode dan keterbacaan. * Di sini * beberapa dokumentasi.

Transfer pendapat sebagai fakta sering ditemukan dalam diskusi gaya dan sintaksis. Ini adalah topik yang sangat penting, tetapi tidak untuk ulasan kode, karena gaya dan sintaksis tidak ada hubungannya dengan masalah yang awalnya diselesaikan pengembang.

Lebih baik melakukan diskusi semacam itu secara terpisah dan menentukan gaya untuk seluruh tim. Terapkan linter dan perbaikan kode otomatis . Anda kemudian akan merujuk pada rekomendasi gaya ini, bukan pendapat pribadi Anda.

Sangat penting untuk tidak memberikan pendapat Anda sebagai fakta jika Anda memiliki pangkat dan otoritas yang lebih tinggi dalam tim atau perusahaan. Pengembang memiliki kesan bahwa ia tidak punya pilihan selain mematuhi persyaratan Anda dengan patuh.

Perilaku Tidak Produktif # 2: Longsoran Komentar

Ketika seseorang membuat kesalahan, ada kemungkinan besar kesalahan ini terjadi di beberapa tempat. Saya memperhatikan bahwa pengulas terkadang menunjukkan masing-masing kasus alih-alih meninggalkan satu catatan terperinci dengan tautan ke sumber daya yang bermanfaat.

Penggabungan komentar memungkinkan Anda untuk mengirim pesan yang sama tanpa menekan penulis. Longsor komentar duplikat pada satu masalah tampak seperti nitpicking.

Tidak produktif dan luar biasa:



Banyak komentar untuk satu kesalahan berulang (spasi di akhir baris)

Opsi yang lebih bermanfaat:


Umpan Balik Konsolidasi

Saya dapat memahami bahwa kadang-kadang berguna untuk menunjuk ke setiap tempat kesalahan, karena komentar itu hilang ketika dikoreksi dalam komitmen selanjutnya. Tetapi jika kesalahan terjadi berkali-kali, jelas bahwa pengembang tidak mengetahui panduan tertentu, dan ia harus menunjukkan sumber daya yang tepat.

Perilaku tidak produktif nomor 3: minta insinyur untuk memecahkan masalah orang lain, "selagi mereka di sini"

Jangan meminta pengembang untuk menangani masalah yang tidak terkait langsung dengan set perubahan atau masalah yang coba dipecahkan oleh kode ini. Bahkan jika pengembang memperluas atau memodifikasi kode kotor dengan banyak praktik buruk, jangan memintanya untuk membersihkan dan memperbaiki kode aneh ini.

Saya tidak mengusulkan untuk menghilangkan tanggung jawab pengembang untuk kode hanya karena mereka awalnya tidak menulisnya. Sebenarnya, tidak baik mengatakan sesuatu seperti "Kode orang lain bukan masalah saya." Lebih tepat untuk membuat tiket terpisah dan menarik permintaan untuk memperbaiki kode kotor. Dengan demikian, Anda menghindari peningkatan tajam dalam volume pekerjaan seseorang, menyelesaikan masalah dengan utang teknis.

TL; DR : Jangan meminta pengembang untuk memperbaiki masalah "saat mereka ada di sini." Jika kode melakukan apa yang diperlukan dalam tiket dan tidak memasukkan masalah baru ke dalam basis kode, setujui, lalu buat tiket untuk menghapus basis kode.

Perilaku Tidak Produktif # 4: Ajukan Pertanyaan yang Mengutuk

Hindari mengajukan pertanyaan yang mengutuk seperti ini:

Mengapa kamu tidak melakukan ____ di sini saja?

Ini menyiratkan bahwa beberapa solusi sederhana harus jelas. Ini memaksa pengembang untuk mempertahankan diri.

Seringkali pertanyaan yang mengutuk ini hanya tuntutan terselubung. Sebagai gantinya, tawarkan rekomendasi (dengan dokumentasi dan tautan), hilangkan kata-kata kasar.

Anda dapat melakukan ____, yang memiliki keunggulan ____.

Perilaku Tidak Produktif No. 5: Sarkasme

Tidak ada tempat untuk sarkasme di ulasan. Sebagai aturan, komentar sarkastik tidak memberikan konteks dan umpan balik yang efektif. Alih-alih, jelaskan masalahnya secara mendetail dan berikan rekomendasi, tetapi kesampingkan lelucon pedas.

Tidak produktif:

Pernahkah Anda menguji kode ini sebelum mengirimkan?

Berguna

Gagal memasukkan nomor negatif. Bisakah Anda melakukan ini?

Berikut adalah contoh lain komentar dalam ulasan kode yang tidak lucu atau berguna:

Kami tidak jahat, kami tanpa ampun. Seperti yang Anda lihat, saya menulis "bip!" - Saat mengimpor setiap file yang Anda sentuh. Saya telah memikirkan yang berikut: "Impor Anda melanggar konvensi standar kami, yang mengandaikan urutan tertentu: pertama, modul bawaan, kemudian pihak ketiga, dan kemudian tingkat proyek," tetapi frasa ini terlalu panjang untuk diketik dalam setiap kasus.

Dalam contoh di atas, "bip!" - Sepenuhnya tidak berguna dan tidak bermakna. Ini adalah humor pedantic yang tidak membantu penulis.

Perilaku Tidak Produktif # 6: Emoji alih-alih menggambarkan masalahnya

Saat menunjukkan masalah dalam kode, hindari emotikon dengan ibu jari ke bawah atau emoji dengan pria kecil yang memuakkan. Tidak ada gunanya seperti sarkasme, untuk alasan yang sama. Emoji itu misterius, mudah disalahartikan. Orang-orang membuang-buang waktu untuk mencoba memahami pikiran Anda.


Jangan gunakan emoji untuk menunjukkan masalah pengkodean

Bagaimanapun, Anda seharusnya tidak memiliki reaksi emosional terhadap kesalahan pemrograman.

Sangat normal untuk menggunakan emotikon positif, seperti "jempol" atau "ceria!", Tetapi bukan untuk menunjukkan masalah, tetapi sebagai respons terhadap kode yang baik.


Menyetujui emotikon sangat bagus

Perilaku Tidak Produktif # 7: Jangan Menanggapi Semua Komentar

Para penulis juga berkontribusi terhadap toksisitas diskusi. Jika Anda menggabungkan kode tanpa menjawab semua komentar, maka ini mengejutkan bagi orang tersebut: ia mencoba membantu Anda, dan Anda menjelaskan bahwa beberapa ulasan tidak masalah.

Jika komentar itu tidak relevan atau Anda tidak akan mengambil tindakan, cukup jelaskan alasannya.

Jangan abaikan kolega.


Menggabungkan kode tanpa menanggapi komentar

Perilaku Tidak Produktif # 8: Mengabaikan Perilaku Beracun Jika Berasal Dari Para Profesional Tertinggi

Perilaku beracun tidak boleh diabaikan atau diremehkan hanya karena pengembang adalah profesional yang sangat baik dan karyawan yang sangat produktif. Meskipun ia melakukan pekerjaan yang fantastis, penting untuk diingat bahwa perilakunya yang beracun menyebabkan stres dan kehabisan tenaga bagi pengembang lain.

Pengalaman dengan seseorang yang menunjukkan perilaku beracun:

Orang lain akan mendapati bahwa bekerja dengan orang ini menghabiskan dan menurunkan motivasi. Mereka akan melakukan apa saja untuk menghindari berinteraksi dengannya, bahkan jika itu memengaruhi kemampuan mereka untuk melakukan tugas secara negatif. Komunikasi di seluruh organisasi akan terganggu, dan karyawan akan mulai mencari pekerjaan di tempat lain. Meskipun Anda menghadapi konsekuensi dari kebocoran bakat dan proyek yang gagal, pengembang khusus ini akan terus bekerja dengan tenang seolah-olah tidak ada yang terjadi. - Joseph Gefro

Jika langkah-langkah tidak diambil untuk memperbaiki situasi, konsekuensi serius mungkin terjadi: pengembang akan kelebihan beban, diserang dan didemotivasi. Mereka akan mulai takut akan umpan balik, yang sebenarnya seharusnya membantu mereka tumbuh.

Saya pribadi merasa sangat khawatir setiap kali saya menerima email berisi komentar tentang permintaan tarik saya dari seorang mantan kolega (dikenal karena ulasannya yang beracun dan tidak membantu). Meskipun perilaku toksik memengaruhi setiap orang secara berbeda, tetapi jelas tidak ada yang mendapat manfaat dari toksisitas ini.

Catatan : Saya ingin menjelaskan bahwa jika pengembang tidak bisa menolak dan sekali menunjukkan perilaku seperti itu, ini tidak membuatnya "beracun". Kita berbicara tentang penghinaan berulang dan komentar pedas.

Praktek Peninjauan Kode yang Berguna

Berikut adalah beberapa rekomendasi yang berlaku untuk komunikasi normal apa pun, meskipun di sini kita berbicara dalam konteks pemrograman dan ulasan kode.

Perilaku Berguna # 1: Gunakan pertanyaan atau rekomendasi untuk membangun dialog

Jangan pernah meminta orang untuk melakukan koreksi atau mengajukan pertanyaan yang tidak disetujui, karena ini mengganggu dialog antara Anda dan orang lain.

Mengapa Anda tidak menggabungkan konversi ini dalam file dengan konstanta?

Secara formal, ini adalah pertanyaan, tetapi itu tidak menciptakan dialog antara Anda dan lawan bicara. Dia hanya membuatnya membela diri. Alih-alih, tanyakan pendapat orang lain tentang keputusan Anda, misalnya:

Apa pendapat Anda tentang menarik konversi ini ke file konstan? Ada cukup banyak dari mereka, jadi file terpisah mungkin masuk akal saat ini.

... atau buat rekomendasi:

Dalam file ini Anda memiliki banyak panggilan terjemahan untuk "fungsi x". Mungkin masuk akal untuk membuat file terpisah dengan konstanta.

Perilaku Berguna # 2: Berkolaborasi, Jangan Sembunyikan

Ketika Anda memprogram bersama, Anda harus ada di sekitar, mengajukan pertanyaan, berdiskusi, dan menunjukkan sumber daya.

"... Ketika Anda ingin membantu atau bekerja bersama, Anda harus sepenuhnya terlibat, tidak hanya campur tangan kadang-kadang" - Recurse Center Guide

Perilaku Berguna # 3: Tanggapi Setiap Komentar

Jika Anda sebagai penulis tidak berencana untuk menerapkan saran dari pengulas, buat saja catatan dengan melaporkannya. Jangan abaikan mereka yang meluangkan waktu untuk membantu Anda.

Sebagai contoh:

Orang A: - Apa pendapat Anda tentang membuat fungsi pembantu untuk panggilan API ini? Kalau tidak, semuanya baik-baik saja.

Orang B: - Baris ini bukan bagian dari changeset saya. Saya akan menggabungkan kode, membuat tiket terpisah di GitHub dan menuliskannya dalam rencana kerja untuk grup kami.

Perilaku Berguna # 4: Mengetahui kapan harus mengatur pertemuan tatap muka

Setelah puluhan komentar dan solusi yang diajukan, harus jelas bahwa komunikasi online menjadi tidak produktif untuk masalah yang dihadapi. Kirim undangan rapat ke semua kolega Anda yang terlibat.

Dengan demikian, kelompok akan dapat dengan cepat membuat keputusan dan menerapkannya.

Masalah yang membutuhkan berjam-jam dan banyak komentar biasanya dapat diselesaikan dalam beberapa menit percakapan yang produktif. - "Java Rapi"

Perilaku Berguna # 5: Gunakan Peluang Belajar dan Jangan Pamer

Sebelum berpartisipasi dalam tinjauan kode, tanyakan pada diri sendiri:

Apakah komentar Anda benar-benar membantu Anda belajar atau Anda menemukan kesalahan?

Pikirkan tentang komentar Anda. Ingatlah bahwa tujuan tinjauan kode adalah untuk mengajar dan membantu pengembang lain tumbuh. Ini bukan platform untuk pertunjukan.

Perilaku Berguna # 6: Jangan Menunjukkan Kejutan

Berhati-hatilah untuk tidak menunjukkan kejutan jika seseorang tidak mengetahui sesuatu. Jangan membuat orang kesal karena mereka seharusnya sudah mengetahui informasi ini. Sebaliknya, jangan ragu untuk mengakui bahwa Anda tidak memiliki pengalaman dalam topik - ini adalah cara yang bagus untuk meminta bantuan.

Lihat aturan “Jangan Berpura-pura Terkejut” di tutorial Recurse Center untuk informasi lebih lanjut.

Perilaku Berguna # 7: Mengotomatiskan Semua yang Anda Bisa

Tidak masuk akal untuk membahas bug yang dapat ditangkap oleh linter, Git hooks, atau tes otomatis. Ini adalah satu ton komentar tambahan yang mirip nitpicking. Orang tidak pandai mengidentifikasi kesalahan seperti itu, dan karena itu alat otomasi telah dibuat.

Ada juga alat untuk secara otomatis menjalankan tes saat menambahkan kode baru. Mereka menampilkan peringatan jika serangkaian perubahan melanggar salah satu tes. Misalnya, TeamCity dan Jenkins CI.

Juga, gunakan kait Git untuk menjalankan tes dan linter pada kode baru. Mereka akan mencegat komit jika mereka menemukan bug.

Biarkan alat menunjukkan masalah, sehingga orang tidak perlu melakukannya.

Perilaku Berguna # 8: Jangan Mengalahkan Perilaku Beracun

Tidak perlu mengadopsi perilaku beracun dalam ulasan kode Anda, karena itu terlihat seperti balas dendam atau ritual perpeloncoan bagi pengembang baru.

Temukan kolega yang akan mendukung Anda.

Jika Anda melihat ulasan kode yang tidak produktif, cobalah untuk memberi tahu kolega, berbicara langsung dan jujur ​​(jika Anda merasa aman dengan posisi / perusahaan Anda).

Perilaku Berguna No. 9: Manajer, pertimbangkan kandidat dengan cermat, dengarkan tim, dan gunakan wewenang Anda

Manajer memiliki peluang besar untuk menciptakan suasana positif dan menyenangkan dalam tim.

Kami ulangi kiat dari artikel "Berbahaya pengembang beracun" :

• Cegah pengembang beracun agar tidak muncul di tim. Saat merekrut, perhatikan tidak hanya pelatihan teknis. Cari tahu bagaimana kandidat berkolaborasi dan berkomunikasi. Secara kritis menganalisis karyanya dan melihat bagaimana dia bereaksi. Pastikan bahwa setiap kandidat meningkatkan budaya perusahaan, dan tidak hanya sesuai dengan itu.
  
• Ketika pengembang beracun masih masuk ke negara bagian atau mewarisi, minta pendapat setiap karyawan tentang hal itu dalam percakapan pribadi. Jika pengembang beracun, itu akan muncul dalam ulasan tentang dia.
  
• Bicaralah dengan pengembang beracun. Berikan contoh spesifik komentar efektif dalam ulasan kode. Terus bekerja dengannya, terus mengumpulkan informasi dalam percakapan pribadi dengan kolega dan manajernya.
  
• Jangan mengisolasi pengembang beracun. (*)
  
• Ulangi kepada karyawan tentang perlunya lingkungan yang ramah.

(*) Meskipun artikel ini mengusulkan untuk mengisolasi pengembang beracun, saya menganggap penting untuk mendorong pengembang beracun untuk bekerja dengan tim, tetapi dengan cara yang lebih sehat. Isolasi tidak akan menyelesaikan masalah. Jika Anda memberikannya pekerjaan yang terpisah, toksisitas akan berkurang dalam jangka pendek, tetapi pengembang tidak akan melepaskan perilaku tidak produktifnya. Dia hanya akan kehilangan podium untuk menunjukkannya.

Perilaku Berguna # 10: Tetapkan standar saat tim kecil dan berkembang

Tim kecil dapat menerima ide-ide baru dan mengimplementasikannya. Sekalipun Anda tidak menganggap perlu untuk menetapkan standar, karena sekarang tidak ada masalah, tetapi penting untuk mempertahankan praktik kerja sama yang baik ketika pengisian ulang tiba.

Perilaku Berguna # 11: Pahami bahwa Anda dapat menjadi bagian dari masalah

Untuk menciptakan lingkungan yang lebih menguntungkan, penting untuk jujur ​​dengan diri sendiri dan merefleksikan perilaku yang tidak efektif.

Sebagai seorang junior, saya melihat kesalahan dalam kode seseorang beberapa kali dan senang, karena saya bisa memberikan komentar! Sekarang saya mengerti bahwa saya menggunakan kesempatan ini untuk menyombongkan diri, dan tidak membantu. Anda perlu mengevaluasi tindakan Anda dengan hati-hati.

Saya pikir berguna bagi semua orang untuk meluangkan waktu untuk introspeksi yang sulit ini.

Dan yang terakhir ...

Kami tidak berbicara tentang konten ulasan, tetapi hanya tentang nada

Saya tahu bahwa ulasan itu penting, dan kami tidak berjuang melawannya. Saya tidak meminta Anda untuk mengkompromikan kualitas kode. Budaya ulasan kode yang baik dan kualitas kode yang tinggi tidak boleh saling eksklusif.

Saya hanya berharap bahwa orang akan mengambil langkah-langkah untuk memberikan umpan balik yang konstruktif, efektif, dan menciptakan kondisi yang lebih menguntungkan di mana pengembang akan merasa nyaman, belajar, tumbuh dan tidak takut untuk membuat kesalahan. Kita semua bisa meningkat bersama.