Anda dan sebagian besar penjawab pendekatan ini sebagai masalah komunikasi antara dua rekan, tetapi saya tidak berpikir itu benar. Apa yang Anda gambarkan terdengar lebih seperti proses peninjauan kode yang rusak parah daripada yang lainnya.
Pertama, Anda menyebutkan bahwa kolega Anda adalah yang kedua dalam perintah dan diharapkan dia akan meninjau kode Anda. Itu salah. Menurut definisi, ulasan kode rekan tidak hierarkis, dan pastinya bukan hanya tentang menemukan cacat. Mereka juga dapat memberikan pengalaman belajar (untuk semua orang yang terlibat), kesempatan untuk interaksi sosial, dan membuktikan alat yang berharga untuk membangun kepemilikan kode kolektif. Anda juga harus meninjau kode-kodenya dari waktu ke waktu, belajar darinya dan memperbaikinya ketika dia salah (tidak ada yang memperbaikinya setiap waktu).
Selanjutnya, Anda menyebutkan bahwa kolega Anda segera melakukan perubahan. Itu juga salah, tetapi tentu saja Anda sudah mengetahuinya; Anda tidak akan menanyakan pertanyaan ini jika pendekatan gung ho-nya tidak menjadi masalah. Namun saya pikir Anda mencari solusi di tempat yang salah. Sejujurnya, kolega Anda mengingatkan saya sedikit ... saya, dan apa yang berhasil bagi saya dalam situasi yang sama adalah proses peninjauan yang jelas dan solid serta seperangkat alat yang luar biasa. Anda tidak benar-benar ingin menghentikan kolega Anda dari meninjau kode Anda, dan memintanya untuk berhenti dan berbicara kepada Anda sebelum setiap perubahan kecil tidak benar-benar bekerja. Mungkin untuk sementara waktu, tetapi dia akan segera mencapai titik di mana itu hanya akan terlalu mengganggu dan Anda akan kembali ke tempat Anda mulai, atau lebih buruk lagi: dia hanya akan berhenti meninjau kode Anda.
Kunci untuk resolusi di sini mungkin alat peninjau kode rekan. Saya biasanya menghindari rekomendasi produk, tetapi untuk ulasan kode Atlassian's Cruciblebenar-benar penyelamat. Apa yang dilakukannya mungkin tampak sangat sederhana, dan memang begitu, tetapi itu tidak berarti itu tidak luar biasa mengagumkan. Ini terhubung ke repositori Anda dan memberi Anda kesempatan untuk meninjau perubahan individu, file, atau grup file. Anda tidak dapat mengubah kode apa pun, sebaliknya Anda mengomentari segala sesuatu yang terasa tidak benar. Dan jika Anda benar-benar harus mengubah kode orang lain, Anda dapat meninggalkan komentar dengan perubahan yang menjelaskan perubahan Anda. Video pengantar di halaman produk Crucible layak ditonton jika Anda menginginkan detail lebih lanjut. Harga Crucible bukan untuk semua orang, tetapi ada banyak alat peer review yang tersedia secara bebas. Salah satu yang telah saya kerjakan dan nikmati adalah Review Board dan saya yakin Anda akan menemukan banyak orang lain dengan pencarian Google sederhana.
Alat apa pun yang Anda pilih, itu benar-benar akan mengubah proses Anda. Tidak perlu berhenti, turun dari kursi Anda, sela orang lain dan diskusikan perubahannya; yang perlu Anda lakukan adalah menetapkan waktu istirahat setiap minggu dan membaca komentar (seminggu sekali hanya saran. Anda tahu jadwal dan rutinitas harian Anda lebih baik daripada saya). Lebih penting lagi, ulasan inti disimpan dalam database di suatu tempat dan Anda dapat mengambilnya kapan saja. Mereka bukan diskusi singkat di sekitar pendingin air. Kasing penggunaan favorit saya untuk ulasan lama adalah ketika memperkenalkan anggota tim baru ke basis kode kami. Itu selalu menyenangkan ketika saya bisa memandu seseorang yang baru melalui basis kode menunjukkan di mana tepatnya kami terjebak, di mana kami memiliki pendapat yang berbeda, dll.
Selanjutnya, Anda menyebutkan bahwa Anda tidak selalu menemukan kode rekan ini dapat dibaca. Itu membuat saya tahu bahwa Anda tidak memiliki seperangkat standar pengkodean yang sama, dan itu hal yang buruk. Sekali lagi Anda dapat mendekati ini sebagai masalah orang atau Anda dapat mendekati ini sebagai masalah proses, dan sekali lagi saya akan sangat menyarankan yang terakhir. Kumpulkan tim Anda dan adopsi gaya koding umum dan serangkaian standar sesegera mungkin. Tidak masalah jika Anda memilih serangkaian standar yang umum dalam ekosistem pengembangan Anda atau Anda membuat standar Anda sendiri. Yang benar-benar penting adalah agar standar Anda konsisten dan Anda mematuhinya. Banyak dan banyak alat di luar sana dapat membantu Anda, tetapi itu adalah diskusi yang sangat berbeda. Hanya untuk memulai, hal yang sangat sederhana untuk dilakukan adalah memiliki hook pre-commit menjalankan semacam style formatter pada kode Anda. Anda dapat terus menulis kode sesuka Anda dan membiarkan alat "memperbaikinya" secara otomatis sebelum orang lain melihatnya.
Terakhir Anda menyebutkan dalam komentar bahwa manajemen tidak percaya cabang dev individu diperlukan. Nah, ada alasan kami menyebutnya "cabang-cabang dev" dan bukan "cabang-cabang manajemen." Aku akan berhenti di sini karena tidak ada alasan untuk kata-kata kasar yang terbentuk di kepalaku keluar.
Semua yang mengatakan, tahu bahwa saya tidak meragukan kolega Anda (sedikit) salah di sini. Itu bukan poin saya, poin saya adalah bahwa seluruh proses pengembangan Anda juga salah, dan itu adalah sesuatu yang lebih mudah untuk diperbaiki. Persenjatai diri Anda dengan alat yang tepat, jelajahi berbagai proses formal dan informal dan pilih yang sesuai dengan tim Anda. Segera Anda akan mencapai titik di mana Anda akan menyadari bahwa sebagian besar "masalah orang" Anda tidak ada lagi. Dan tolong jangan dengarkan siapa pun (termasuk Anda sendiri) yang mengemukakan alasan "kami tim kecil, kami tidak membutuhkan semua itu". Tim pengembang yang kompeten dapat mengatur alat yang diperlukan dalam waktu kurang dari seminggu, mengotomatiskan semua yang dapat diotomatisasi, dan tidak pernah melihat ke belakang lagi.
PS. "Kepemilikan kode" adalah istilah yang samar-samar, terus-menerus diperdebatkan, dan ini memiliki arti berbeda bagi orang yang berbeda. Anda dapat menemukan koleksi cemerlang dari sebagian besar pendapat yang berbeda (dan terkadang antitesis) tentang C2 .