Katakanlah seseorang bekerja di perusahaan hipotetis yang memiliki beberapa pengembang yang jarang bekerja bersama dalam proyek dan Bos tidak percaya bahwa tinjauan kode sepadan dengan waktu dan biaya.
Apa berbagai argumen yang dapat disajikan dalam skenario ini yang akan menggambarkan manfaat dari tinjauan kode? Lebih lanjut, apa argumen potensial terhadap tinjauan kode di sini dan bagaimana hal ini dapat dilawan?
Jawaban:
Jika Anda harus membenarkan diri sendiri untuk hal-hal mendasar seperti itu, Anda memiliki masalah yang lebih besar.
Anda ahli, tim Anda harus memutuskan praktik apa yang Anda gunakan. Mungkin Anda harus mulai meyakinkan bos Anda tentang prinsip yang sangat penting itu.
Bos Anda seharusnya memutuskan APA yang harus dilakukan dan yang lebih penting MENGAPA melakukannya. Anda harus merawat BAGAIMANA membangunnya
(itu tidak berarti Anda tidak dapat menyarankan apa dan mengapa melakukan hal-hal di perusahaan Anda tentu saja). Seorang bos yang hebat harus mendorong karyawannya untuk berpartisipasi dalam strategi perusahaan)
Namun demikian, inilah cara saya melihat ulasan kode rekan:
Karena pemrograman adalah pekerjaan intelektual yang sangat intensif, satu orang tidak dapat memastikan semuanya sempurna. Oleh karena itu tinjauan kode memastikan bahwa:
Setiap orang mengambil manfaat langsung dari itu:
Tinjauan kode dapat membuat banyak pengembang terbiasa dengan kode yang sama. Ini hal yang baik. Bagaimana jika penulis asli memutuskan untuk berhenti atau lebih buruk, sesuatu yang buruk terjadi padanya. Jika ulasan kode dilakukan secara teratur, orang lain dapat mengambil alih dengan cepat.
Teman sebaya mungkin dapat menemukan bug potensial atau masalah kinerja selama peninjauan kode. Ini mengurangi QA dan upaya pengembangan. Ini dapat mengkompensasi biaya tambahan yang terlibat dalam ulasan kode.
Ulasan kode mempromosikan berbagi pengetahuan. Teman sebaya dapat mengetahui cara yang lebih baik atau cara alternatif dalam melakukan sesuatu. Saya sendiri telah belajar banyak dari rekan-rekan saya melalui ulasan kode.
Ulasan kode membantu memperkuat pedoman pengkodean yang diikuti oleh tim. Jika tim tidak memilikinya, itu perlu diperbaiki. Kode dimaksudkan untuk ditulis satu kali dan dibaca berulang kali. Pedoman pengkodean adalah langkah menuju kode yang dapat dibaca. Kode dimaksudkan agar dapat dibaca oleh teman sebaya. Apa cara yang lebih baik daripada memiliki ulasan kode untuk memastikan keterbacaan?
Banyak jawaban bagus di sini. Beberapa hal yang ingin saya tambahkan:
Ketika Anda harus menjelaskan kode kepada orang lain, sering kali dalam penjelasannya pengembang tiba-tiba menyadari bahwa ia memiliki bug. Saya telah melihat itu terjadi berulang-ulang bahwa dev berhenti mati di jalurnya dan berkata "oh tunggu itu salah" sebelum pengulas telah memahami hal itu dengan cukup baik untuk melihat bug.
Mengetahui kode Anda akan diperiksa oleh orang lain memberi Anda lebih banyak insentif untuk menggunakan standar pengkodean (membuat pemeliharaan lebih mudah) atau menggunakan lebih sedikit metode "koboi" yang tidak akan dipahami oleh siapa pun selain diri Anda sendiri (dan kadang-kadang bahkan bukan diri Anda sendiri). Anda tidak ingin malu ketika Anda menunjukkan kode Anda kepada orang lain, jadi Anda melakukan pekerjaan yang lebih baik di atasnya. Karena faktor yang memalukan, semakin sedikit kode yang dikomentari dengan: "Saya tidak tahu mengapa ini berhasil tetapi jangan mengacaukannya." di basis kode.
Pengembang yang memiliki kebutuhan untuk pengawasan atau pelatihan yang lebih luas mudah diidentifikasi. Begitu juga yang tidak kompeten langsung. Semakin cepat Anda dapat menemukan dan mengatasi masalah kinerja, semakin baik tim secara keseluruhan dan semakin tinggi kualitas aplikasi. Adalah baik untuk mengetahui informasi ini sebelum Anda mengambil orang baru yang membutuhkan pelatihan dan menugaskannya ke bagian paling sulit, paling kritis dari aplikasi Anda.
Kadang-kadang itu hanya masalah memperbaiki kesalahan persepsi yang akan menyelamatkan membuat kesalahan yang sama di banyak tempat lain. Sebagai contoh, kami baru-baru ini meninjau beberapa SQL untuk laporan kompleks dan menemukan bahwa beberapa pengembang baru kami memiliki kesalahpahaman yang sama tentang di mana menemukan sepotong informasi tertentu dalam database (memang tempat yang mereka pilih tampak logis yang merupakan masalah desain database kami. juga perlu diperbaiki) yang sangat penting untuk menulis semua laporan dengan benar. Dengan menemukan masalah dan memperbaikinya dalam laporan pertama yang mereka tulis, itu menyimpan kesalahan yang sama dari yang terjadi di sisa laporan. Dan sesuatu yang lebih tua (pada waktu bekerja di sini bukan usia) devs begitu terbiasa sehingga mereka tidak berpikir perlu menjelaskan keluar.
Junior dapat belajar dari kode yang lebih canggih yang ditulis oleh manula (yang cenderung lebih memahami kasus trapping dan edge misalnya) dan manula dapat belajar dari teknik baru yang digunakan oleh junior bahwa mereka belum terekspos.
Kadang-kadang orang yang mengerjakan bagian aplikasi yang berbeda tetapi terkait menyadari bahwa mereka akan pergi dalam dua arah yang berbeda dan saling eksklusif. Ups, lebih mudah diperbaiki sekarang.
Tidak mudah untuk menyelinap dalam nilai-nilai hard-coded yang akan berubah seiring waktu hanya untuk membuat hal itu berfungsi sekarang. Ini mencegah banyak bug di masa depan seperti hal-hal yang berubah pada awal setiap tahun fiskal.
Saya kadang-kadang terjebak pada bagaimana melakukan sesuatu dan belajar teknik baru yang persis seperti yang saya inginkan dari meninjau kode barang orang lain.
Jika Anda terbiasa dengan cara berpikir anggota tim Anda yang lain (peninjauan kode mana yang akan membantu memberi Anda pemahaman itu), maka akan lebih mudah untuk memecahkan masalah nanti karena Anda akan mulai dengan pemahaman tentang bagaimana Joe akan mendekati pendekatan semacam itu. masalah.
Seperti halnya berbagi pengetahuan yang disebutkan oleh yang lain, temukan contoh bug yang akan ditemukan selama tinjauan kode dan ukur berapa lama waktu yang diperlukan untuk memperbaikinya - ini termasuk waktu yang dihabiskan untuk meneliti masalah dan merilis versi yang ditambal serta versi waktu aktual memperbaiki bug.
Ambil biaya ini, yang mungkin akan menjadi upaya setidaknya beberapa hari, dan kontras dengan waktu yang Anda habiskan untuk review kode dan bertindak atas hasilnya.
Ini akan menunjukkan kepada bos Anda bahwa ulasan kode sepadan dengan biayanya.
Ulasan Kode Dapat:
Cons
Jika itu benar, mengapa kita selalu punya waktu untuk melakukan hal-hal dua atau tiga kali untuk pelanggan yang sama tetapi kita tidak pernah punya cukup waktu untuk melakukannya dengan benar pada kali pertama.
Jika Anda perlu mereferensikan dokumen maka saya akan mencari "Kode Lengkap." Di dalamnya, buku ini menjelaskan berapa banyak kesalahan yang ditangkap dengan unit test vs peer review. Sangat mencengangkan. Unit test, jika ingatanku benar, tangkap hanya ~ 30% dari semua bug sementara peer review formal menangkap ~ 70%.
Ambil informasi itu, tunjukkan padanya di buku dan naik banding ke sisi keuangannya. Dibutuhkan jauh lebih lama dan jauh lebih mahal untuk memungkinkan bug melewatinya daripada menangkapnya lebih awal.
Bagaimana menjalankan demo (proyek sejenis "mickey mouse" satu minggu) yang dijalankan secara paralel oleh dua tim, satu menggunakan tinjauan kode, yang lain tidak.
Pada akhir minggu, menilai kualitas kerja masing-masing tim, saya cukup yakin bahwa peninjau kode akan menjadi lebih baik.
Dari Construx Steve Mcconnel, Kasus Bisnis untuk Praktik Perangkat Lunak yang Lebih Baik dan Buah Rendah Pengembangan Perangkat Lunak (LHF) dari Pengembangan Perangkat Lunak membahas hal ini. Dari yang terakhir "LHF yang tidak akan ditolak oleh Manajemen Atas" daftar Inspeksi.
Saat mempresentasikannya, fokuslah pada gambaran yang lebih besar.
Buat daftar manfaat (kode yang lebih baik, lebih sedikit bug, lebih sedikit penulisan ulang, dll) dan sebutkan ulasan kode sebagai salah satu teknik yang akan Anda rekomendasikan.
Saya akan menjadikannya bagian dari gambaran yang lebih besar dalam melakukan pengerjaan perangkat lunak
Bersiaplah untuk melakukan banyak pekerjaan sendiri dalam mempromosikan prinsip-prinsip ini.
Kebanyakan dari semua tidak berharap persuasi menjadi "satu pertemuan dan selesai" agak hal.
Anda harus membangun kasing dari waktu ke waktu dengan tenang dan konsisten. Ketika Anda paling jengkel dengan bug yang diperbaiki dengan teknik yang lebih baik, sering kali adalah saat terburuk untuk membuat kasus Anda karena Anda cenderung terlalu emosional dan kurang rasional. Ini mungkin tampak agak kontra-intuitif, tetapi itulah yang telah saya pelajari selama 30 tahun pemrograman. Jelas ymmv.