Bagaimana saya bertanggung jawab atas kode saya ketika kolega melakukan perbaikan yang tidak perlu tanpa pemberitahuan?


71

Salah satu rekan tim saya adalah jack dari semua perdagangan di toko IT kami dan saya menghargai wawasannya.

Namun, kadang-kadang dia meninjau kode saya (dia yang kedua di komando untuk pemimpin tim kami, jadi itu diharapkan) tanpa kepala. Jadi kadang-kadang dia meninjau perubahan saya sebelum mereka menyelesaikan tujuan akhir dan membuat perubahan segera ... dan bahkan pernah merusak pekerjaan saya.

Di lain waktu, dia telah melakukan perbaikan yang tidak perlu pada beberapa kode saya yang berumur 3+ bulan.

Ini mengganggu saya karena beberapa alasan:

  1. Saya tidak selalu diberi kesempatan untuk memperbaiki kesalahan saya
  2. Dia belum meluangkan waktu untuk bertanya kepada saya apa yang saya coba capai ketika dia bingung, yang dapat mempengaruhi pengujian atau perubahannya
  3. Saya tidak selalu berpikir bahwa kodenya dapat dibaca
  4. Tenggat waktu bukan merupakan masalah dan beban kerjanya saat ini tidak memerlukan pekerjaan apa pun di proyek saya selain meninjau perubahan kode saya.

Ngomong-ngomong, saya telah mengatakan kepadanya di masa lalu untuk tetap membuat saya diposting jika dia melihat sesuatu dalam pekerjaan saya yang dia ingin ubah sehingga saya dapat mengambil kepemilikan kode saya (mungkin saya seharusnya mengatakan "kekurangan") dan dia tidak responsif .

Saya takut bahwa saya akan menjadi agresif ketika saya memintanya untuk menjelaskan perubahannya kepada saya.

Dia hanya orang pendiam yang menjaga dirinya sendiri, tetapi tindakannya terus berlanjut. Saya tidak ingin mengusirnya dari membuat perubahan kode (tidak seperti yang saya bisa), karena kami adalah tim - tetapi saya ingin melakukan bagian saya untuk membantu tim kami.

Klarifikasi tambahan:

  • Kami berbagi 1 cabang pengembangan. Saya tidak menunggu sampai semua perubahan saya menyelesaikan satu tugas karena saya berisiko kehilangan pekerjaan yang signifikan - jadi saya memastikan perubahan saya membangun dan tidak merusak apa pun.
  • Kekhawatiran saya adalah bahwa rekan satu tim saya tidak menjelaskan alasan atau tujuan di balik perubahannya. Saya tidak berpikir dia harus membutuhkan berkah saya, tetapi jika kita tidak setuju pada suatu pendekatan saya pikir akan lebih baik untuk membahas pro dan kontra dan membuat keputusan setelah kita berdua mengerti apa yang sedang terjadi.
  • Saya belum membahas hal ini dengan pimpinan tim kami karena saya lebih suka menyelesaikan perselisihan pribadi tanpa melibatkan manajemen kecuali jika diperlukan. Karena kekhawatiran saya tampaknya lebih merupakan masalah pribadi daripada ancaman bagi pekerjaan kami, saya memilih untuk tidak mengganggu pemimpin tim. Saya sedang mengerjakan ide proses peninjauan kode - untuk membantu mempromosikan manfaat dari tinjauan kode yang lebih terorganisir tanpa membuat semuanya tentang kencing hewan peliharaan saya.

20
Apakah Anda menggunakan git, CVS, atau TFS untuk repo kode Anda? Putar kembali komitmennya. Dia akan mendapatkannya pada akhirnya :)

6
Dalam org saya, semua perubahan kode seharusnya melalui semacam review, dan dianggap sebagai bentuk yang buruk untuk memeriksa perubahan tanpa mencatat dalam deskripsi daftar perubahan siapa peninjau itu. Memperkenalkan prinsip itu dalam organisasi Anda mungkin merupakan solusi jangka panjang untuk masalah rekan kerja yang memeriksa perubahan kode yang Anda tulis tanpa ulasan.
Carolyn

13
Mengapa Anda memiliki perubahan yang belum selesai di cabang bersama? Itu ide yang buruk, dan bukan hanya karena alasan yang Anda temui.
hyde

15
Tentu saja ini tergantung pada VCS apa yang Anda gunakan, tetapi itu mungkin sesuatu yang perlu diperhatikan, mulai menggunakan cabang lebih banyak. Dengan cabang pribadi, ini adalah IMO yang hebat ketika Anda dapat melakukan (dan mendorong dengan DVCS) kapan pun Anda mau tanpa khawatir, dan bergabung hanya ketika dilakukan dengan bagian, atau menggabungkan hanya sebagian jika diperlukan (DVCS yang baik membuat ini sangat mudah). Juga berfungsi baik dengan ulasan kode, mampu melakukannya secara alami dan memperbaiki masalah sebelum bergabung.
hyde

4
@ Jesslyn - Apakah pemimpin tim Anda sama sekali khawatir bahwa rekan setim Anda menghabiskan waktu untuk melakukan perbaikan yang tidak perlu pada kode lama? Setidaknya, tampaknya tidak efisien bagi rekan setim Anda untuk menghabiskan waktu membuat perubahan yang tidak perlu sebagai lawan dari mengerjakan tugas dengan prioritas lebih tinggi. Selain itu, jika teman satu tim Anda lebih suka menghabiskan waktu "memperbaiki" kode Anda untuk Anda daripada memberdayakan Anda untuk melakukannya sendiri, itu tampaknya juga tidak efisien. Sudahkah Anda mendiskusikan salah satu dari keprihatinan ini dengan pimpinan tim Anda?
Tebing

Jawaban:


81

Saya pikir sebagian besar pengembang menemukan diri mereka dalam posisi ini di beberapa titik, dan saya berharap setiap pengembang yang merasa menjadi korban menyadari betapa frustrasinya ketika dia menjadi senior dan merasa terdorong untuk membersihkan kode yang ditulis oleh junior.

Bagi saya, menghindari konflik dalam situasi ini bermuara pada dua hal:

  1. Kesopanan . Berbicara dengan seseorang tentang kode-nya memungkinkan seorang dev mengetahui bahwa Anda tertarik dan Anda dapat mendiskusikannya sebagai profesional dewasa.

  2. Lupakan "kepemilikan kode" - tim memiliki kode . Orang lain yang ingin melakukan perubahan adalah hal yang baik. Jika seorang pengembang senior membuat perubahan yang "tidak dapat dibaca" atau lebih buruk, maka mundurlah. Anda tidak perlu agresif, cukup beri tahu editor bahwa perubahannya tidak berhasil, dan Anda senang mendiskusikan pengembalian Anda.

Ingat, kepemilikan kode oleh tim sangat bagus dan memotong kedua-duanya. Jika Anda melihat sesuatu yang tidak masuk akal dalam kode orang lain, maka perbaiki. Menjadi terlalu posesif dan kurang komunikatif adalah cara yang pasti untuk menciptakan lingkungan pengembangan yang beracun.


4
Saya pikir itu sampai ke Poin 1 - berdiskusi dengannya. Menghitung fakta bahwa perubahan kode terhadap pengembang asli adalah manajemen yang buruk (saya tidak mengatakan itu tidak terjadi) dan saya berpendapat Anda perlu mengajukan petisi untuk metrik yang lebih baik. Seberangi jembatan itu jika dan ketika itu terjadi.
Michael

2
Saya pikir itulah yang harus kita semua fokuskan - secara umum, rekan tim Anda tidak membuat Anda terlihat buruk - jangan menghabiskan waktu untuk menganalisis, hanya menjadi lebih baik dan menjadi anggota tim yang lebih bernilai (saya tahu itu lebih mudah dikatakan daripada dilakukan!)
Michael

7
@ Jesslyn, Jika dia melakukannya untuk Anda, kemungkinan dia melakukannya untuk semua orang. Saya ragu ada yang menghitung melawan Anda. (Jika dia tidak melakukannya untuk semua orang, Anda mungkin memiliki masalah yang berbeda)
user606723

3
@tgkprog: (1) Tentu saja, mendapatkan umpan balik dari orang lain sangat penting dan saya telah belajar beberapa hal dari melihat kode orang lain tetapi (2) jika Anda ingin belajar dari satu sama lain, Anda harus menyarankan perubahan dan mendiskusikannya bersama . Hanya mengubah hal-hal acak karena Anda pikir kodenya lebih baik setelah perubahan itu bukan pendekatan yang tepat. Ada pendekatan yang lebih baik seperti ulasan kode menggunakan alat ulasan.
Giorgio

2
ya saya sedang memikirkan saat-saat ketika saya telah memperbaiki kode orang lain sebelum batas waktu jam 11 malam tetapi bahkan kemudian akan mengirim email ke tim sehingga mereka dapat memeriksanya juga, termasuk QA kami ....
tgkprog

86

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 .


7
+1 dan lebih banyak lagi jika saya bisa. Jawaban bagus yang membahas cara terbaik untuk meningkatkan proses semacam itu.
Waldfee

2
Ya OP membutuhkan alat peninjau kode, sehingga Anda dapat meninjau kode bersama-sama, bukan hanya seseorang yang mengubah kode karena mereka menyukainya. Kami baru saja mulai menggunakan smartbear.com/products/software-development/code-review di tempat kerja
Juan Mendes

19

Ada apa dengan proses yang membuat Anda ingin bertanggung jawab atas "kode Anda"? Apakah Anda memiliki tanggung jawab tunggal untuk membuat fitur tertentu berfungsi? Apakah pemimpinnya berkata, "Michael, aku ingin kamu bertanggung jawab atas ..."? Atau apakah tanggung jawab Anda tersirat, dalam hal pimpinan dan anggota tim lainnya memandang Anda setiap kali fitur tertentu rusak?

Either way, jika Anda memiliki tanggung jawab, maka Anda memerlukan wewenang atas kode tersebut. Lain kali ketika orang lain melakukan perubahan sepihak dan pimpinan kembali kepada Anda untuk memperbaikinya, Anda harus duduk dengan pemimpin dan meminta agar wewenang dan tanggung jawab Anda selaras.


5
+1 Untuk menunjukkan fakta penting: Entah ada kepemilikan tim dan (1) semua bertanggung jawab (2) semua orang dapat mengubah kode, atau ada kepemilikan individu dan (1) pemilik modul bertanggung jawab (2) setiap perubahan harus disetujui oleh pemilik modul. Seringkali timbul kebingungan ketika anggota tim diharapkan bertanggung jawab atas suatu modul, tetapi anggota senior merasa berhak untuk membuat perubahan acak pada kode. Dengan kata lain, seseorang harus menghindari situasi "tanggung jawab tanpa wewenang".
Giorgio

4

Bukan berarti ini akan menyelesaikan seluruh situasi, tetapi Anda dapat mencoba menambahkan lebih banyak komentar ke kode sumber Anda.

  1. Jika kode tidak lengkap, itu bisa ditandai seperti itu.
  2. Jika tujuan blok kode tidak mendokumentasikan diri, maka Anda harus mendokumentasikannya.

Semua dan semua, cobalah membuat limun alih-alih membuang waktu mengisap lemon. Seperti yang dikatakan Michael, secara umum, rekan tim tidak keluar untuk membuat Anda terlihat buruk. Cobalah belajar dari kesalahan Anda dan menerapkannya pada revisi di masa depan.

Jika Anda yakin bahwa perubahannya berdampak negatif, silakan sampaikan ini (secara diplomatis). Jika itu saya, saya hanya akan bertanya mengapa perubahan spesifik dilakukan dan melihat apakah Anda dapat mempertahankan perubahan asli Anda. Rekan kerja senior Anda juga manusia. Sangat mungkin bahwa dia melewatkan sesuatu dan / atau tidak menyadari dampak negatif apa pun yang dia berikan.


3
Bocah yang bisa membingungkan. Bayangkan - menambahkan komentar yang menyatakan, "Kode ini tidak lengkap," dan kemudian lupa untuk menghapusnya setelah Anda menyelesaikan kode.
riwalk

1
@ Stargazer712, Lebih membingungkan daripada memiliki kode yang tidak lengkap di cabang?
user606723

Itulah gunanya raket. Jangan laporkan kode yang tidak lengkap.
riwalk

2
Tidak. Jika Anda memeriksa kode yang tidak lengkap yang memerlukan komentar untuk melabeli itu, maka Anda sudah berada di neraka. Komentar hanya membawa Anda ke sudut neraka yang berbeda.
riwalk

1
Mereka disebut TODO, mereka ditinggalkan dalam kode kerja sepanjang waktu
Juan Mendes

4

Semua orang secara implisit 'memiliki kode mereka sendiri', terlepas dari politik, hukum, atau ekonomi - itu adalah 'sifat alami' - Anda secara alami merasakan hubungan pribadi dengan pekerjaan Anda sendiri.

Jika rekan kerja Anda terlibat dalam perilaku yang Anda jelaskan dan tetap tidak responsif ketika Anda meminta kepala , rekan kerja itu tidak sopan, untuk sedikitnya, dan mungkin mencoba untuk merusak Anda (untuk mengatakan yang terburuk .. .) - TIDAK terdengar seperti pemain tim.

Rekan kerja yang baik akan menyentuh basis dengan Anda dan menunjukkan masalah dengan kode Anda kepada Anda - dan membiarkan Anda memperbaiki / mengubahnya, atau merespons dengan tepat. Saya sangat bersyukur bahwa bahkan ketika saya seorang pemula, mentor saya selalu menunjukkan kepada saya apa yang saya lakukan salah, menjelaskan mengapa dan membiarkan (atau membuat ) saya memperbaikinya. Itu membuat saya seorang programmer yang lebih baik dan semua orang mendapat manfaat. Dan itulah yang selalu saya lakukan ketika meninjau pekerjaan yang dilakukan oleh orang lain. Maka Anda, (atau siapa pun) sebenarnya belajar sesuatu dari 'jack of all trades' Anda, dan kode serta tim semuanya menjadi lebih baik, termasuk guru Anda: Mengajar membantu memahami.

Jika memungkinkan, saya akan membahas masalah ini secara pribadi dengan Ketua Tim. Berdasarkan uraian Anda tentang situasi, seorang pemimpin tim yang baik akan memihak Anda - yang buruk tidak akan .... Jelas ini membutuhkan kehati-hatian - Anda harus menilai itu sendiri.


1
Terlepas dari pernyataan awal (ada tim yang mengadopsi kepemilikan tim dan tim lain yang mengadopsi kepemilikan individu), saya menemukan pengamatan dalam jawaban ini OK (+1 untuk ini): Saya juga mengamati kepemilikan kode bersama yang digunakan untuk merusak tim posisi anggota dalam tim dengan memodifikasi kode mereka secara sewenang-wenang. Jadi saya tidak mengerti downvotes. Akan lebih baik jika para downvoters peduli untuk menjelaskan.
Giorgio

1
Saya pikir jawaban Mikey adalah penjelasan yang baik tentang bagaimana saya tetap menjadi pemain tim. Mungkin ini terlalu fokus orang? Seperti Yannis sarankan, proses pengembangan tim saya terdengar menjadi masalah nyata. Bagaimanapun saya ingin tahu mengapa ini diturunkan.
Jesslyn

1
@ Jesslyn - Saya menduga saya downvoted karena pernyataan saya "Semua orang secara implisit 'memiliki kode mereka sendiri'". Ini adalah pertanyaan filosofis, bukan pertanyaan kebijakan. :-)
Vector

1
@ Mikey: "Semua orang secara implisit 'memiliki kode mereka sendiri'" Ini bisa menjadi bahan perdebatan, tentu saja. Programmer yang bukan wiraswasta biasanya menandatangani kontrak yang mengatakan mereka tidak memiliki kode sumber. Terlepas dari ini, saya berpikir bahwa pembuat kode adalah yang paling memahami kode, dan jika orang lain mengubah kode, maka baik penulis maupun pengembang kedua tidak benar-benar memahami kode 100%.
Giorgio

1
@ Mikey: Kepemilikan kode bersama mencoba memastikan bahwa anggota tim cukup memahami kode dengan cukup baik (sementara tidak ada yang benar-benar memahaminya dengan sangat baik). Ini lebih disukai daripada kepemilikan kode individu, di mana setiap modul (setidaknya pada prinsipnya) sepenuhnya dipahami oleh satu programmer, tetapi ada risiko bahwa pengetahuan ini hilang jika programmer itu berhenti.
Giorgio

1

Jika Anda menulis kode, maka saya harus memeriksanya.

Jika saya mengubah kode Anda selama peninjauan, maka kode itu bukan lagi kode yang saya ulas, tetapi kode yang saya ubah. Karena itu perlu ditinjau. Mungkin olehmu.

Jika saya melakukan kode baru Anda dengan perubahan saya tanpa seseorang meninjau perubahan saya, maka saya telah melakukan (1) perubahan yang tidak ditinjau, dan (2) dosa terburuk yang mungkin terjadi jika ulasan kode dianggap serius.


0

Saya pikir Anda sedang menanganinya dengan cara yang benar untuk saat ini - tetapi akan segera ada titik kritis di mana hal itu mengalihkan perhatian Anda sejauh Anda mungkin tidak senang mengodekan cara ini sama sekali.

Jika saya jadi Anda, saya akan meminta pertemuan langsung dengan orang ini dan menjelaskan PoV saya dengan tenang namun tegas. Kepemilikan tim atas kode dll. Baik-baik saja tetapi kecuali jika Anda memberi setiap pengembang cukup ruang untuk menyelesaikan pekerjaannya, membuat kesalahan dan meningkatkan Anda tidak akan pernah membangun kode yang baik. Ini bisa menjadi area gesekan lebih cepat daripada nanti.

(Ada jawaban yang sama sekali berbeda jika ini ada di tempat kerja.stackexchange. Mencari cara yang benar untuk melakukan tinjauan kode adalah hal yang mudah. ​​Meyakinkan rekan kerja Anda untuk mematuhi ini jauh lebih sulit).

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.