Membawa Pola Pikir Tinjauan Kode yang Sehat ke Tim Anda

'Peninjauan kode' adalah momen dalam proses pengembangan di mana Anda (sebagai pengembang) dan rekan kerja Anda bekerja sama dan mencari bug dalam potongan kode terbaru sebelum dirilis. Pada saat seperti itu, Anda dapat menjadi pembuat kode atau salah satu pengulas.

Saat melakukan tinjauan kode, Anda mungkin tidak yakin dengan apa yang Anda cari. Di sisi lain, saat mengirimkan tinjauan kode, Anda mungkin tidak tahu harus menunggu apa. Kurangnya empati dan harapan yang salah antara kedua belah pihak dapat memicu situasi yang tidak menguntungkan dan mempercepat proses hingga berakhir dengan pengalaman yang tidak menyenangkan bagi kedua belah pihak.

Dalam artikel ini, saya akan membagikan bagaimana hasil ini dapat diubah dengan mengubah pola pikir Anda selama tinjauan kode:

• Sebagai sebuah tim
• Sebagai seorang penulis
• Sebagai pengulas

Bekerja Sebagai Tim

Menumbuhkan Budaya Kolaborasi

Sebelum kita mulai, penting untuk memahami nilai mengapa kode perlu ditinjau. Berbagi pengetahuan dan kohesi tim bermanfaat bagi semua orang, namun, jika dilakukan dengan pola pikir yang buruk, tinjauan kode dapat menjadi waktu yang sangat lama bagi konsumen dengan hasil yang tidak menyenangkan.

Sikap dan perilaku tim harus merangkul nilai kolaborasi yang tidak menghakimi, dengan tujuan bersama untuk belajar dan berbagi — terlepas dari pengalaman orang lain.

Sertakan Ulasan Kode Dalam Perkiraan Anda

Tinjauan kode lengkap membutuhkan waktu. Jika perubahan membutuhkan waktu satu minggu untuk dilakukan, jangan berharap peninjauan kode memakan waktu kurang dari satu hari. Itu tidak bekerja seperti itu. Jangan mencoba untuk terburu-buru meninjau kode atau melihatnya sebagai hambatan.

Review kode sama pentingnya dengan menulis kode yang sebenarnya. Sebagai sebuah tim, ingatlah untuk menyertakan tinjauan kode dalam alur kerja Anda dan tetapkan ekspektasi tentang berapa lama tinjauan kode dapat berlangsung, sehingga semua orang disinkronkan dan percaya diri dengan pekerjaan mereka.

Hemat Waktu Dengan Pedoman Dan Otomatisasi

Cara efektif untuk menjamin kontribusi yang konsisten adalah dengan mengintegrasikan template Pull Request dalam proyek. Hal ini akan membantu penulis untuk menyampaikan PR yang sehat dengan deskripsi yang lengkap. Deskripsi PR harus menjelaskan apa tujuan perubahan, alasan di baliknya, dan bagaimana mereproduksinya. Tangkapan layar dan tautan referensi (masalah Git, file desain, dan sebagainya) adalah sentuhan terakhir untuk pengiriman yang cukup jelas.

Melakukan semua ini akan mencegah komentar awal dari pengulas yang meminta detail lebih lanjut. Cara lain untuk membuat ulasan kode tampak kurang rumit adalah dengan menggunakan linter untuk menemukan pemformatan kode dan masalah kualitas kode sebelum peninjau terlibat. Setiap kali Anda melihat komentar berulang selama proses peninjauan, cari cara untuk meminimalkannya (dengan pedoman atau otomatisasi kode yang lebih baik).

Tetaplah Mahasiswa

Siapa pun dapat melakukan tinjauan kode, dan setiap orang harus menerima tinjauan kode — tidak peduli tingkat senioritasnya. Terima umpan balik apa pun dengan rasa terima kasih sebagai kesempatan untuk belajar dan berbagi pengetahuan. Lihatlah umpan balik apa pun sebagai diskusi terbuka daripada reaksi defensif. Seperti yang dikatakan Ryan Holiday:

“Seorang amatir itu defensif. Profesional menemukan pembelajaran (dan bahkan, kadang-kadang, ditampilkan) menyenangkan; mereka suka ditantang dan direndahkan, dan terlibat dalam pendidikan sebagai proses yang berkelanjutan dan tanpa akhir. (...)”

— Ryan Holiday, Ego Adalah Musuh

Tetaplah rendah hati karena begitu kamu berhenti menjadi mahasiswa, ilmumu menjadi rapuh.

Seni Memilih Peninjau

Menurut pendapat saya, memilih pengulas adalah salah satu keputusan terpenting untuk tinjauan kode yang efektif dan sehat sebagai sebuah tim.

Katakanlah kolega Anda mengirimkan tinjauan kode dan memutuskan untuk menandai "semua orang" karena, secara tidak sadar, dia mungkin ingin mempercepat proses, mengirimkan kode terbaik, atau memastikan semua orang tahu tentang perubahan kode. Setiap pengulas menerima pemberitahuan, lalu membuka tautan PR dan melihat banyak orang ditandai sebagai pengulas. Pikiran "orang lain akan melakukannya" muncul di benak mereka, yang mengarah untuk mengabaikan tinjauan kode dan menutup tautan.

Karena belum ada yang memulai tinjauan, rekan Anda akan mengingatkan setiap pengulas untuk melakukannya, yaitu dengan menciptakan tekanan pada mereka. Setelah peninjau mulai melakukannya, proses peninjauan berlangsung selamanya karena setiap orang memiliki pendapatnya sendiri dan mencapai kesepakatan bersama adalah mimpi buruk. Sementara itu, siapa pun yang memutuskan untuk tidak meninjau kode tersebut, kemudian di-spam dengan miliaran pemberitahuan email dengan semua komentar ulasan, sehingga menciptakan kebisingan dalam produktivitas mereka.

Ini adalah sesuatu yang saya lihat terjadi lebih dari yang saya inginkan: Tarik Permintaan dengan sekelompok orang yang ditandai sebagai pengulas dan berakhir, ironisnya, dalam tinjauan kode yang tidak produktif.

Ada beberapa alur efektif umum saat memilih peninjau: Alur yang mungkin adalah memilih dua hingga tiga kolega yang memahami kode dan meminta mereka menjadi peninjau. Pendekatan lain, yang dijelaskan oleh tim Gitlab adalah memiliki alur tinjauan berantai di mana penulis memilih satu pengulas yang memilih pengulas lain hingga setidaknya dua pengulas setuju dengan kode tersebut. Terlepas dari aliran yang Anda pilih, hindari memiliki terlalu banyak pengulas . Mampu memercayai penilaian kode rekan Anda adalah kunci untuk melakukan tinjauan kode yang efektif dan sehat.

Memiliki Empati

Menemukan potongan kode untuk ditingkatkan hanyalah bagian dari tinjauan kode yang sukses. Sama pentingnya adalah mengomunikasikan umpan balik itu dengan cara yang sehat dengan menunjukkan empati terhadap rekan kerja Anda.

Sebelum menulis komentar, ingatlah untuk menempatkan diri Anda pada posisi orang lain. Sangat mudah disalahpahami saat menulis, jadi tinjau kata-kata Anda sendiri sebelum mengirimnya. Bahkan jika percakapan mulai jelek, jangan biarkan itu memengaruhi Anda — selalu tetap hormat. Berbicara dengan baik kepada orang lain bukanlah keputusan yang buruk.

Tahu Cara Berkompromi

Saat diskusi tidak diselesaikan dengan cepat, bawa ke panggilan atau obrolan pribadi. Analisis bersama jika itu adalah subjek yang layak melumpuhkan permintaan perubahan saat ini atau jika itu dapat ditangani di yang lain.

Bersikaplah fleksibel tetapi pragmatis dan tahu bagaimana menyeimbangkan efisiensi (pengiriman) dan efektivitas (kualitas). Ini adalah kompromi yang harus dibuat sebagai sebuah tim. Pada saat-saat ini saya suka menganggap tinjauan kode sebagai iterasi daripada solusi akhir. Selalu ada ruang untuk perbaikan di babak berikutnya.

Ulasan Kode Langsung

Mengumpulkan penulis dan pengulas bersama-sama dalam gaya pemrograman berpasangan bisa sangat efektif. Secara pribadi, saya lebih suka pendekatan ini ketika tinjauan kode melibatkan perubahan kompleks atau ada peluang untuk berbagi pengetahuan dalam jumlah besar. Meskipun ini merupakan tinjauan kode offline, merupakan kebiasaan yang baik untuk meninggalkan komentar online tentang diskusi yang dilakukan, terutama ketika perubahan perlu dilakukan setelah rapat. Ini juga berguna untuk membuat pengulas online lainnya tetap up to date.

Belajar Dari Hasil Tinjauan Kode

Ketika tinjauan kode mengalami banyak perubahan, terlalu lama, atau sudah terlalu banyak diskusi, kumpulkan tim Anda dan analisis penyebabnya dan tindakan apa yang dapat diambil darinya. Ketika tinjauan kode rumit, membagi tugas di masa mendatang menjadi tugas-tugas yang lebih kecil membuat setiap tinjauan kode lebih mudah.

Ketika kesenjangan pengalaman besar, mengadopsi pemrograman berpasangan adalah strategi dengan hasil yang luar biasa — tidak hanya untuk berbagi pengetahuan tetapi juga untuk kolaborasi dan komunikasi offline. Apa pun hasilnya, selalu bidik tim dinamis yang sehat dengan harapan yang jelas.

Sebagai Penulis

Salah satu perhatian utama ketika mengerjakan review kode sebagai penulis adalah untuk meminimalkan kejutan reviewer saat membaca kode untuk pertama kalinya. Itulah langkah pertama menuju tinjauan kode yang dapat diprediksi dan lancar. Inilah cara Anda dapat melakukannya.

Bangun Komunikasi Dini

Tidak ada salahnya untuk berbicara dengan pengulas Anda di masa depan sebelum membuat kode terlalu banyak. Kapan pun itu adalah kontribusi internal atau eksternal, Anda dapat melakukan penyempurnaan bersama atau sedikit pemrograman berpasangan di awal pengembangan untuk mendiskusikan solusi.

Tidak ada salahnya meminta bantuan sebagai langkah awal. Padahal, bekerja sama di luar peninjauan merupakan langkah penting pertama untuk mencegah kesalahan awal dan menjamin kesepakatan awal. Pada saat yang sama, peninjau Anda mengetahui tinjauan kode di masa mendatang yang akan dibuat.

Ikuti Pedoman

Saat mengirimkan Permintaan Tarik untuk ditinjau, ingatlah untuk menambahkan deskripsi dan mengikuti panduannya. Ini akan menyelamatkan pengulas dari menghabiskan waktu untuk memahami konteks kode baru. Bahkan jika pengulas Anda sudah tahu tentang apa itu, Anda juga dapat mengambil kesempatan ini sebagai cara untuk meningkatkan keterampilan menulis dan komunikasi Anda.

Jadilah Pengulas Pertama Anda

Melihat kode Anda sendiri dalam konteks yang berbeda memungkinkan Anda menemukan hal-hal yang akan Anda lewatkan di editor kode Anda. Lakukan review kode terhadap kode Anda sendiri sebelum bertanya kepada rekan kerja Anda. Memiliki pola pikir pengulas dan benar-benar mempelajari setiap baris kode.

Secara pribadi, saya suka membubuhi keterangan pada ulasan kode saya sendiri untuk memandu pengulas saya dengan lebih baik. Tujuannya di sini adalah untuk mencegah komentar yang terkait dengan kemungkinan kurangnya perhatian dan memastikan Anda mengikuti pedoman kontribusi. Bertujuan untuk mengirimkan ulasan kode sama seperti Anda ingin menerimanya.

Sabar

Setelah mengirimkan ulasan kode, jangan langsung masuk ke pesan pribadi baru yang meminta pengulas Anda untuk "lihat, hanya perlu beberapa menit" dan secara tidak langsung menginginkan emoji jempol itu. Mencoba untuk terburu-buru rekan Anda untuk melakukan pekerjaan mereka bukanlah pola pikir yang sehat. Sebaliknya, percayai alur kerja kolega Anda karena mereka mempercayai Anda untuk mengirimkan tinjauan kode yang baik. Sementara itu, tunggu sampai mereka menghubungi Anda kembali saat mereka tersedia. Jangan melihat pengulas Anda sebagai hambatan. Ingatlah untuk bersabar karena hal-hal sulit membutuhkan waktu.

Jadilah Pendengar

Setelah tinjauan kode dikirimkan, komentar akan datang, pertanyaan akan diajukan, dan perubahan akan diusulkan. Aturan emas di sini adalah untuk tidak mengambil umpan balik sebagai serangan pribadi. Ingat bahwa kode apapun bisa mendapatkan keuntungan dari perspektif luar .

Jangan melihat pengulas Anda sebagai musuh. Sebaliknya, gunakan momen ini untuk mengesampingkan ego Anda, menerima bahwa Anda melakukan kesalahan, dan terbuka untuk belajar dari rekan kerja Anda, sehingga Anda dapat melakukan pekerjaan yang lebih baik di lain waktu.

Sebagai Peninjau

Rencanakan Lebih Awal Dari Waktu Anda

Saat Anda diminta menjadi pengulas, jangan langsung menyela. Itu kesalahan umum yang saya lihat sepanjang waktu. Meninjau kode menuntut perhatian penuh Anda, dan setiap kali Anda mengganti konteks kode, Anda mengurangi produktivitas Anda dengan membuang waktu untuk mengkalibrasi ulang fokus Anda. Sebaliknya, rencanakan ke depan dengan mengalokasikan slot waktu hari Anda untuk melakukan tinjauan kode.

Secara pribadi, saya lebih suka melakukan tinjauan kode di pagi hari atau setelah makan siang sebelum memilih tugas saya yang lain. Itulah yang paling cocok untuk saya karena otak saya masih segar tanpa konteks kode sebelumnya untuk dimatikan. Selain itu, setelah saya selesai meninjau, saya dapat fokus pada tugas saya sendiri, sementara penulis dapat mengevaluasi kembali kode berdasarkan umpan balik.

Jadilah Mendukung

Saat Pull Request tidak mengikuti panduan kontribusi, berikan dukungan — terutama kepada pendatang baru. Gunakan momen itu sebagai kesempatan untuk membimbing penulis untuk meningkatkan kontribusinya. Sementara itu, cobalah untuk memahami mengapa penulis tidak mengikuti pedoman sejak awal. Mungkin ada ruang untuk perbaikan yang tidak Anda sadari sebelumnya.

Periksa Cabang Dan Jalankan

Saat meninjau kode, jalankan di komputer Anda sendiri — terutama jika melibatkan antarmuka pengguna. Kebiasaan ini akan membantu Anda untuk lebih memahami kode baru dan menemukan hal-hal yang mungkin Anda lewatkan jika Anda hanya menggunakan alat diff default di browser yang membatasi cakupan tinjauan Anda ke kode yang diubah (tanpa memiliki konteks lengkap seperti di editor kode Anda) .

Tanyakan Sebelum Asumsi

Ketika Anda tidak memahami sesuatu, jangan takut untuk mengatakannya dan bertanya. Saat bertanya, ingatlah untuk terlebih dahulu membaca kode di sekitarnya dan hindari membuat asumsi.

Sebagian besar pertanyaan masuk ke dalam dua jenis kategori ini:

1. Pertanyaan “Bagaimana”
   Ketika Anda tidak mengerti bagaimana sesuatu bekerja atau apa fungsinya, evaluasi dengan penulis jika kodenya cukup jelas. Jangan salah mengira kode sederhana dengan ketidaktahuan. Ada perbedaan antara kode yang sulit dibaca dan kode yang tidak Anda ketahui. Bersikaplah terbuka untuk mempelajari dan menggunakan fitur bahasa baru, meskipun Anda belum mengetahuinya secara mendalam. Namun, gunakan hanya jika menyederhanakan basis kode.
2. Pertanyaan “Mengapa”
   Ketika Anda tidak mengerti "mengapa", jangan takut menyarankan untuk mengomentari kode, terutama jika itu adalah kasus tepi atau perbaikan bug. Kode harus cukup jelas ketika menjelaskan apa yang dilakukannya. Komentar adalah pelengkap untuk menjelaskan alasan di balik pendekatan tertentu. Menjelaskan konteks sangat berharga dalam hal pemeliharaan dan itu akan menyelamatkan seseorang dari menghapus blok kode yang dianggap tidak berguna. (Secara pribadi, saya suka mengomentari kode sampai saya merasa aman untuk melupakannya nanti.)

Kritik membangun

Setelah Anda menemukan sepotong kode yang Anda yakini harus ditingkatkan, selalu ingat untuk menghargai upaya penulis dalam berkontribusi pada proyek dan mengekspresikan diri Anda dengan cara yang terbuka dan reseptif.

• Diskusi terbuka.
  Hindari memformalkan umpan balik Anda sebagai perintah atau tuduhan seperti “Anda harus…” atau “Anda lupa…”. Ekspresikan umpan balik Anda sebagai diskusi terbuka alih-alih permintaan wajib. Ingatlah untuk mengomentari kode, bukan penulisnya. Jika komentarnya bukan tentang kode, maka komentar itu seharusnya tidak termasuk dalam tinjauan kode. Seperti yang dikatakan sebelumnya, jadilah pendukung. Menggunakan suara pasif, berbicara dalam bentuk jamak, mengungkapkan pertanyaan atau saran adalah pendekatan yang baik untuk menekankan empati dengan penulis.
  

Alih-alih "Ekstrak metode ini dari sini ..." lebih suka "Metode ini harus diekstraksi ..." atau "Apa pendapat Anda tentang mengekstraksi metode ini ..."

• Jelas.
  Umpan balik dapat dengan mudah disalahartikan, terutama dalam hal mengungkapkan pendapat versus berbagi fakta atau pedoman. Selalu ingat untuk menghapusnya segera di komentar Anda.

Tidak jelas: “Kode ini seharusnya….”

Opini: “Saya yakin kode ini seharusnya…”

Fakta: “Mengikuti [pedoman kami], kode ini seharusnya…”.

• Jelaskan mengapa.
  Apa yang jelas bagi Anda, mungkin tidak bagi orang lain. Tidak pernah terlalu banyak menjelaskan motivasi di balik umpan balik Anda, sehingga penulis tidak hanya mengerti bagaimana mengubah sesuatu tetapi juga apa manfaatnya.

Opini: “Saya yakin kode ini bisa…”

Dijelaskan: “Saya yakin kode ini bisa (…) karena ini akan meningkatkan keterbacaan dan menyederhanakan pengujian unit.”

• Berikan contoh.
  Saat membagikan fitur kode atau pola yang penulis tidak ketahui, lengkapi saran Anda dengan referensi sebagai panduan. Jika memungkinkan, lebih dari sekadar dokumen MDN dan bagikan cuplikan atau contoh kerja yang disesuaikan dengan skenario kode saat ini. Saat menulis contoh terlalu rumit, berikan dukungan dan tawarkan bantuan secara langsung atau melalui panggilan video.

Selain mengatakan sesuatu seperti “Menggunakan filter akan membantu kita untuk [motivasi],” juga mengatakan, “Dalam hal ini, bisa berupa: [cuplikan kode]. Anda dapat memeriksa [contoh di Finder.js]. Jika ada keraguan, silakan ping saya di Slack.”

• Bersikaplah masuk akal.
  Jika kesalahan yang sama dilakukan berkali-kali, lebih baik tinggalkan satu komentar saja dan ingat penulisnya juga mengulasnya di tempat lain. Menambahkan komentar yang berlebihan hanya akan menimbulkan gangguan dan mungkin kontraproduktif.

Tetap Fokus

Hindari mengusulkan perubahan kode yang tidak terkait dengan kode saat ini. Sebelum menyarankan perubahan, tanyakan pada diri Anda apakah itu benar-benar diperlukan pada saat itu. Jenis umpan balik ini sangat umum di refactors. Ini adalah salah satu dari banyak trade-off antara efisiensi dan efektivitas yang perlu kita buat sebagai sebuah tim.

Ketika datang ke refactors, secara pribadi, saya cenderung lebih memilih perbaikan kecil tapi efektif . Itu lebih mudah untuk ditinjau dan ada sedikit kemungkinan konflik kode saat memperbarui cabang dengan cabang target.

Tetapkan Harapan

Jika Anda membiarkan ulasan kode setengah jadi, beri tahu penulisnya, sehingga ekspektasi waktu terkendali. Pada akhirnya, beri tahu penulis jika Anda setuju dengan kode baru atau jika Anda ingin meninjau ulang sekali lagi nanti.

Sebelum menyetujui tinjauan kode, tanyakan pada diri Anda apakah Anda merasa nyaman dengan kemungkinan menyentuh kode itu di masa mendatang. Jika ya, itu tandanya Anda berhasil melakukan review kode!

Belajar Menolak Ulasan Kode

Meskipun tidak ada yang mengakuinya, terkadang Anda harus menolak review kode. Saat Anda memutuskan untuk menerima tinjauan kode tetapi mencoba untuk terburu-buru, kualitas proyek sedang dikompromikan serta pola pikir tim Anda.

Saat Anda menerima untuk meninjau kode orang lain, orang itu memercayai kemampuan Anda — itu adalah komitmen. Jika Anda tidak punya waktu untuk menjadi reviewer, katakan saja tidak kepada rekan Anda. Saya benar-benar serius; jangan sampai rekan anda menunggu review kode yang tidak akan pernah selesai. Ingatlah untuk berkomunikasi dan menjaga harapan tetap jelas . Jujurlah dengan tim Anda dan — bahkan lebih baik — dengan diri Anda sendiri. Apapun pilihan Anda, lakukan dengan sehat, dan lakukan dengan benar.

Kesimpulan

Dengan waktu dan pengalaman yang cukup, melakukan tinjauan kode akan mengajarkan Anda lebih dari sekadar pengetahuan teknis. Anda akan belajar memberi dan menerima umpan balik dari orang lain, serta membuat keputusan dengan lebih banyak pemikiran.

Setiap tinjauan kode adalah kesempatan untuk tumbuh sebagai komunitas dan individu. Bahkan di luar ulasan kode, ingatlah untuk menumbuhkan pola pikir yang sehat sampai hari itu datang secara alami kepada Anda dan kolega Anda. Karena berbagi adalah hal yang membuat kita lebih baik!

Bacaan Lebih Lanjut tentang SmashingMag:

• Bekerja Bersama: Bagaimana Desainer dan Pengembang Dapat Berkomunikasi Untuk Membuat Proyek yang Lebih Baik
• Kolaborasi Lebih Baik Dengan Membawa Desainer Ke Dalam Proses Peninjauan Kode
• Podcast Manakah yang Harus Didengar oleh Desainer dan Pengembang Web?
• Cara Membuat Resume Pengembang Web yang Sempurna