Apa itu proses peninjauan kode umum dan apa yang dianggap buruk?

Perusahaan saya baru-baru ini mulai melakukan tinjauan kode formal. Prosesnya seperti ini: Anda mengirimkan ke github, meminta permintaan tarik, kode ditinjau oleh sekitar tiga orang, lalu jika semua lewat, kode Anda masuk.

Prosesnya tampak adil, namun tiga orang yang melakukan tinjauan kode tampaknya tidak adil. Saya perhatikan bahwa ketika saya memasukkan kode saya untuk ditinjau, saya mendapatkan antara 100-200 komentar. Jumlah teratas untuk saya adalah 300 komentar sekali. Tentu saja Anda akan berpikir itu adalah perubahan besar, tetapi ini bisa menjadi perubahan yang sangat kecil juga dengan kurang dari 50 baris kode (yang termasuk tes unit). Semua komentar dianggap "harus dilakukan" dan tanpa argumen.

Dengan pemikiran itu, masalah utama saya di sini adalah tampaknya agak berlebihan. Saya berbicara dengan grup dan pada dasarnya mereka mengatakan kepada saya bahwa hanya karena saya memiliki bertahun-tahun pengembangan di php tidak berarti saya seorang "pengembang." Tentu saja ini tampaknya lebih menyakitkan daripada tidak. Saya juga memperhatikan bahwa di dalam grup, mereka tampaknya tidak menghasilkan banyak komentar dan sebagian besar waktu mereka mengabaikan atau mengabaikan komentar atau saran lain jarang menerimanya sebagai poin yang valid bahkan jika ada sesuatu yang rusak.

Jadi pertanyaan saya adalah apakah ini adil? Atau biasa?

Semua komentar dianggap "harus dilakukan" dan tanpa argumen.

IMHO itulah masalah sebenarnya, karena tidak ada prioritas dalam hal itu. Ketika Anda mendapatkan 100-300 komentar, pasti ada beberapa di antaranya yang memiliki prioritas A (bug nyata), beberapa di antaranya prio B (kemungkinan akan mengarah ke bug nanti) dan beberapa di antaranya prio C (semuanya). Beri tahu kolega Anda bahwa Anda bersedia untuk menghormati semua keinginan mereka, tetapi untuk membuat perubahan efektif, dan waktu Anda terbatas, bersikeras pada prioritas. Kemudian, mulailah dengan memperbaiki prio A komentar terlebih dahulu, dan jika Anda benar-benar punya waktu untuk lebih setelah itu, Anda dapat mulai dengan B (jika Anda beruntung, bos Anda akan mengerti bahwa memperbaiki prio B dan C tidak begitu penting, dan memberi Anda beberapa tugas yang lebih penting daripada membuang-buang waktu Anda).

Ulasan kode dapat menjadi proses yang memecah belah.

Anda berada di persimpangan yang penting. Lakukan analisis bijaksana pada ulasan mereka. Apakah mereka mengidentifikasi masalah memilih, atau menyoroti kelemahan serius dalam gaya dan logika Anda?

Jika yang pertama, saya sarankan bekerja menuju resolusi (pekerjaan baru, atau proses peninjauan kode baru).

Jika ini yang terakhir, saya sarankan melakukan banyak membaca kode dan belajar untuk mencoba membawa kode Anda ke kualitas profesional.

Tampaknya oleh komentar Anda bahwa kolega Anda menggunakan proses peninjauan kode untuk menyetujui metodologi atau memoles kode. Saya baru saja mulai melakukan tinjauan kode seperti Anda dan saya perhatikan bahwa kadang-kadang kita membahas banyak hal yang hanya pendekatan atau peningkatan implementasi. Ini tidak buruk sama sekali sejauh yang wajar (300 komentar terlihat terlalu banyak bagi saya, yang harus terlihat seperti utas reddit)

Mungkin Anda perlu menyetujui beberapa keputusan arsitektur tentang kode sebelum mulai menerapkannya atau mungkin hanya setuju tentang penamaan konvensi, pola dan praktik yang baik sehingga Anda semua tahu apa yang dianggap "kode yang baik".

Jika Anda mematuhi standar kode Anda seperti yang Anda katakan dan kode berfungsi sebagaimana mestinya, seharusnya tidak ada begitu banyak komentar, sehingga mereka menggunakan kode Anda sebagai forum atau mereka mengolok-olok Anda karena tampaknya Anda menunjuk.

Saya akan mencoba untuk menjadi kritikus dengan diri saya sendiri, akan mencoba untuk mengambil bagian dalam percakapan dan melihat alasan semua komentar ini dan mungkin berbicara dengan mereka tentang hal itu dengan cara yang konstruktif untuk melihat mengapa mereka begitu tidak senang dengan kode Anda dan jika Anda dapat kode dengan cara yang membuat semua orang senang dan pekerjaan tidak terjebak dalam ulasan kode.

Saya baru saja membaca komentar terakhir Anda, kadang-kadang ketika Anda tidak setuju dengan kode Anda dapat memeriksanya seratus kali dan mengusulkan perubahan di mana-mana yang tidak membuat Anda bahagia karena alasan sebenarnya bahwa Anda akan melakukan keputusan arsitektur yang berbeda dan Anda tidak suka kode itu, tidak peduli berapa kali Anda membuatnya ulang. Seperti yang saya katakan di atas, mungkin Anda harus menyetujui pendekatan kode sebelumnya sehingga ketika Anda menulisnya Anda tahu apa yang mereka harapkan darinya dan karena itu kode Anda akan lebih masuk akal bagi mereka.

Dari apa yang Anda katakan, menurut saya mereka mungkin memiliki bias terhadap pengembang php, dan dengan demikian mereka mencoba untuk menemukan setiap hal yang salah dengan kode Anda untuk membuktikan pendapat mereka.

Mengenai review kode itu sendiri, saya percaya seperti yang Anda katakan sudah, bahwa sejumlah besar komentar kecil kurang membantu daripada beberapa kritik yang baik dan valid. Dan meskipun saya memiliki pengalaman terbatas sehubungan dengan ulasan kode, teknik berikut ini telah bekerja dengan baik untuk tim tempat saya bekerja sebelumnya.

• Pertama-tama, penganalisa kode statis harus digunakan untuk mengidentifikasi sebagian besar masalah sebelum peninjauan kode dilakukan. Misalnya: menjalankan kode Anda melalui Sonar, Lint atau penganalisa kode yang baik lainnya akan membantu Anda untuk menyingkirkan sebagian besar masalah kecil. Terutama karena pengulas Anda dapat menentukan profil khusus untuk memastikan semuanya mulai dari penempatan braket, spasi putih, komentar, penamaan variabel yang tepat, dan banyak lagi ...
• Kedua, saya tampaknya bekerja dengan baik jika Anda membagi komentar ke dalam kategori yang berbeda. Misalnya dua kategori di mana satu grup menyertakan hal-hal kecil yang harus Anda perhatikan dan terapkan di masa depan. Dan grup kedua untuk komentar-komentar itu yang memerlukan modifikasi segera dari kode Anda yang akan membutuhkan komit lain dan ulasan selanjutnya. Tentu saja, jumlah komentar di grup terakhir harus lebih kecil.

Selain itu, saya harus mengatakan bahwa ulasan kode nyata pertama saya juga berisi lebih banyak komentar daripada yang saya harapkan. Namun saya tidak pernah menganggap ini sebagai hal yang buruk. Jika Anda terus belajar dari komentar mereka² dan bersedia menerapkan teknik-teknik baru yang dipelajari / praktik terbaik dalam pengiriman kode Anda di masa mendatang, komentar-komentar tersebut akan menjadi kurang. Itu memang benar bagi saya ;-)

¹ Dalam pengalaman saya, ini sering terjadi karena banyak programmer mengklaim bahwa php adalah bahasa pemrograman yang paling jahat, dengan menggunakan programmer yang paling tidak berpengalaman menggunakannya. Saya menjauhkan diri dari pernyataan ini karena saya percaya bahwa perangkat lunak yang hebat dapat ditulis dalam bahasa apa pun!

² Dengan asumsi bahwa meskipun komentarnya berlebihan, ada beberapa nilai di dalamnya

Apakah umum bagi siapa saja untuk mendapatkan 100+ komentar dalam ulasan kode mereka secara rutin? Saya akan mengatakan tidak. Apakah biasa bagi orang yang kualitas kodenya "meninggalkan banyak yang diinginkan" untuk mendapatkan banyak komentar, tentu saja.

Namun, itu juga tergantung pada "aturan" dari proses peninjauan kode. SEMUA ORANG memiliki ide mereka sendiri tentang bagaimana sesuatu seharusnya dilakukan. Jika proses peninjauan kode Anda memungkinkan komentar berbentuk "Anda harus melakukannya dengan cara ini, bukan seperti itu", maka Anda kemungkinan akan mendapatkan BANYAK komentar bahkan untuk kode yang memadai. Jika proses Anda dimaksudkan untuk menemukan "cacat" maka jumlah komentar harus jauh lebih kecil.

Dalam pengalaman saya, ulasan yang memungkinkan "saran" untuk metode alternatif adalah pemborosan waktu. "Saran" itu harus ditangani satu lawan satu di luar proses peninjauan. Ulasan yang cacat lebih bermanfaat karena membuat orang berfokus pada bug daripada "mengapa Anda tidak melakukannya seperti yang saya lakukan?". Ini juga lebih bermanfaat karena tidak dapat disangkal bug jika seseorang menemukannya. Dengan demikian, tidak ada perasaan terluka, tetapi kemungkinan besar rasa terima kasih sebagai gantinya.

PEMBARUAN: Dengan semua yang dikatakan, beberapa kode benar-benar buruk, meskipun cacat gratis. Dalam hal itu, komentar ulasan harus berupa komentar tunggal yang mengatakan sesuatu seperti. "Kode ini perlu dibersihkan. Silakan tunda ulasan sampai kode dibahas dengan [nama Anda di sini]." Dalam hal ini, peninjauan kode lebih lanjut harus berhenti sampai komentar diperbaiki.

UPDATE2: @ Pengguna: Apakah Anda mendiskusikan kode / desain Anda dengan salah satu dari mereka saat Anda sedang mengembangkannya sehingga Anda dapat mengimplementasikan apa yang mereka cari sebelum Anda melakukannya dengan cara Anda? Apakah Anda mengubah sesuatu tentang bagaimana Anda mengembangkan kode berdasarkan saran mereka atau tetap berpikir cara Anda baik-baik saja? Apakah Anda belajar sesuatu dari komentar mereka?

Ketika saya memimpin proyek, itu adalah tugas saya untuk bertanggung jawab atas SEMUA produk kerja. Jika saya menyetujui produk kerja maka saya mengklaim produk tersebut dapat diterima. Saya ingin memiliki reputasi untuk membangun produk yang berkualitas. Jadi, saya memiliki harapan dan tidak akan menerima kurang memuaskan. Pada saat yang sama saya mencoba mengajar dan menjelaskan alasan preferensi saya. Preferensi-preferensi itu mungkin tidak selalu ideal (terutama di mata orang lain), tetapi sebagian besar preferensi itu berasal dari pengalaman. Biasanya merupakan reaksi untuk menghindari pengulangan yang buruk. Jadi, ada beberapa "stickler" pribadi saya yang diperlukan untuk mendapatkan persetujuan saya, terlepas dari pushback.

Di sisi lain, Anda perlu mempelajari harapan yang diperlukan untuk mendapatkan produk kerja Anda disetujui. Anda dapat tidak setuju, tetapi karena Anda tampaknya tidak memiliki wewenang untuk memerintah maka pelajari apa yang diharapkan. Saya ragu bahwa tim berusaha membuat Anda gagal. Karena itu membuat mereka terlihat buruk juga. Dalam hal itu, cukup tunjukkan bahwa Anda ingin belajar (bahkan jika tidak), ambil apa yang mereka katakan dan lakukan yang terbaik untuk beradaptasi dengan preferensi mereka dan Anda mungkin akan melihat mereka mundur sedikit. Mungkin temukan yang paling tidak bisa Anda toleransi dan lihat apakah mereka akan melakukan sedikit pegangan tangan untuk mengajari Anda cara mereka. Siapa tahu, dalam prosesnya Anda bisa belajar sesuatu yang benar-benar bisa membawa keterampilan Anda ke tingkat selanjutnya.

Beberapa perbedaan penting dengan proses inspeksi tim kami:

• dasar inspeksi adalah daftar periksa, yang disusun oleh seluruh tim.
• Fokus adalah cacat (sekarang dan masa depan), bukan gaya demi gaya.
• 3 inspektur (termasuk penulis) duduk bersama untuk membahas komentar. Hanya komentar dengan suara mayoritas yang tersisa.

Untuk 50 LOC 300 komentar tampaknya agak berlebihan dan - wow - 3 pengulas untuk setiap permintaan tarik? Perusahaan Anda harus memiliki banyak sumber daya.

Dari pengalaman saya untuk proses peninjauan kode yang berguna harus ada beberapa aturan dan / atau pedoman:

• Prioritas komentar
• Klasifikasi komentar (Bug, Gaya Kode, dll.)
• Arsitektur / desain yang disepakati untuk diikuti
• Gaya kode yang disetujui

Jika Anda tidak mendapatkan prioritas dari pengulas, tanyakan manajer proyek / pemimpin tim Anda yang bertanggung jawab; penanggung jawab biaya harus memiliki pendapat tentang prioritas.

Jika Anda memiliki arsitektur yang ditentukan, pemahaman umum apa pola desain yang Anda gunakan dalam proyek Anda dan gaya kode yang disepakati, maka komentar ulasan harus hanya tentang "masalah nyata" seperti masalah keamanan, bug yang tidak disengaja, kasus sudut tidak tercakup oleh yang ditentukan arsitektur, dll.

Jika tim pengembangan Anda belum menyetujui "masalah rasa" (misalnya variabel anggota harus dimulai dengan "m_"), maka setiap pengulas akan memaksa Anda untuk mengikuti gayanya, yang hanya membuang-buang waktu / uang.

Bagi saya ini benar-benar seperti masalah komunikasi. Anda memiliki harapan bahwa kode Anda tidak cukup buruk untuk mendapatkan 300 komentar. Para pengulas sepertinya berpikir Anda membutuhkan banyak umpan balik. Berdebat bolak-balik dengan cara asinkron akan menghabiskan banyak waktu. Heck, menulis 300 komentar adalah buang-buang waktu yang luar biasa. Jika ini tidak semuanya cacat maka mungkin sebagai anggota tim baru Anda belum tahu gaya tim. Itu normal dan sesuatu yang harus dipelajari untuk mempercepat seluruh tim.

Saran saya adalah menghemat waktu. Percepat umpan balik. Saya akan:

• Lakukan lebih banyak ulasan sementara untuk menghindari kesalahan yang sama dan hasilkan komentar yang sama sebanyak 50 kali
• Duduklah dengan pengulas saat mereka meninjau kode Anda sehingga Anda dapat berbicara tentang masalah yang muncul, sehingga menghindari mendokumentasikan 300 "masalah" yang akan dihapus di komit berikutnya
• Pasangkan dengan salah satu pengembang "nyata" ini selama beberapa waktu ketika Anda menulis kode untuk melihat apa yang akan mereka lakukan secara berbeda

Orang mungkin berdebat menentang pasangan karena "itu akan memakan waktu lebih lama" tapi itu jelas bukan masalah di sini.