Bagaimana cara menangani tanpa ulasan kode di tempat baru saya ketika saya datang dari latihan itu?


33

Tim di perusahaan baru saya tidak memiliki proses peninjauan kode.

Saya berasal dari perusahaan dengan tinjauan kode sebagai budaya wajib dan karenanya saya tidak merasa nyaman melakukan kode saya tanpa ditinjau oleh seseorang.

Saya sangat percaya bahwa tinjauan kode adalah cara untuk meningkatkan kualitas dan menghemat waktu karena menangkap masalah potensial sebelumnya (perhatikan bahwa saya tidak berbicara tentang pemrograman pasangan).

  • Bagaimana saya bisa menunjukkan bahwa tinjauan kode bukan pemboros waktu tetapi penghemat waktu?
  • Dapatkah tinjauan kode dilewati jika Anda memiliki unit test?

rekomendasi sumber daya di luar situs secara eksplisit di luar topik per pusat bantuan . Lihat meta.programmers.stackexchange.com/questions/6483/...
nyamuk

1
Pertimbangkan untuk bertanya di sini: meta.codereview.stackexchange.com Dan dalam pikiran saya, pertanyaan ini dapat ditanyakan di sini karena dia hanya ingin tahu sesuatu konsep yang berkaitan dengan Pemrograman.
xqMogvKW

1
Meskipun saya juga sangat percaya pada tinjauan kode, saya juga memiliki beberapa pengalaman buruk di mana tinjauan kode berubah menjadi perang abadi, alat tinjauan kode (gerrit) berubah menjadi avatar buruk dari beberapa papan diskusi dengan debat yang terlalu bersemangat yang dipimpin oleh para pemimpin. oleh ego yang terlalu besar. Saya tidak yakin apakah ini pasti akan terjadi di perusahaan mana pun, atau apakah ini hanya masalah kedewasaan orang.
Joel

Dengan judul apa yang Anda tanyakan bertanya karena "Apakah Peninjauan Kode suatu keharusan?" adalah pertanyaan yang terlalu luas dan tidak dapat dijawab karena akan tergantung pada sejumlah besar faktor - ukuran perusahaan, # pengembang, pendapatan, dll. pembuatan perangkat lunak di situs publik Anda (resume, tautan, github, twitter, dll). mempublikasikan apa yang Anda pedulikan dan apa yang Anda cari sehingga orang-orang yang Anda inginkan akan melihatnya. Ini adalah saran 'masa depan' tentu saja, karenanya komentar :)
Michael Durrant

3
Saya tidak dapat melihat bagaimana ini merupakan "rekomendasi sumber daya di luar situs". Itu kedengarannya bukan alasan yang tepat bagi saya.
nyuszika7h

Jawaban:


30

Dapatkah tinjauan kode dilewati jika Anda memiliki unit test?

Tapi kenapa?

Peran utama peer review bukan untuk menangkap bug.

Ya, Anda dapat mengidentifikasi beberapa bug potensial dan kode rawan bug yang meragukan, ini sering terjadi, tetapi terkadang menemukan beberapa kesalahan tidak berarti bahwa peer review adalah cara yang dapat diandalkan untuk mengesampingkan keberadaan bug. Jauh dari itu. Ini bukan alat yang tepat untuk memverifikasi kebenaran fungsional implementasi.

Tinjauan kode memberlakukan pemeliharaan kode . Saya akan menuntut kode itu bersih dan dapat dimengerti (tidak hanya untuk pembuatnya) sebelum mulai diproduksi.

Kehadiran unit test sepenuhnya ortogonal untuk itu. Anda dapat memiliki cakupan kode 100% dan semua tes lulus untuk kode yang benar-benar tidak dapat dipahami.

Peninjauan kode juga berfungsi untuk membiasakan pengembang lain dengan pekerjaan Anda sehingga mereka tahu apa itu dan dapat mengambilnya dari sana, atau menangani laporan bug saat Anda sedang berlibur dll. Mengetahui apa yang telah Anda lakukan dengan segera dapat membantu mereka lakukan pekerjaan mereka dengan baik - pertahankan basis kode konsisten (tetap berpegang pada pola dan konvensi serupa di seluruh aplikasi), atau menghindari duplikasi kode.

Dalam skema yang lebih luas, seseorang juga belajar dan tumbuh sebagai pengembang dari membaca kode orang lain.

Tes unit hampir tidak bisa menjadi pengganti untuk semua itu. Ya, jika ditulis dengan baik, mereka membaca seperti dokumentasi, dan kita harus berusaha untuk ini. Tapi sekali lagi ini tidak eksklusif dengan melakukan peer review, justru sebaliknya - semua keuntungan dari peer review masih berlaku, fakta bahwa rekan-rekan Anda memiliki beberapa unit test yang bagus untuk dilihat hanya akan membuat proses peninjauan lebih mudah dan bahkan lebih menguntungkan bukannya berlebihan.


4
Saya tidak percaya unit test adalah pengganti untuk ulasan kode juga. Tetapi peran utama unit test bukanlah untuk menangkap bug, baik. Ya, Anda dapat mengidentifikasi beberapa bug potensial saat menulis tes unit, tetapi tes unit adalah untuk memastikan Anda tidak akan memperkenalkan bug nanti ketika Anda harus mengubah sesuatu. Jadi tujuan unit test adalah menjaga kode Anda tetap terpelihara juga.
Doc Brown

2
@ DocBrown benar itu. Namun menangkap bug regresi termasuk dalam kategori menangkap bug juga. Jelas ini adalah salah satu kelebihan yang dimiliki unit test dibandingkan peer review (dalam aspek ini), karena mereka bukan operasi satu kali. Peer review bahkan tidak berusaha menangani aspek penting ini, karena tidak layak untuk meninjau ulang seluruh basis kode setelah setiap perubahan.
Konrad Morawski

1
@DocBrown Peer review doesn't even attempt to tackle this important aspect- yah, memang, semacam. Sampai batas tertentu. Saya sering menemukan diri saya menunjukkan misalnya. "Mitra, Anda secara efektif mengulangi logika yang sama di sini, dan itu adalah bom detak. Suatu hari itu akan berubah di tempat lain itu dan kami akan lupa untuk memperbaruinya di sini ..."
Konrad Morawski

24

Apakah ada studi dan statistik yang menunjukkan tinjauan kode bukan pemborosan waktu tetapi penghemat waktu?

Saya tidak tahu. Juga sulit untuk melakukan studi seperti itu, karena Anda membutuhkan dua tim yang memiliki tugas untuk menyelesaikan kompleksitas yang sama dan realistis , di mana satu menggunakan ulasan kode dan yang lainnya tidak. Anda mungkin perlu meminta mereka menyelesaikan masalah yang sama , yang berarti membuang banyak uang ke luar jendela. Dan Anda perlu mengulangi eksperimen cukup sering untuk mendapatkan relevansi statistik, yang akan meningkatkan jumlah uang yang dikeluarkan oleh pesanan besar.

Jika Anda hanya mengukur efisiensi perusahaan yang menggunakan tinjauan kode terhadap perusahaan yang tidak, tidak hanya tidak jelas cara mengukur efisiensi, tetapi juga apa penyebab sebenarnya. Ulasan kode adalah bagian dari budaya yang lebih besar. Bagian mana yang benar-benar membuat tim lebih efisien adalah sulit untuk diceritakan (dan mungkin sangat tergantung pada sifat tim atau proyek). Atau keberadaan budaya ini dapat berarti bahwa perusahaan itu lebih kecil atau lebih muda, yang masing-masing memiliki banyak efek. Atau mungkin saja kesediaan untuk tunduk pada ulasan kode menghalangi atau mendorong jarak yang sehat ke ego Anda;)

Tapi jangan lupa: Anda memiliki pengalaman sendiri untuk menggambar. Itu bagian dari mengapa mereka mempekerjakan Anda. Jadi, jika Anda benar-benar yakin dapat meningkatkan efisiensi (dan tim Anda benar-benar menderita kekurangannya), maka komunikasikan dengan jelas.

Dapatkah tinjauan kode dilewati jika Anda memiliki unit test?

Nggak. Jika Anda meyakini pentingnya tes, maka sebenarnya tes Anda harus menjadi hal pertama yang ditinjau. Bagaimana jika itu omong kosong? Atau apakah cakupannya buruk? Atau jika mereka menguji implementasi daripada perilaku?


2
Saya pikir Anda membuat poin nyata yang bagus pada tinjauan kode untuk kasus uji. Terima kasih!
jparkcool

4
+1 untuk "Anda memiliki pengalaman sendiri untuk menarik" - sebenarnya, jika seseorang telah benar-benar bekerja dengan ulasan kode untuk beberapa waktu, ia pasti telah melihat berapa banyak masalah kualitas yang biasanya diperbaiki selama tinjauan kode yang umum, dan berapa banyak transfer pengetahuan tercapai. Dari pengalaman itu seharusnya sulit untuk tidak memiliki beberapa argumen untuk atau menentang tinjauan kode.
Doc Brown

2
Mengenai paragraf pertama Anda: Ini akan membutuhkan tidak hanya dua tim yang melakukan tugas yang sama, tetapi dua tim dengan kemampuan yang sama, pengalaman individu akan mengacaukan usaha apa pun untuk mempelajari hal ini.
David Wilkins

"Bagaimana jika itu omong kosong? Atau jika liputannya buruk?" Atau katakan saja return true;.
Burhan Ali

1
Baca bab 20 dari Kode Lengkap untuk perawatan menyeluruh dari tinjauan kode, dan studi dan statistik yang mendukung penggunaannya. Berikut adalah beberapa rangkuman yang bagus: blog Jeff Atwood dan cowok lain
Mike Partridge

5

Diambil dari beberapa slide acak yang saya temukan , tetapi data kerasnya berasal dari buku Lengkap Kode Steve McConnell:

Apakah Ulasan Kode Berguna?

"Saya percaya bahwa tinjauan kode rekan adalah hal terbesar yang dapat Anda lakukan untuk meningkatkan kode Anda"

Jeff Atwood dari Coding Horror di http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html


"Inspeksi individu biasanya menangkap sekitar 60 persen cacat, yang lebih tinggi daripada teknik lain kecuali prototipe dan pengujian beta volume tinggi."

Steve McConnell, Code Complete 2nd Edition, halaman 485

Angka 60% itu berasal dari makalah IEEE oleh Shull et al 2002 Apa yang Telah Kita Pelajari Tentang Memerangi Cacat yang berisi bagian berjudul:

"Peer reviews menangkap 60% dari cacat"


1
Saya pikir masalah dengan ini adalah pada tahun 2006 kami belum sepenuhnya merangkul pemrograman pasangan, yang saya rasa telah menjadi semacam pengganti untuk melakukan tinjauan kode rekan dengan cara tertentu. Saya menyadari bahwa mereka tidak sebanding dalam beberapa hal.
JP Silvashy

3

Penafian: Jawaban ini adalah pengalaman pribadi saya :)

Saya membuat pengalaman yang sangat buruk dengan ulasan kode dalam kode yang kami pertahankan. Karena kami biasanya hanya memiliki satu liner atau lebih dan tidak banyak yang harus ditinjau.

Tetapi dalam proyek-proyek aktual saya membuat pengalaman yang baik, pada waktu ujian saya pelatih saya meninjau peraturan saya dan itu banyak membantu saya untuk menemukan beberapa kesalahan yang saya buat sangat sering, yang tidak saya lakukan lagi.

Jadi saya akan mengatakan itu sangat tergantung pada apa yang Anda lakukan, berapa banyak orang, dll.

Juga risiko bahwa codereviews Anda berakhir dalam perang tidak diremehkan.


3

Anda dapat meminta ketua tim dan / atau kolega Anda untuk melakukan peer-review kode Anda, bahkan jika tinjauan kode tidak dilakukan secara normal, mungkin sebagai bagian dari pelatihan Anda.

Pastikan kode Anda ditulis dengan baik dan diuji sebelum ditinjau.

Ketika saya adalah seorang pemimpin tim, saya biasa melakukan review kode sendiri dari karyawan baru, sampai (setelah beberapa saat) saya akan berhenti menemukan bug atau apa pun untuk mengkritik kode mereka, dan pada titik mana saya akan berhenti melakukan review kode dengan mereka; itu akan terjadi ketika:

  • Mereka mempelajari sistem yang berinteraksi dengan mereka dan tidak membutuhkan penjelasan saya tentang itu
  • Mereka belajar mendesain dan / atau menguji kode mereka sampai bebas bug sebelum saya melihatnya
  • Mereka cukup belajar tentang pedoman gaya pengkodean saya sehingga saya menganggap kode mereka dapat dipertahankan

Ulasan kode memiliki beberapa tujuan:

  • Menemukan cacat dalam kode
  • Transfer pengetahuan antara anggota tim

Saya pikir tidak apa-apa untuk melakukan review kode karyawan baru, bahkan jika tim memilih untuk melewatkan review kode di antara anggota tim yang berpengalaman.


2

Tidak ada aturan praktis untuk ulasan kode yang harus dilakukan pada perangkat lunak apa pun yang dikembangkan ... semuanya tergantung pada ruang lingkup aplikasi, ukuran klien dan ukuran perusahaan. Misalnya, jika Anda sedang membangun aplikasi di mana itu adalah aplikasi sederhana di mana mungkin tidak ada versi lebih lanjut sedang dilaksanakan di masa depan, pengujian unit sudah cukup di sana. Tetapi sekali lagi tinjauan kode terjadi ketika Anda berbicara tentang kinerja aplikasi di mana Anda perlu meninjau kode untuk setiap jatuh pendek dari kode yang bisa dilakukan dengan cara yang lebih baik untuk memfasilitasi kinerja yang lebih cepat.

Tinjauan kode biasanya dilakukan di mana ada tim yang terdiri lebih dari 2 pengembang dan pemimpin teknologi di mana pemimpin teknologi ingin memastikan kualitas aplikasi dan memastikan standar kode diikuti untuk mengukur aplikasi untuk peningkatan di masa depan dan meningkatkannya untuk berbagai versi mendatang.

Sebagai contoh, kami memiliki banyak platform open source CMS sekarang dan platform ini merilis peningkatan dari waktu ke waktu untuk meningkatkan fitur platform, bayangkan seorang pengembang menggunakan salah satu platform ini dan belum mengikuti standar kode seperti pengkodean keras dalam file inti, aplikasi penulisan kode dalam file templat, dan jika kode ini digunakan untuk produksi dan nanti ketika klien ingin memutakhirkan platform ke versi baru, kode itu tidak akan pernah ditingkatkan kecuali pengkodean dilakukan ulang sesuai standar kode untuk platform itu. Ini menjadi masalah serius untuk merilis kode ke produksi tanpa review kode yang dilakukan.

Jadi saya akan mengatakan memiliki ulasan kode yang dilakukan sebelum rilis adalah suatu keharusan bagi setiap perusahaan perangkat lunak profesional dan pengecualian hanya dapat untuk aplikasi skala pribadi / sangat kecil di mana pengembang adalah programmer yang sangat berpengalaman dan membawa pengalaman bersamanya.


1

Peninjauan kode memiliki kelebihan yang tidak berasal dari proses peninjauan itu sendiri: Selalu ada dilema untuk mendapatkan kode yang berkualitas tinggi, tetapi dibuat dalam waktu singkat. Tanpa ulasan kode, Anda sendirian, sehingga Anda dapat mengorbankan kualitas untuk melakukan kode dalam waktu singkat. Dengan ulasan kode, ada pengulas ini yang tidak membiarkan Anda lolos dengan kualitas kode rendah - yang persis seperti yang Anda inginkan, terpaksa menghabiskan waktu untuk mendapatkan kode kualitas yang merupakan apa yang Anda inginkan di tempat pertama, dan yang Anda tahu akan menghemat waktu karena setiap jam yang dihabiskan untuk menulis kode yang lebih baik adalah dua jam disimpan pada debugging (atau lebih).

Tanpa ulasan kode, Anda sendirian, jadi terserah Anda untuk mempertahankan kualitas kode yang tinggi. Solusi sederhana adalah meninjau setiap perubahan yang Anda buat sendiri dan memperbaiki hal-hal yang tidak memenuhi standar kualitas Anda.

Ini juga menghindari situasi yang mengerikan di mana ulasan kode mengarah ke bentrokan ego - situasi di mana programmer A akan menggunakan metode X, sedangkan B akan menggunakan metode Y, jadi jika A menulis kode ia menggunakan metode X, peninjau B bersikeras pada metode Y, jadi A menulis ulang kode menggunakan metode Y, sedangkan jika B telah menulis kode dan A meninjaunya, kebalikannya pasti akan terjadi.


0

Jika Anda seorang penganjur ulasan kode, saya khawatir tidak ada pengganti yang nyata. Kasus malang dan stereotip adalah tempat kerja yang tidak melakukan tinjauan kode karena (A) mereka tidak terbiasa dengan praktik, dan / atau (B) mereka tidak ingin mencurahkan waktu dan upaya untuk mendapatkan tinjauan kode sistem di tempat.

Pada dasarnya, untuk mendapatkan apa yang Anda inginkan di sini, Anda memerlukan perubahan budaya di tempat kerja - dan itu tidak pernah sederhana atau mudah. Jangan lupa bahwa meskipun tempat kerja Anda 100% diyakinkan bahwa ulasan kode sangat bagus dan mereka ingin mengadopsinya, sebenarnya beralih ke cara kerja yang baru masih akan membutuhkan investasi waktu, energi, dan produktivitas yang signifikan. Investasi ini harus membayar sendiri - tetapi Anda harus membeli untuk investasi, bukan hanya untuk hasilnya. Lihat video Roy Osherove "Unit Testing dan TDD - How To Make It Happen" - tantangan dalam mengadopsi ulasan kode sangat mirip dengan yang ada pada mengadopsi unit testing.

Sementara itu, lakukan apa yang Anda bisa untuk mendapatkan sebanyak yang Anda bisa:

  • Jika ada pengembang lain yang melihat nilai ulasan kode, coba tinjau satu sama lain, bahkan secara informal.
  • Jika Anda memiliki mentor atau pengembang yang bertanggung jawab atas pelatihan Anda, jelaskan kepadanya nilai yang Anda lihat dalam ulasan kode, dan tanyakan apakah mereka bersedia untuk meninjau kode Anda, setidaknya sesekali.
  • Beri tahu manajer Anda bahwa Anda ingin meninjau kode orang lain, karena itu akan membantu Anda memahami sistem dengan lebih baik.
  • Jika pada suatu saat Anda menjadi pemimpin tim, Anda dapat membuat ulasan kode secara lokal, hanya untuk tim Anda.

Manfaat utama dari semua ini adalah, jika Anda dapat mempertahankannya dari waktu ke waktu, maka pengembang di sekitar Anda akan mulai memperhatikan ulasan kode. Anda akan secara efektif menunjukkan bagaimana ulasan kode dapat diintegrasikan dalam budaya yang ada - dan itu membuka jalan bagi budaya untuk mulai berubah. Ulasan kode membantu , jadi jika Anda dapat menunjukkan itu dalam skala kecil, itu akan membuka jalan bagi orang lain - dan budaya secara keseluruhan - untuk mengikuti contoh Anda.


-2

Berhentilah mencemaskannya - perusahaan baru Anda tidak peduli dengan ulasan kode. Belajarlah untuk memiliki kepercayaan diri pada kemampuan Anda sendiri tanpa orang lain memberi tahu Anda bahwa tidak apa-apa untuk memeriksa kode yang Anda tulis. Anda akan segera belajar untuk hidup tanpa proses yang melelahkan pikiran yang mengkaji kode orang lain.

Ikuti pedoman gaya (atau hanya gaya) yang digunakan orang lain. Gunakan pengalaman Anda untuk memutuskan apa yang perlu dikomentari, konvensi penamaan apa yang akan digunakan dan sebagainya.

Kemudian uji semuanya sebelum Anda memeriksanya. Yang paling penting adalah itu berfungsi dengan benar.


2
-1: Fakta bahwa tim baru OP tidak melakukan review kode tidak membuatnya menjadi ide yang buruk untuk melakukannya. Ini adalah pertanda insinyur yang baik untuk membantu meningkatkan kualitas proses pengembangan.
Jørgen Fogh

1
@ JørgenFogh Saya juga mendukung ulasan kode, tetapi Anda tampaknya menganggap ulasan kode akan membantu proses pengembangan khusus ini. Selain jawaban ini, saya akan bertanya mengapa mereka tidak melakukan review kode - mereka mungkin memiliki alasan yang bagus. Mungkin, seperti yang disarankan oleh jawaban ini - perusahaan ini mempekerjakan orang yang tidak perlu melihat kode mereka, atau setidaknya manfaat dari melakukan hal itu tidak sebanding dengan biaya tambahan. Jika OP mencoba tetapi tidak memiliki keberuntungan mengubah apa pun, ini akan menjadi jawaban untuk kembali.
DoubleDouble

1
Mungkin saja manfaatnya tidak sepadan dengan biayanya. Namun, fakta bahwa tim tidak melakukan tinjauan kode tidak memberi tahu kita tentang apakah mereka seharusnya melakukannya atau tidak.
Jørgen Fogh

4
-1: "Yang paling penting adalah itu berfungsi dengan benar." Ini adalah pandangan singkat tentang apa yang penting dalam hal kode produksi. Kode dibaca lebih sering daripada yang tertulis. Nilai ulasan kode (berkinerja baik) jauh melampaui memeriksa kebenaran. Di antara banyak keuntungan, ulasan kode memastikan bahwa kode masuk akal bagi seseorang yang tidak menulisnya.
Dancrumb

-2

Jika atasan baru Anda tidak menyukai gagasan tinjauan kode, itu mungkin karena mereka memiliki hubungan negatif dengan metodologi tipe perintah dan kontrol kuno dan mereka mengincar praktik praktik yang lebih modern dan tangkas. Dalam hal ini, mereka mungkin lebih terbuka terhadap ide pemrograman pasangan, yang memberikan banyak manfaat yang sama, dan secara luas dianggap sebagai praktik modern yang lebih dinamis.

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.