Siapa yang harus melakukan tinjauan kode?


12

Di perusahaan saya kebanyakan arsitek melakukan review kode. Dia adalah orang yang sangat berpengalaman dan perangkat lunak yang cerdas, jadi dia sangat pandai dalam hal itu. Ketika pengembang melakukan review kode mereka tidak melakukannya setengah juga. Kami mencoba memberi pengembang untuk melakukan lebih banyak ulasan kode, tetapi kualitas ulasan kode itu tidak bagus. Kami menggunakan Scrum sebagai metodologi pengembangan.

Namun dengan sistem saat ini ada dua masalah:

  1. Arsitek menjadi hambatan

  2. Pengembang tidak bertanggung jawab atas kualitas kode dan arsitektur (yang mengarah ke semua jenis masalah).

Bagaimana kita bisa mengatasi masalah ini? Haruskah kita mengubah siapa yang ditinjau kode?



1
Saya tidak melihatnya sebagai duplikat. Pertanyaan-pertanyaan terkait, tetapi kemungkinan duplikat berfokus pada masalah yang sedikit berbeda.
Bart van Ingen Schenau

Bisakah Anda memperluas apa yang Anda maksud dengan 'kualitas ulasan kode'? Apakah maksud Anda kualitas kode yang muncul di akhir ulasan? Bagi saya sepertinya Anda hanya memiliki satu pengembang yang dapat menghasilkan kode dengan kualitas yang dapat diterima, dalam hal ini saya akan mengatakan Anda memiliki masalah lebih besar ...
AakashM

Jawaban:


15

Pengembang harus melakukan tinjauan kode. Mereka harus melakukan tinjauan kode, karena mereka harus mengetahui kode, standar gaya perusahaan dan praktiknya. Dengan meminta orang lain melakukan tinjauan kode, Anda memberi tahu pengembang Anda bahwa bukan tanggung jawab mereka untuk memastikan kode tersebut memenuhi standar perusahaan.

Jika Anda merasa mereka perlu pelatihan untuk melakukan tinjauan kode, dapatkan untuk mereka. Mengingat situasi Anda saat ini, Anda dapat meminta dev melakukan review kode, dan kemudian meminta komentar dari arsitek Anda - mintalah dev mengirimkan review ke arsitek untuk disetujui sebelum mengirimkannya ke submitter.


2
" Dengan meminta orang lain melakukan tinjauan kode, Anda memberi tahu pengembang Anda bahwa bukan tanggung jawab mereka untuk memastikan kode tersebut memenuhi standar perusahaan. " - ya dan tidak. Anda juga mengatakan "Kode Anda tunduk (mudah-mudahan) kritis rekan review, sehingga Anda lebih baik melakukannya dengan benar pertama kalinya."
JensG

@JensG: tapi bukan rekan yang melakukan review dalam situasi OP.
jmoreno

3
Itu sebabnya saya membuatnya berani.
JensG

8

Dalam situasi ini, yang Anda butuhkan adalah pengetahuan pengembang yang berpengalaman ini untuk membantu anggota tim lainnya tumbuh. Kualitas tim tidak ditentukan oleh keterampilan pengembang terbaik; itu ditentukan oleh keterampilan yang terburuk. Anda dapat mencoba hal-hal seperti:

  • Ulasan kolaboratif. Ini bekerja sangat bagus di tim terakhir saya. Kami menempatkan seluruh tim di sebuah ruangan dengan proyektor dan mulai meninjau beberapa item. Mungkin pada awalnya arsitek adalah orang yang memandu tinjauan, tetapi dalam beberapa minggu (kami memesan satu atau dua jam setiap hari Jumat) seluruh tim mulai berbicara dan memahami konsep-konsep kunci yang saat ini hanya diketahui oleh arsitek.

  • Memasangkan pemrograman. Bagi saya ini adalah alat terbaik untuk menyebarkan pengetahuan dalam tim.


+1 untuk pemrograman pasangan. Sebenarnya, pertanyaan pertama saya pada pertanyaan itu adalah "semua orang", tetapi memasangkan pemrograman membuatnya lebih baik. Saya pikir kita mendapatkan yang terbaik dari itu jika kita menjadikannya sumber pembelajaran di samping aspek kualitas.
JensG

3

Sementara saya dapat melihat titik di mana arsitek sistem / perangkat lunak menandatangani semua perubahan / komitmen, pengembang perangkat lunak harus dapat melakukan tinjauan tanpa melibatkan arsitek - kecuali untuk arbitrasi.

Prosedur tinjauan [*] yang saya sukai adalah:

  • Grup berubah berdasarkan persyaratan / masalah.
  • Undang semua pengembang, arsitek perangkat lunak, dan penulis persyaratan / masalah untuk meninjau. (Mereka tidak semua diminta untuk melakukan peninjauan.)
  • Pertimbangkan review yang selesai saat:
    • Dua pengembang telah meninjau.
    • Semua komentar ditanggapi. (Mungkin dengan membuat arsitek perangkat lunak membuat keputusan.)
    • Satu hari kerja telah berlalu tanpa diskusi lebih lanjut (atau semua pihak yang diundang telah meninjau).

Jadi jawaban singkat saya untuk pertanyaan Anda adalah: Pengembang harus melakukan perubahan ulasan.

[*] Sayangnya ini tidak selalu bagaimana proyek yang saya ikuti beroperasi.


sekarang selalu, atau tidak selalu?
Martijn

Seperti yang mungkin sudah Anda duga: "tidak selalu". Terima kasih telah melihatnya. Saya sudah mengoreksi jawabannya.
Jacob Sparre Andersen

3

Saya suka praktik ulasan kode tim sesekali yang mencakup seluruh tim arsitek, tetapi kemudian banyak dan banyak dan banyak ulasan kode antara dua atau tiga anggota tim.

Jika itu kode yang benar-benar rumit atau sensitif, maka mintalah arsitek atau anggota senior tim.

Jujur saja, kedengarannya agak konyol memiliki arsitek yang melakukan review kode. Dia harus melakukan tinjauan desain, atau tinjauan kode sesekali secara informal untuk berbagi keahliannya. Tim teknik harus bertanggung jawab atas kode tersebut. Jika ada masalah, maka mereka akan menjadi lebih baik seiring waktu.


2

Saya setuju, jika hanya satu orang yang memberikan ulasan, orang-orang yang lain mungkin hanya akan pergi dengan "Saya tidak tahu, sepertinya berhasil, tapi biarkan orang pintar itu mencari tahu apakah itu boleh atau tidak". Saya dapat memikirkan hal-hal berikut:

  • buat kode Anda publik sehingga semua orang dapat melihat apa yang sedang dikerjakan semua orang; tuliskan nama di awal setiap file yang berisi kode; mungkin mencetaknya dan mencapnya di kamar mandi, uhh, atau di mana pun Anda merasa itu akan menarik perhatian
  • pemrograman pasangan; dengan otak lain di samping Anda, Anda akan berpikir dua kali sebelum memberi nama variabel Andai
  • Ambil petugas kebersihan Anda dan jelaskan kepadanya bagaimana warisan itu bekerja (oh, ya, itu tidak berhasil). Menjelaskan kode Anda kepada orang lain membantu. Mungkin itu mengkompilasi, mungkin itu melakukan hal yang benar, tetapi Anda tidak benar-benar mengerti mengapa. Sekarang adalah kesempatanmu
  • memiliki seperangkat pedoman dan membuat semua orang mengikuti mereka; apa pun pedomannya, lebih baik daripada tidak ada pedoman
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.