BerandaComputers and TechnologyMeningkatkan budaya tinjauan kode tim Anda

Meningkatkan budaya tinjauan kode tim Anda

Membuat sistem yang memberdayakan tim Anda.

Image for post

Image for post

Peninjauan kode adalah salah satu tugas paling produktif yang kami lakukan setiap hari. Jika dilakukan dengan baik, mereka memastikan kualitas kode, mempromosikan berbagi pengetahuan, dan memperkuat tim. Peninjauan kode memberikan keyakinan kepada pengembang bahwa kode yang mereka kontribusikan sebaik mungkin dan memungkinkan semua orang dalam tim untuk berbicara tentang arah basis kode dan standar tempat kode tersebut dipegang oleh tim. Mereka membiarkan tim campur tangan sebelum hutang teknis menjadi masalah dan memberikan kesempatan untuk umpan balik positif dan merayakan peningkatan.

Namun, kami o f sepuluh berakhir dengan satu set proses dan budaya yang tidak bekerja dengan baik. Mungkin ada masalah yang tampaknya tidak berbahaya saat peninjauan berada di bagian bawah daftar prioritas semua orang dan membutuhkan waktu beberapa hari untuk menyelesaikannya. Di mana ulasan terjerat dengan aturan dan ekspektasi di seluruh perusahaan. Di mana tidak ada yang menghargai nilai yang diberikan ulasan kode kepada tim. Kami mungkin memiliki ulasan di mana orang-orang membuang-buang waktu untuk mencari hal-hal yang salah dan tidak memanfaatkan otomatisasi. Dalam beberapa kasus, kita bisa berakhir dengan masalah yang lebih merepotkan, di mana tekanannya terlalu tinggi dan risiko kehilangan sesuatu yang terlalu berbahaya. Di mana ulasan menjadi rumah bagi perilaku berbahaya dan beracun, yang mana pengulas dan pihak yang ditinjau bisa dianggap bersalah.

Jika ada yang tidak beres dengan proses peninjauan Anda, hasil akhirnya adalah keterlambatan seberapa cepat sesuatu melewati langkah peninjauan. Terlepas dari dampak apa yang menyebabkan penundaan, beberapa hari tambahan untuk tinjauan macet memiliki dampak luas pada bagaimana pekerjaan bergerak melalui tim Anda.

Karena ulasan menjadi lebih lambat dan mode memberatkan, mereka beralih dari seseorang yang melihat-lihat pekerjaan Anda dan menjadi gerbang. Gates menjadi tahap formal dan membawa serta handoffs, bernegosiasi siapa yang akan mengambil pekerjaan selanjutnya, dan menunggu sampai mereka tersedia. Setiap gerbang tambahan dalam proses kami menciptakan siklus umpan balik yang lebih lama, mempersulit koordinasi dalam tim kami, dan membawa kami kembali ke metodologi air terjun.

Image for post

Image for post

Satu tugas tertunda dapat memiliki banyak dampak aliran sehingga lebih sulit bagi tim untuk mengoordinasikan tugas lainnya yang diperlukan untuk menyampaikan fitur tersebut.

Ketika pekerjaan macet dalam peninjauan kode, hal itu menyebabkan penundaan untuk semua pekerjaan yang bergantung pada kode yang ditinjau. Ini meningkatkan ketidakpastian karena kami tidak tahu kapan pekerjaan itu akan selesai atau seberapa banyak yang masih bisa berubah. Mencoba membuat cabang dari cabang yang macet sering kali menyebabkan mimpi buruk penggabungan untuk menyatukan semuanya kembali.

Image for post

Image for post

Durasi cabang mencakup semua tugas dan gerbang yang harus diselesaikan sebelum dapat digabungkan kembali.

Kedua, tinjauan kode yang berjalan lama berarti cabang yang sudah berjalan lama dan semua kesulitan yang ditimbulkannya. Pengembang yang berbeda akhirnya bekerja melawan model mental yang berbeda dari basis kode. Menggabungkan kembali menjadi master semakin sulit dan berisiko. Refactoring menjadi tidak disarankan karena menjadi tidak mungkin untuk menggabungkan kembali perubahan yang signifikan.

Respons alami kami terhadap penundaan yang disebabkan oleh tinjauan kode yang lambat hanya akan memperburuk masalah. Untuk menyederhanakan kekacauan dependensi yang rumit, kami mengelompokkan tugas dan fitur ke dalam blok yang semakin besar dan menghindari masalah koordinasi dengan mendedikasikan seluruh fitur untuk pengembang tunggal. Kumpulan perubahan besar dan silo dalam tim membuat tinjauan lebih sulit karena orang lain tidak memiliki konteks untuk meninjau perubahan dengan nyaman. Kami menyerah pada kemampuan kami untuk mengelompokkan tugas atau bekerja sama dalam tim.

Image for post

Image for post

Kesulitan dalam mengoordinasikan pekerjaan mencegah pengembang mengelompokkan tugas, dan setiap tim perlu mengatur lebih banyak fitur dalam jangka waktu yang lebih lama.

Pendekatan ini mempersulit semua non-pengembang yang terlibat dalam pengembangan fitur. Dengan setiap pengembang mengerjakan streaming yang berbeda, pemilik produk perlu menangani lebih banyak tugas sekaligus, menjaga beberapa fitur terpisah berjalan sekaligus. Sementara itu, penguji tim kehilangan kemampuan untuk mengantisipasi kapan pekerjaan akan siap untuk diuji dan sering kali semua fitur pengembang dibuang sekaligus sebelum setiap rilis.

Akhirnya, peninjauan kode yang tertunda berdampak signifikan pada motivasi dan moral pengembang. Mereka membuat sulit untuk mempertahankan rasa kepemilikan atau momentum. Peninjauan kode menjadi alasan untuk pekerjaan yang tertunda, dengan “itu macet dalam peninjauan kode,” menjadi jawaban atas pertanyaan apa pun tentang status tugas.

Banyak strategi untuk meningkatkan tinjauan kode membuatnya lebih buruk

Sayangnya, bahkan setelah kami mengidentifikasi bahwa peninjauan kode merupakan masalah bagi tim kami, pendekatan yang cenderung kami ambil hanya memperburuk situasi. Naluri kami adalah menyelesaikan setiap masalah dengan menerapkan lebih banyak teknologi dan proses, tetapi akar penyebabnya lebih berkaitan dengan orang dan budaya.

  • Meningkatkan ukuran kumpulan pengulas Image for post – Biasanya dicapai dengan memperkenalkan atau mendorong ulasan lintas tim. Peninjau dari tim lain tidak memiliki konteks dan latar belakang untuk setiap perubahan kode dan tidak memiliki kesadaran atau kepemilikan untuk termotivasi untuk memprioritaskan peninjauan. Semakin banyak pengulas juga meningkatkan jumlah orang lain yang dapat mengambil ulasan, membuatnya lebih mudah untuk menggadaikan ulasan sebagai masalah orang lain.
  • Lebih mendorong – Seringkali, dorongan untuk meningkatkan komunikasi berubah menjadi pengingat di dasbor atau selama standup pagi. Namun, peningkatan dorongan hanya membantu ketika pengembang melupakan tinjauan kode; jika tidak, itu berubah menjadi motivasi yang mengganggu dan menurun.
    • Cabang integrasi – Daripada memiliki banyak ulasan kecil, setiap orang berkomitmen pada satu cabang besar, dan Anda memiliki ulasan Anda di akhir. Meskipun tim dapat terus bergerak dan berkembang tanpa hambatan, pendekatan ini menunda masukan penting hingga akhir fitur. Hal ini membuat pengulas memiliki ulasan besar yang tidak terkelola, di mana seringkali terlambat untuk mengatasi perubahan.
    • Intervensi dari kepemimpinan – Pemimpin tim mungkin akan masuk mode perintah dan kontrol, mengetuk peninjau di bahu dan meminta mereka untuk melihat ulasan yang menahan anggota tim lainnya. Peninjauan kode yang tertunda tidak disebabkan oleh pengembang yang malas, jadi memunculkan rasa bersalah dan tekanan itu kontraproduktif. Kami perlu mengatasi masalah sebenarnya yang dihadapi pengulas.

    Image for post

    Image for post

    Jika diberi pilihan, apakah tim Anda akan terus melakukan peninjauan kode? Jika satu-satunya alasan pengembang terlibat dalam proses tinjauan adalah rasa kewajiban, kami memiliki kesenjangan dalam nilai yang dirasakan yang diperoleh dari tinjauan versus kesulitan untuk melakukannya. Ketika keseimbangan ini mati, motivasi, dan dengan demikian waktu penyelesaian tinjauan kode, terpengaruh.

    Kami selalu bisa mendapatkan keuntungan dari membuat ulasan kode kami lebih positif. Idealnya, semua pihak harus menantikan tinjauan kode, dan ada banyak cara untuk mencapai ini. Alih-alih berfokus pada menemukan kesalahan, tekankan belajar, mengajar, dan berbagi pengetahuan. Komentari perubahan positif, ketika seseorang akhirnya berhasil melunasi hutang teknis yang buruk itu, memecahkan masalah yang sulit dengan cara yang sangat elegan atau membawa ide baru yang luar biasa ke dalam basis kode. Daripada melihat ulasan kode sebagai transaksi, kita harus melihatnya sebagai peluang untuk kolaborasi.

    Berhenti mengharapkan ulasan kode yang sempurna

    Hambatan umum yang mencegah pengembang untuk melihat ulasan kode adalah keyakinan bahwa setiap ulasan harus mengidentifikasi setiap masalah , kesalahan, dan kesalahan yang terkandung dalam set perubahan itu. Jika kami tidak memiliki pemahaman atau keyakinan umum dengan bagian aplikasi tersebut atau bahasa atau kerangka kerja yang digunakan, akan mudah untuk membenarkan meninggalkan ulasan untuk seseorang yang lebih berpengalaman. Sayangnya, alur pemikiran ini menghasilkan kumpulan peninjau kode yang jauh lebih kecil yang akhirnya harus melakukan sebagian besar tinjauan, mengurangi waktu yang tersedia, dan menciptakan kemacetan.

    Kita tidak boleh mengabaikan ulasan dari orang selain pengembang paling berpengalaman dalam proyek tersebut. Upaya dua pengembang yang melihat ulasan dapat mengidentifikasi lebih banyak masalah daripada yang bisa dilakukan pengulas tunggal. Lebih lanjut, pertanyaan pemula seringkali sangat bagus dalam mengambil asumsi yang mungkin diterima begitu saja oleh beberapa pengembang berpengalaman. Kasus terburuk, pengkaji mempelajari alasan di balik keputusan tersebut, kasus terbaik, mereka telah membantu mengungkap titik buta. Membuat semua orang berpartisipasi dalam ulasan memungkinkan mereka meningkatkan kemampuan peninjauan kode dan pemahaman tentang aplikasi.

    Ekspektasi yang sempurna terkadang bukan dari pengembang itu sendiri tetapi dipaksakan oleh kebijakan perusahaan. Peninjau harus menjadi “penjaga kualitas” dan diharapkan dapat mencegah semua bug dan utang teknis memasuki produk. Di perusahaan dengan budaya menyalahkan yang berat, pengulas mungkin bertanggung jawab atas apa pun yang mereka biarkan lolos. Pekerjaan pertama saya sebagai pengembang sejauh memiliki “lisensi” pengulas yang akan dicabut jika pengulas melewatkan sesuatu yang penting. Kami akan menunggu berhari-hari untuk menemukan seseorang yang bersedia mengulas apa pun. Membutuhkan tinjauan yang sempurna menambah begitu banyak tekanan tambahan pada sistem tinjauan kode dan merusak begitu banyak kepercayaan di antara kolega sehingga membuat tinjauan hampir mustahil.

    Setiap orang harus mundur dan mengevaluasi apa sebenarnya risiko dalam tinjauan kode yang tidak sempurna. Sisa dari proses kami akan menemukan sesuatu yang terlewat selama peninjauan. Kami dapat menggunakan otomatisasi untuk menemukan masalah sederhana dan menyelesaikan masalah struktural selama fase desain dan perencanaan. Tinjauan kode tidak boleh menjadi ambulans di bagian bawah tebing, juga bukan satu-satunya pertahanan Anda yang mencegah bug yang melumpuhkan berakhir dalam produksi.

    Berbagi pengetahuan

    Jika kita hanya fokus pada menemukan kesalahan, kita melupakan mengapa kita melakukan tinjauan kode sejak awal. Salah satu manfaat paling berharga yang kami lewatkan adalah menggunakannya untuk belajar dan mengajar. Lagi pula, banyak kesalahan yang kami temukan saat meninjau kode disebabkan oleh sepenggal pengetahuan yang tidak dimiliki pengembang asli. Mengadopsi fokus pada berbagi pengetahuan mempromosikan “budaya belajar” dalam tim dan mengubah ulasan dari menilai menjadi berkolaborasi.

    Sebagai pengulas, kami dapat membuat beberapa perubahan kecil pada cara kami meninggalkan komentar pada ulasan. Luangkan lebih banyak usaha untuk menulis komentar informatif yang menjelaskan alasan Anda menyarankan perubahan, bukan hanya cara memperbaikinya – frasa komentar sebagai diskusi, bukan instruksi. Sertakan tautan atau contoh kode jika sesuai.

    Sementara itu, pengulas harus memperlakukan ulasan dengan rasa ingin tahu. Meninjau karya orang lain dapat membuat Anda menghadapi banyak teknik dan fitur yang tidak Anda ketahui. Catat hal-hal yang Anda lihat yang ingin Anda gali lebih jauh. Belajar melalui peninjauan kode tidak hanya memberi Anda informasi yang secara langsung relevan dengan Anda dan contoh yang konteksnya Anda miliki, tetapi Anda juga memiliki seseorang yang tersedia secara langsung untuk membantu Anda mempelajari lebih lanjut.

    Catatan kehati-hatian, tinjauan kode tidak boleh menggantikan uji tuntas Anda dan mencari tahu apa yang perlu Anda ketahui untuk menulis kode yang bersih, elegan, dan fungsional. Belajar dalam review kode harus fokus pada pengetahuan yang tidak Anda sadari hilang, daripada mengharapkan pengulas melakukan pekerjaan Anda untuk Anda.

    Memperjelas apa yang harus dan tidak boleh dilakukan pengulas tidak mencari

    Dalam peninjauan kode, ada lusinan hal yang mungkin perlu diperhatikan oleh peninjau kode, tetapi mereka berisiko menjadi aktivitas penampung-semua-besar yang mencakup setiap check in siklus hidup fitur. Namun, ulasan kode bukanlah tempat yang tepat untuk membahas banyak masalah ini.

    Kami dapat menyederhanakan tinjauan kode dan membantu peninjau mencari masalah yang paling berdampak dengan mempersempit cakupan dari apa yang seharusnya mereka cari. Misalnya, gunakan otomatisasi untuk memeriksa masalah pemformatan dan lint. Diskusikan masalah arsitektural yang signifikan di awal pengembangan fitur; peninjau harus yakin bahwa gambaran besar dari kode yang mereka ulas benar. Biarkan peninjau fokus pada keterbacaan dan pemeliharaan tanpa terganggu oleh masalah di luar lingkup tinjauan.

    Hindari ulasan “stempel karet”

    Beberapa tim dapat berakhir dalam situasi di mana sebagian besar perubahan kode mengalir melalui tahap peninjauan kode tanpa komentar atau umpan balik; tim Anda

    tidak ulasan kode karena begitulah cara pengembangan perangkat lunak dilakukan. Perilaku ini dapat menyebabkan penundaan yang lama bagi siapa pun untuk mendapatkan peninjauan, karena tidak ada yang percaya bahwa proses tersebut berharga – hanya kotak yang perlu dicentang. Sebelum Anda dapat meningkatkan tinjauan kode, pengembang harus yakin bahwa tinjauan kode bermanfaat bagi tim mereka. Mungkin pengembang tidak tahu apa yang harus mereka cari, Anda tidak memiliki standar pengkodean yang harus dikerjakan, atau mereka perlu melihat contoh tinjauan kode kualitas yang sedang beraksi.

    Alasan lain mengapa tidak ada orang yang berbicara dalam tinjauan kode adalah kurangnya keamanan psikologis dalam tim. Meninjau kode bisa jadi menantang. Hal ini memerlukan pengajuan pertanyaan tentang hal-hal yang tidak Anda pahami, mengakui bahwa Anda menemukan potongan kode yang terlalu rumit untuk dibaca, memberikan umpan balik dan saran yang mungkin ternyata tidak benar, dan tidak membiarkan diri Anda dipermainkan. Setiap orang dalam tim harus merasa nyaman untuk berbicara jika mereka yakin telah mengidentifikasi masalah dan tidak takut akan konsekuensi atau rasa malu karena kesalahan.

    Tangani perilaku ulasan negatif

    Banyak perilaku bermasalah dan beracun dapat terjadi dalam ulasan yang menyebabkan pengalaman tidak menyenangkan bagi semua orang yang terlibat. Peninjau yang meminta kode ditulis “dengan cara mereka”, mengirim spam ulasan dengan komentar yang sama beberapa kali, atau meninggalkan komentar kasar atau merendahkan – “Ya ampun,” “Saya tidak percaya Anda tidak tahu cara melakukan X.” Dalam kondisi terburuknya, ulasan dapat menjadi jalan bagi pengulas untuk menindas developer lain. Pengembang yang meminta ulasan bisa sama buruknya, tidak menghargai upaya yang dilakukan oleh pengulas, bersikap agresif dan bermusuhan, mencoba menyelinap sesuatu oleh pengulas, atau mengharapkan pengulas menulis kode untuk mereka.

    Perilaku seperti ini adalah masalah bagi manajer, bukan sesuatu yang dapat atau harus ditangani sendiri oleh pengembang. Namun, akan berguna bagi tim pengembangan untuk mengklarifikasi di antara mereka sendiri apa yang harus dicari dalam tinjauan kode dan menegaskan kembali bahwa tinjauan kode adalah untuk mengatasi masalah dalam kode, bukan mengatasi masalah pada orang.

    Image for post

    Image for post

    Berbagi kepemilikan

    Mungkin cara terbaik untuk meningkatkan budaya peninjauan kode Anda adalah dengan mengalihkan tanggung jawab setiap perubahan: dari hanya pengembang yang menulis kode, ke tim. Setiap orang harus memahami mengapa perubahan itu dibutuhkan dan merasa diinvestasikan untuk mewujudkannya. Saat semua orang ingin melihat fitur diselesaikan, kami melihat peningkatan motivasi pengembang, dan peninjau memiliki konteks latar belakang yang memadai untuk melakukan tinjauan yang efektif. Libatkan semua anggota tim dalam merencanakan fitur, dan tambahkan semua anggota tim sebagai peninjau untuk semua tinjauan kode tim. Menghancurkan silo dalam tim pengembangan tidak hanya membuat ulasan kode lebih kuat, tetapi juga meningkatkan throughput, kelincahan, dan kualitas kerja tim secara keseluruhan.

    Berikan kepemilikan kepada setiap tim atas proses peninjauan mereka

    Sebuah kepercayaan umum yang menahan kita meningkatkan proses peninjauan kode kami adalah bahwa peninjauan kode harus seragam di semua tim pengembangan. Kami mungkin meninjau seluruh tim dan menginginkan konsistensi itu dalam proses kami. Atau, kami mungkin memiliki basis kode bersama dan menginginkan konsistensi atas apa yang memasukinya.

    Namun, menjaga konsistensi peninjauan kode di seluruh tim mencegah setiap tim mengubah proses agar sesuai dengan kebutuhan khusus mereka. Sebuah tim yang terdiri dari dua pengembang senior memiliki gaya kerja yang berbeda dari tim yang terdiri dari satu senior, dua perantara, dan satu junior. Tim selalu pada akhirnya membangun budaya mereka sendiri, dan pengulas memiliki preferensi berbeda tentang apa yang harus dan tidak boleh masuk ke basis kode.

    Daripada satu set aturan terpadu untuk peninjauan kode, kita harus memiliki harapan terpadu untuk kualitas kode, dan memberdayakan setiap tim untuk mengontrol proses yang mereka perlukan memenuhi tujuan itu.

    Hapus ketergantungan pada pengulas dari luar tim

    Umumnya, saat menyusun tim, kami bertujuan agar setiap tim berfungsi lintas dan berisi semua keterampilan dan peran yang dibutuhkan untuk menyampaikan pekerjaan mereka. Namun, terkadang, kemampuan tim untuk melakukan peninjauan kode mereka sendiri tidak disertakan dalam rumus ini, dan tim harus mengandalkan peninjau dari tim lain. Terkadang, ini perlu; misalnya, kode tim kontraktor jangka pendek harus ditinjau oleh anggota tetap. Namun secara umum, memiliki peninjau di luar tim menciptakan banyak masalah. Peninjau eksternal tidak memiliki pengetahuan latar belakang yang memadai tentang fitur yang mereka ulas atau pemahaman tentang area basis kode tim Anda. Peninjau eksternal tidak berinvestasi dalam fitur tim Anda dan akan selalu mengutamakan tujuan, prioritas, dan tenggat waktu tim mereka sendiri. Tim yang berbeda mungkin memiliki budaya atau proses tinjauan yang berbeda, menyebabkan pekerjaan macet ketika setiap tim mengerjakan asumsi yang berbeda. Tinjauan kode eksternal sering kali terasa lebih menghakimi dan kurang kolaboratif, karena mungkin tidak ada hubungan kerja yang erat antara setiap sisi tinjauan.

    Seringkali, kami berakhir dengan ulasan lintas tim ketika ada penekanan berlebihan pada umpan balik dari pengembang senior, yang mungkin tersebar tipis di tim. Pengembang senior dari satu tim harus mendapatkan umpan balik dari pengembang senior di tim lain. Sebagai gantinya, kita harus memasukkan pengembang junior dan menengah dalam setiap tim: memberi mereka status peninjau yang setara, meningkatkan kemampuan peninjauan mereka, dan mempercayai ulasan mereka.

    Menjaga ulasan dalam tim memiliki manfaat lebih lanjut untuk mengurangi ukuran kumpulan pengulas. Itu membuat lebih sulit untuk mengabaikan ulasan atau berharap orang lain akan melakukannya. Mengetahui bahwa kami harus melihat sebagian besar antrean berarti kami tidak dapat menghindari ulasan.

    Waspadai sifat timbal balik dari tinjauan kode Image for post Pengembang adalah lebih cenderung meninjau kode untuk individu yang secara historis membalas budi dan meninjau pekerjaan mereka di masa lalu, mungkin karena rasa keadilan yang dirasakan, perdagangan ulasan eksplisit, atau bias yang tidak disadari. Baik atau buruk, itu adalah pola yang sulit diubah. Kecenderungan ini dapat menyebabkan masalah bagi junior dan karyawan baru yang tidak dapat meninjau kebijakan perusahaan atau merasa tidak siap sehingga tidak dapat membalas ulasan.

    Image for post Pada tingkat pribadi, itu mungkin berarti bahwa tidak ada orang yang meninjau kode Anda adalah Anda perlu mulai melakukan lebih banyak ulasan untuk kode orang lain. Kosongkan antrian permintaan ulasan Anda sambil menunggu pekerjaan Anda ditinjau.

    Default untuk menyetujui

    Sebagai pengulas, terkadang kami menjadi gugup saat kami tidak menemukan masalah dengan apa yang kami ulas. Kami khawatir pasti melewatkan sesuatu dan meninggalkan ulasan tanpa persetujuan, berharap pengembang berikutnya akan menemukan apa pun yang kami lewatkan. Pengembang kedua akhirnya datang beberapa hari kemudian, melihat hal-hal yang tidak kami miliki, dan memperkuat keyakinan kami.

    Sikap default kami adalah ingin memberi komentar dan mendorong ulasan kembali ke pengembang asli seolah-olah mundur -dan-seterusnya adalah tingkat tambahan dari bukti kebenaran kode. Namun, cara berpikir ini hanya berfungsi untuk memperlambat tinjauan dan mengurangi kepercayaan kami sebagai peninjau. Hanya karena Anda tidak melihat apa pun, bukan berarti Anda tidak menambahkan nilai dengan melihat.

    Pengalih pola pikir sederhana adalah mengubah sikap default Anda menjadi ‘persetujuan.’ Masuk ke ulasan yang bermaksud untuk menyetujui meninjau kecuali Anda menemukan sesuatu yang mendiskualifikasi. Tentu, beberapa masalah akan terlewatkan dalam peninjauan kode, tetapi harus ada lebih banyak pemeriksaan dalam proses Anda untuk menemukan kesalahan sebelum mereka menghentikan produksi.

    Menemukan waktu

    Kita semua ingin menghindari peralihan konteks, dan dengan alasan yang bagus, setiap kali kita mengubah aktivitas, perlu beberapa saat untuk bangkit kembali kecepatan. Terlalu banyak pengalihan dapat membuat kita kelelahan, mengurangi perhatian dan konsentrasi yang kita miliki untuk dihabiskan pada setiap tugas. Untuk mengatasi ini, banyak pengembang lebih memilih untuk menyelesaikan tugas mereka saat ini sebelum melihat item berikutnya dalam antrian mereka. Sambil mempertahankan fokus kami, kecenderungan ini mengarah ke tugas-tugas sekunder, seperti tinjauan kode, jatuh di pinggir jalan.

    Beberapa pengembang senior sangat sibuk bergantian antara rapat, perencanaan, dan membantu orang lain sehingga mereka jarang di meja mereka. Dalam periode singkatnya, mereka harus memilih antara melihat antrian peninjauan kode atau akhirnya mengerjakan tugas mereka.

    Waktu untuk tinjauan kode tidak akan pernah muncul secara ajaib. Kita perlu mewaspadai bias yang mencegah kita mendapatkan waktu itu. Miliki rencana bagaimana Anda menyesuaikan ulasan dalam hari Anda. Beberapa pengembang membuat rutinitas memeriksa antrian mereka di awal setiap hari atau setelah makan siang. Yang lain mengubah urutan prioritas mereka sehingga membuka blokir tugas orang lain lebih diutamakan daripada apa pun yang sedang mereka kerjakan, dan menerima dampak perubahan konteks.

    Bersikaplah baik kepada pengulas

    Kami perlu ingat bahwa pengulas adalah orang juga, dan memiliki waktu terbatas, energi, dan kesabaran. Kita harus mempertimbangkan bagaimana kita bisa membuat pengalaman mereka meninjau kode kita lebih mudah dan lebih menyenangkan. Lakukan “peninjauan sendiri” permintaan pull Anda untuk memeriksa kesalahan sepele seperti kode yang Anda beri komentar yang tersisa. Tidak diragukan lagi kebutaan terhadap perubahan akan membatasi apa yang dapat Anda temukan, tetapi secara keseluruhan tetap bermanfaat. Periksa apakah Anda telah menjalankan linter proyek Anda dan benar-benar menguji perubahan tersebut. Pisahkan pemformatan otomatis dan refaktor massal menjadi tinjauan atau kumpulan perubahan independen daripada mencampurnya dengan perubahan fungsional.

    Membangun kepercayaan adalah bagian penting dari proses peninjauan. Setelah beberapa bulan meninjau kode, Anda mendapatkan ide yang bagus tentang kekuatan dan kelemahan kolega Anda. Anda tahu siapa yang memeriksa empat kali lipat bahwa mereka telah memenuhi kriteria penerimaan fitur, yang sedikit ceroboh dengan konsistensi, dan yang tidak dapat membantu merefaktor semua yang mereka lihat.

    Namun , kami akan lebih sulit menyetujui set perubahan jika kami tidak memercayai pengembang asli untuk melakukan uji tuntas mereka. Kami perlu memeriksa ulasan lebih dekat dan menyelidiki pengembang asli dengan lebih banyak pertanyaan untuk memastikan mereka memahami masalah yang mereka coba selesaikan. Hindari merusak kepercayaan pengulas dengan mengirimkan kode yang jelas tidak pernah Anda periksa atau uji.

    Jangan merasa bersalah tentang menambahkan banyak komentar

    Seringkali, ulasan akan terasa malu atau bersalah ketika mereka menambahkan banyak komentar ke ulasan. Mereka khawatir akan terlalu menghakimi atau memberi seseorang banyak pekerjaan ekstra untuk diperbaiki. Dari sisi lain ulasan, banyak komentar bisa menjadi hal yang baik. Mereka memberikan lebih banyak kesempatan untuk belajar dan meningkatkan dan memberi Anda keyakinan bahwa kode Anda telah ditinjau secara menyeluruh dan seaman mungkin untuk dikirim. Kita semua menginginkan umpan balik dan untuk meningkatkan kemampuan kita, dan tinjauan kode dengan banyak komentar membantu kita mencapai tujuan tersebut.

    Lihat tinjauan kode sebagai penggunaan produktif waktu

    Pengembang cenderung memiliki banyak asumsi yang salah tentang apa artinya menjadi produktif. Menghabiskan terlalu banyak waktu untuk mengerjakan tugas-tugas sekunder seperti dokumentasi, sign-off, perencanaan, komunikasi, dan peninjauan kode dan tidak cukup waktu untuk menulis kode akan sering mengakibatkan penolakan yang kuat. Anda akan mendengar pengembang mengatakan hal-hal seperti, “Saya tidak menulis kode apa pun. Hari ini benar-benar sia-sia. ” Sikap seperti ini dalam sebuah tim sangat merusak. Menjadi pengembang adalah lebih dari sekadar menulis kode, dan setiap sikap yang bertentangan adalah sesuatu yang perlu kami tangani setiap kali kami melihatnya di tim kami.

    Image for post Gunakan tinjauan kode untuk membantu mengatasi kelumpuhan analisis

    Terkadang, menemukan keseimbangan antara momentum dan melakukan sesuatu dengan benar dapat menjadi tantangan. Kita mungkin khawatir kita telah melewatkan sesuatu yang penting atau memperkenalkan lebih banyak hutang teknis. Tinjauan kode penilaian membuat kecenderungan ini menjadi lebih jelas, menyebabkan beberapa pengembang menggandakan atau melipatgandakan waktu yang dihabiskan untuk tugas mencoba menghindari kehilangan apa pun.

    Secara umum, kami lebih baik memeriksa pertanyaan apa pun dengan kolega kami sebelum masuk ke fase peninjauan. Namun, menggunakan ulasan sebagai kesempatan untuk berkolaborasi dapat menjadi alat yang berguna untuk membantu kami terus bergerak, dengan asumsi kami telah melakukan uji tuntas yang wajar. Aplikasi perangkat lunak bisa jadi terlalu besar dan terlalu rumit, dan terkadang kita perlu menerima bahwa kita tidak tahu apa yang tidak kita ketahui dan sebagai gantinya perlu mengandalkan kolega kita.

    Gunakan status pemblokiran dengan hati-hati

    Teknik sederhana untuk membagi setengah durasi dari 90% tinjauan kode Anda adalah dengan menghapus r persyaratan bahwa perbaikan kecil harus ditinjau ulang. Kami harus mempercayai pengembang asli untuk memperbaiki kesalahan ejaan atau menambahkan pemeriksaan tambahan dalam metode tanpa menimbulkan kesalahan baru. Dorong peninjau untuk menggunakan status “Disetujui dengan komentar” sehingga pengembang asli dapat menggabungkan permintaan tarik setelah semua komentar diperbaiki atau ditanggapi tanpa memerlukan putaran tinjauan tambahan. Untuk platform tanpa tanda ini, seperti Github, tim Anda harus memutuskan cara alternatif untuk memberi sinyal status ini. Cadangan bendera ‘Perubahan Diminta’ untuk saat meminta perubahan signifikan atau saat Anda meninjau seseorang yang baru dalam proyek dan yang membutuhkan sedikit lebih banyak pengawasan.

    “Dua centang ”aturan

    Ini mungkin terdengar kontra-intuitif, tetapi menggandakan jumlah peninjau yang diperlukan untuk menyetujui tinjauan sering kali akan menghasilkan tinjauan dengan waktu penyelesaian yang lebih cepat. Mengetahui bahwa orang kedua akan menangkap apa pun yang mereka lewatkan akan memudahkan pengulas untuk mulai melihat ulasan. Sementara itu, orang kedua akan merasa lebih mudah untuk melompat ke ulasan karena tahu orang lain telah melihatnya. Bekerja sebagai pasangan seperti ini meningkatkan kepercayaan diri setiap pengembang dan mengurangi tekanan yang mungkin dirasakan oleh peninjau kode tunggal untuk menangkap semuanya.

    Kedua, memiliki dua peninjau menggandakan manfaat sekunder dari peninjauan kode, meningkatkan peluang berbagi pengetahuan, membuat lebih banyak pengembang menyadari bagaimana kode berubah, dan mengurangi silo dalam tim. Memiliki dua peninjau berarti Anda dapat memiliki satu anggota tim berpengalaman untuk mengajar dan membimbing dan anggota tim lain yang kurang berpengalaman hadir dalam tinjauan untuk mempelajari tentang basis kode dan praktik pengembangan tim. Efek ini juga meluas untuk membantu setiap pengembang meningkatkan kemampuan peninjauan mereka, dengan setiap pengembang memperhatikan apa yang ditemukan pengulas lain tetapi tidak mereka lakukan.

    Namun, memiliki beberapa pengulas pada sebuah ulasan memang membutuhkan perhatian. Lebih banyak peninjau berarti overhead komunikasi yang lebih tinggi dan meningkatkan peluang peninjauan kode untuk berakhir dalam keadaan yang ambigu. Peninjau perlu menggunakan status pemblokiran dengan hati-hati, karena Anda mungkin menemukan peninjau kedua belum memulai peninjauan karena peninjau pertama sudah meminta perubahan. Sementara itu, pengembang asli menunggu pengulas kedua untuk berkomentar sebelum mereka mengganti konteks untuk mulai memperbaiki sesuatu.

    Pisahkan komentar nitpicking

    Salah satu perilaku ulasan yang lebih kontroversial adalah komentar yang cuek. Di sini, peninjau menunjukkan masalah yang tidak memiliki dampak fungsional atau dampak sepele pada pemeliharaan. Mungkin sepotong logika dapat ditulis ulang dalam beberapa baris kode yang lebih sedikit, atau ada penyimpangan kecil dari panduan gaya. Saya cenderung menghargai nitpicks karena mereka menyediakan sumber pembelajaran yang baik untuk fitur bahasa minor dan khusus; plus, saya lebih suka kode saya konsisten. Namun, banyak pengembang melihat mereka sebagai sumber frustrasi dan tidak suka pekerjaan mereka ditahan atas apa yang mereka anggap sebagai kerewelan.

    Nitpick juga dapat mengungkap perbedaan pendapat yang valid, di mana kedua cara itu benar. Dalam kasus ini, ini dapat dianggap sebagai peninjau yang memaksakan cara mereka menulis kode.

    Saya merasa berguna untuk membiarkan saran nitpicking menjadi opsional dan memisahkannya dari masalah yang saya perlu perbaiki dengan mengawali komentar dengan bendera seperti “nitpick” atau “opsional.” Juga berguna untuk membangun panduan gaya dalam tim Anda dan menetapkan pola perbedaan pendapat yang valid. Diskusikan dengan tim Anda tentang nilai konsistensi dalam basis kode. Tidaklah berguna untuk menghindari penyebutan nitpicks, karena memiliki beberapa nilai, dan penting untuk tidak terjebak dalam menebak-nebak setiap komentar yang ingin Anda kemukakan.

    Sertakan waktu peninjauan kode saat memperkirakan tugas

    Terkadang, kita jatuh ke dalam perangkap di mana kita merasa seperti kita berada secara permanen terlambat dari jadwal. Ada tenggat waktu dan komitmen, dan kami merasa satu-satunya cara untuk mengejar ketinggalan adalah dengan mengabaikan semua “tugas dukungan” kami, seperti tinjauan kode. Seringkali, ketika kami tidak punya waktu untuk hal lain selain menulis kode, kami gagal memasukkan tugas-tugas tersebut dalam perkiraan kami, hanya berfokus pada perkiraan waktu untuk mengembangkan dan menguji fitur tersebut. Kita cenderung lupa tentang mengalokasikan waktu untuk dokumentasi, sign-off, serah terima, dan review kode.

    Peninjauan kode dapat menghabiskan banyak waktu; menurut pengalaman saya, para pengembang biasanya menghabiskan waktu 3–5 jam seminggu untuk meninjau kode orang lain atau menanggapi tinjauan kode mereka. Kami tidak dapat mengharapkan tinjauan kode dan kemudian tidak menyediakan waktu yang kami butuhkan untuk melakukannya.

    Alternatif untuk memasukkan tinjauan kode secara langsung dalam perkiraan kami adalah dengan mengurangi kapasitas harian setiap pengembang. Misalnya, salah satu tim saya sebelumnya memperkirakan kemampuan setiap pengembang untuk mengerjakan tugas selama lima jam sehari, dengan sisanya dihabiskan untuk rapat, melakukan tinjauan kode, membantu orang lain, merencanakan pekerjaan yang akan datang, istirahat, atau 10% waktu.

    Diskusikan ulasan secara langsung jika berguna

    Tidak semua diskusi tentang ulasan harus dilakukan di dalam platform ulasan itu sendiri. Sering kali lebih mudah dan lebih cepat untuk berdiskusi atau memandu secara langsung. Berayun di meja orang lain bisa menjadi sangat penting ketika kompromi dalam kode diperlukan. Pengalaman terpisah yang disediakan platform ulasan kode tidak mendorong pemahaman dan empati yang diperlukan.

    Namun, terlalu mengandalkan penjelasan langsung harus dilakukan dengan hati-hati. Basis kode harus dapat dimengerti tanpa penjelasan. Saat Anda perlu memperpanjang atau mempertahankan kode ini dalam enam bulan, Anda mungkin tidak memiliki akses ke pengembang asli untuk menjelaskan cara kerja kode mereka. Ingatlah untuk mencatat kembali diskusi atau keputusan secara langsung di platform ulasan sehingga pengulas lain tahu apa yang dibahas.

    Kurangi ambiguitas dalam proses Anda

    Proses peninjauan kode tim dapat penuh dengan ambiguitas yang menambah gesekan dan menyebabkan penundaan. Mungkin sulit bagi peninjau untuk mengetahui kapan permintaan tarik siap untuk ditinjau atau kapan pengembang asli telah selesai melakukan perbaikan, dan tinjauan siap untuk ditinjau ulang. Anda dapat mengejar tinjauan tertunda hanya untuk menemukan bahwa peninjau mengira mereka sudah menyetujuinya. Prioritas ulasan dapat menyesatkan, dan dapat membuat frustasi jika meninggalkan semuanya untuk meninjau karya yang seharusnya berprioritas tinggi hanya untuk melihatnya merana tanpa penggabungan selama beberapa hari atau minggu setelahnya.

    Aturan yang menentukan kapan peninjauan kode ‘selesai’ mungkin tidak jelas. Berapa banyak orang yang perlu menandai ‘disetujui’? Persetujuan siapa yang penting? Apakah perubahan Anda perlu ditinjau ulang? Apakah komentar itu merupakan saran opsional atau perbaikan wajib? Apakah komentar yang Anda tinggalkan oke, itu menjelaskan mengapa Anda tidak membuat perbaikan? Apakah ulasan dari orang di luar tim dihitung? Apakah masih ada yang salah, atau apakah salah satu pengulas lupa memperbarui statusnya?

    Tim sering kali memiliki aturan tak tertulis tentang proses peninjauan kode mereka, sehingga menyulitkan orang yang baru mengenal tim dan budayanya untuk berpartisipasi. Tim yang berbeda mungkin memiliki proses yang berbeda, sehingga sulit untuk meninjau seluruh tim.

    Jika ambiguitas dan ketidakpastian memperlambat proses peninjauan kode Anda, mungkin ada baiknya memformalkan aturan tim dan perusahaan, mendokumentasikannya di tempat yang tersedia secara luas. Komunikasikan tentang ulasan menggunakan media yang lebih permanen daripada mengandalkan email dari platform ulasan kode Anda. Misalnya, kami akan menggunakan saluran Slack tim kami untuk berkomunikasi ketika ulasan siap untuk dimulai, berapa banyak persetujuan yang tersisa, atau ketika ulasan siap untuk dilihat kedua kali.

Imbalan untuk menangani dan meningkatkan praktik tinjauan kode tim Anda tinggi. Dilakukan dengan baik, peninjauan kode dapat menjadi mesin yang memberdayakan tim Anda, membantu komunikasi, kerja tim, dan berbagi pengetahuan sekaligus menjaga kualitas dan pemeliharaan kode yang berkomitmen setinggi mungkin. Tinjauan kode dapat menjadi sesuatu yang setiap orang secara aktif melihat ke depan. Pengembang menjadi antusias untuk mendapatkan umpan balik dan menginginkan kepercayaan diri yang diberikan melalui pemeriksaan menyeluruh. Sementara itu, pengulas menikmati kesempatan untuk membantu anggota tim lainnya dan menyampaikan fitur tersebut. Semua ilustrasi yang digunakan dalam posting ini bersumber dari

https://undraw.co/

Read More

RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments