Haruskah saya bersikeras bahwa kami melakukan tinjauan kode sebelum bergabung kembali ke trunk?

Diposting ulang pos dari StackOverflow:

Saya bekerja dalam waktu pengembangan kecil dengan waktu pengembangan yang sangat terbatas. Kami mengembangkan alat yang penting untuk hasil pekerjaan kami, tetapi tidak digunakan setiap hari. Saya satu-satunya orang di tim yang memiliki latar belakang sebagai programmer.

Masalah saya adalah bahwa saya telah mendorong ulasan kode sebelum bergabung kembali ke trunk selama lebih dari setahun. Semua orang sepakat tentang ini, tetapi tetap saja hanya kode saya yang telah ditinjau. Kembali dari liburan panjang saya kembali ke bagasi dengan komentar kode karena "ini adalah solusi yang jelek - hapus sesegera mungkin" dan "perbaikan cepat". Yang juga baru adalah bahwa seorang pria telah ditunjuk untuk bertanggung jawab atas alat tersebut. (Peran yang pertama kali ditawarkan kepada saya tetapi saya menolak karena alasan yang tidak terkait dengan pekerjaan.) Dan dia berpikir bahwa ini adalah cara yang baik untuk bekerja: Karena kita memiliki waktu yang terbatas untuk berkembang, kita harus mengambil jalan pintas seperti itu.

Kekhawatiran saya adalah bahwa pengembang lain menulis kode jelek: sering melanggar enkapsulasi, menulis kelas besar, menambahkan kelas internal di tempat-tempat aneh, memiliki beberapa atau tidak ada unit test, dan sebagainya. Pada akhirnya tidak mungkin untuk mengembangkan alat lebih lanjut.

Haruskah saya bersikeras bahwa kami melakukan tinjauan kode sebelum bergabung kembali ke trunk atau apakah saya hanya pelacur kualitas kode?

Saya pernah dalam situasi yang sama sebelumnya dan imho itu tergantung pada "apakah saya harus menjaga kode".

Jika saya harus mempertahankan kode, daripada yang saya inginkan kode berkualitas tinggi, saya pribadi tidak memerlukan ulasan kode untuk setiap komit (mis. Programmer dapat memutuskan sendiri apakah kode tertentu perlu ditinjau atau tidak) tetapi jika keterbacaan / pemeliharaan lebih buruk daripada mungkin dalam urutan.

Saat membaca ini:

Kekhawatiran saya adalah bahwa pengembang lain menulis kode jelek: sering melanggar enkapsulasi, menulis kelas besar, menambahkan kelas internal di tempat-tempat aneh, memiliki beberapa atau tidak ada unit test, dan sebagainya. Pada akhirnya tidak mungkin untuk mengembangkan alat lebih lanjut.

Saya pikir masalah Anda lebih besar dari sekadar ulasan kode. Anda sepertinya kehilangan beberapa pedoman dan / atau tidak diimplementasikan. Tidak memiliki / beberapa tes unit mungkin merupakan ide yang buruk tetapi tergantung pada kasus tertentu. Namun, breaking encapsulation, writing huge classes, ...benar-benar membuat kode rawan bug sehingga harus diperbaiki.

Saya pikir ulasan kode dan mempertahankan beberapa pedoman pengkodean adalah ide yang bagus, tapi saya pikir melakukan itu untuk setiap check in adalah buang-buang waktu. Ini adalah ide yang baik ketika membentuk sebuah tim dan dengan programmer muda, tetapi programmer yang berpengalaman dapat berpikir untuk diri mereka sendiri dan akhirnya Anda harus mempercayai mereka. Yang mengatakan - Anda dapat melakukan review kode periodik untuk hal baru, tetapi melihat setiap baris kode yang memasuki VCS Anda benar-benar berlebihan.

Dan komentar kecil tentang perbaikan kolega Anda - beberapa kali membuat perbaikan jelek adalah solusi yang tepat . Mungkin kode khusus ini tidak cukup penting untuk menginvestasikan banyak waktu, mungkin solusi sederhana cukup baik dan lebih baik menginvestasikan waktu dalam hal-hal lain. Membuat kode Anda "cantik" bukanlah tujuan utama Anda sebagai seorang programmer. Tujuan utama Anda adalah memberikan dan terobsesi pada setiap baris kode tidak akan membuat Anda sampai di sana.

Yang ingin saya katakan adalah - Anda harus memilih pertempuran Anda. Tidak apa-apa untuk kehilangan pertempuran atas beberapa kelas utilitas yang tidak signifikan untuk memenangkan perang pengiriman (atau perang subsistem yang SANGAT PENTING ini, dalam hal ini).

Jika program tersebut bukan prototipe sekali pakai, saya pikir ulasan kode harus wajib untuk setiap check-in.

Pengembang senior dapat memiliki hak istimewa untuk check-in yang tidak ditinjau, begitu mereka diketahui cukup teliti untuk meminta peninjauan jika perlu.

Tidak yakin ulasan kode adalah jawabannya sampai seseorang mulai menerapkan standar pengkodean yang lebih baik. Seseorang menulis kode jelek, berkomentar / mengakuinya dan memeriksanya. Apa gunanya review akan dilakukan jika seseorang ingin menolak kode tersebut, tetapi itu akan membuat Anda terlambat?

Anda akan perlu: menetapkan standar, mengawasi lebih lanjut penyebab utama, dan menumbuk ke kepala mereka bahwa kode yang baik tidak selalu membutuhkan lebih banyak waktu untuk menulis. Mereka harus berhenti menggunakan garis waktu sebagai alasan untuk menolak mengubah kebiasaan buruk.