Bagaimana cara mengambil tanggung jawab untuk kode saya ketika rekan tidak perlu membuat perbaikan tanpa pemberitahuan?
Salah satu rekan tim saya adalah jack dari semua perdagangan di kami toko dan saya menghormati wawasan.
Namun, kadang-kadang ia ulasan saya kode (ia's kedua dalam perintah untuk pemimpin tim kami, sehingga's diharapkan) tanpa kepala. Jadi kadang-kadang dia ulasan saya perubahan sebelum mereka menyelesaikan tujuan akhir dan membuat perubahan segera... dan bahkan telah rusak kerja saya sekali.
Kali lain, dia telah membuat yang tidak perlu perbaikan untuk beberapa kode saya yang 3+ bulan.
Ini mengganggu saya selama beberapa alasan:
- Saya tidak selalu diberikan kesempatan untuk memperbaiki kesalahan saya
- Ia tidak mengambil waktu untuk bertanya kepada saya apa yang saya capai ketika dia bingung, yang dapat mempengaruhi pengujian atau perubahan
- Saya don't selalu berpikir kodenya lebih mudah dibaca
- Tenggat waktu tidak akan menjadi masalah dan beban kerja saat ini doesn't membutuhkan pekerjaan di proyek-proyek saya yang lain dari saya meninjau perubahan kode.
Lagian, saya telah mengatakan kepadanya di masa lalu untuk mohon terus kabari aku jika dia melihat sesuatu dalam pekerjaan saya bahwa dia ingin perubahan, sehingga saya bisa mengambil kepemilikan dari kode saya (mungkin saya harus mengatakan "kekurangan") dan dia's tidak responsif.
Aku takut bahwa aku mungkin datang sebagai agresif ketika saya meminta dia untuk menjelaskan perubahan untuk saya.
Dia's hanya orang yang tenang terus untuk dirinya sendiri, tapi tindakannya terus. Saya don't ingin mengusir dia dari membuat perubahan kode (tidak seperti aku yang bisa), karena kami adalah sebuah tim, tapi saya ingin melakukan bagian saya untuk membantu tim kami.
Menambahkan klarifikasi:
- Kita berbagi 1 pengembangan cabang. Saya tidak menunggu sampai semua perubahan saya menyelesaikan satu tugas karena saya kehilangan beberapa pekerjaan yang signifikan--jadi saya pastikan saya perubahan yang membangun dan tidak melanggar apa-apa.
- Keprihatinan saya adalah bahwa rekan saya doesn't menjelaskan alasan atau tujuan di balik perubahan. Saya don't pikir dia harus membutuhkan berkat saya, tapi jika kita tidak setuju pada pendekatan saya pikir itu akan menjadi yang terbaik untuk membahas pro dan kontra dan membuat keputusan setelah kita memahami apa yang terjadi.
- Saya belum membicarakan hal ini dengan tim kami memimpin namun seperti yang saya akan lebih memilih untuk menyelesaikan perbedaan pendapat pribadi tanpa mendapatkan manajemen yang terlibat kecuali jika diperlukan. Karena keprihatinan saya tampak lebih dari masalah pribadi dari ancaman untuk pekerjaan kami, saya memilih untuk tidak repot-repot memimpin tim. Saya bekerja pada kode meninjau proses ide-ide untuk membantu mempromosikan manfaat lebih terorganisir kode ulasan tanpa membuat itu semua tentang my pet peeves.
Anda dan kebanyakan dari penjawab pendekatan ini sebagai masalah komunikasi antara dua rekan, tapi aku don't benar-benar berpikir itu adalah. Apa yang anda jelaskan lebih terdengar seperti mengerikan patah kode proses review dari apa pun. Pertama, anda menyebutkan bahwa rekan anda adalah yang kedua dalam perintah dan's diharapkan bahwa ia'll review kode anda. Yang's salah. Menurut definisi, peer kode ulasan yang tidak hirarkis, dan mereka tentu saja tidak 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 kode kolektif kepemilikan. Anda juga harus meninjau kode nya dari waktu ke waktu, belajar dari dia dan benar dia ketika dia's yang salah (tidak ada yang mendapatkannya benar every waktu). Selain itu, anda menyebutkan bahwa rekan anda membuat perubahan segera. Yang's juga salah, tapi tentu saja anda sudah tahu itu, anda tidak't telah meminta pertanyaan ini jika gung ho pendekatan itu't masalah. Namun saya pikir anda sedang mencari solusi di tempat yang salah. Untuk menjadi sempurna jujur, rekan anda mengingatkan saya sedikit... saya, dan apa yang bekerja untuk saya dalam situasi yang sama telah didefinisikan dengan baik dan solid proses review dan satu set alat yang mengagumkan. Anda don't benar-benar ingin berhenti rekan anda dari meninjau kode anda, dan meminta dia untuk berhenti dan berbicara kepada anda sebelum setiap perubahan kecil ini tidak benar-benar akan bekerja. Mungkin, untuk sementara waktu, tapi ia'akan segera mencapai titik di mana ia hanya akan mendapatkan terlalu mengganggu dan anda'akan kembali di mana anda mulai, atau lebih buruk: ia'll hanya berhenti meninjau kode anda. Kunci untuk resolusi berikut mungkin menjadi peer review kode alat. Saya biasanya menghindari produk rekomendasi, tapi untuk kode ulasan Atlassian's Crucible adalah benar-benar hidup hemat. Apa itu mungkin tampak sangat sederhana, dan itu adalah, tapi itu doesn't berarti itu's tidak luar biasa mengagumkan. Ini kait sampai ke repositori anda dan memberi anda kesempatan untuk meninjau individu set perubahan, file atau sekelompok file. Anda don't mendapatkan untuk mengubah kode apapun, sebagai gantinya anda mengomentari segala sesuatu yang doesn't merasa benar. Dan jika anda benar-benar harus mengubah orang lain's kode, anda hanya dapat meninggalkan komentar dengan changeset menjelaskan perubahan anda. Pengantar video di Wadah's halaman produk bernilai menonton jika anda ingin rincian lebih lanjut. Wadah's harga ini tidak untuk semua orang, tetapi ada banyak yang tersedia secara bebas peer review yang sesuai. Salah satu yang saya've bekerja dengan dan menikmati Review Papan dan I'm yakin anda'll menemukan banyak orang lain dengan pencarian Google yang sederhana. Apapun alat yang anda pilih, itu akan benar-benar mengubah proses. Tidak perlu berhenti, turun dari kursi, mengganggu orang lain dan mendiskusikan perubahan; semua yang perlu anda lakukan adalah mengatur waktu libur setiap minggu dan pergi melalui komentar (seminggu sekali hanya saran. Anda tahu jadwal anda dan rutinitas sehari-hari yang lebih baik daripada yang saya lakukan). Yang lebih penting inti ulasan disimpan dalam database di suatu tempat dan anda dapat mengambil mereka setiap saat. Mereka tidak't fana diskusi sekitar pendingin air. Favorit saya gunakan kasus untuk ulasan tua adalah ketika memperkenalkan anggota tim baru untuk kita codebase. It's selalu menyenangkan ketika saya bisa berjalan-jalan dengan seseorang yang baru melalui basis kode yang menunjukkan di mana tepatnya kita terjebak, di mana kita memiliki perbedaan pendapat, dll. Selanjutnya, anda menyebutkan bahwa anda don't selalu menemukan rekan ini's kode yang dapat dibaca. Yang memungkinkan saya tahu bahwa anda don't memiliki seperangkat standar coding, dan yang's hal yang buruk. Sekali lagi anda mungkin pendekatan ini sebagai orang-orang masalah atau anda dapat pendekatan ini sebagai sebuah proses, masalah, dan lagi saya akan sangat menyarankan terakhir. Mendapatkan tim anda bersama-sama dan mengadopsi umum coding gaya dan menetapkan standar sesegera mungkin. Itu doesn't benar-benar peduli jika anda memilih satu set standar yang's umum dalam pengembangan ekosistem atau anda datang dengan anda sendiri. Apa yang benar-benar penting adalah untuk standar anda untuk konsisten dan bahwa anda tetap untuk mereka. Banyak dan banyak alat di luar sana yang dapat membantu anda, tapi itu's keseluruhan diskusi yang berbeda. Hanya untuk mendapatkan anda mulai, hal yang sangat sederhana untuk dilakukan adalah memiliki hook pre-commit menjalankan beberapa jenis gaya formatter pada kode anda. Anda dapat melanjutkan menulis kode anda namun anda suka dan biarkan alat "fix it" otomatis sebelum orang lain melihatnya. Terakhir yang anda sebutkan dalam comment bahwa manajemen tidak percaya individu dev cabang-cabang yang diperlukan. Nah, ada's alasan kami menyebutnya "dev cabang" dan "manajemen cabang." aku'll berhenti di sini karena ada's tidak ada alasan untuk kata-kata kasar yang's terbentuk di kepala saya untuk keluar. Semua yang mengatakan, tahu bahwa aku don't ragu rekan anda (sedikit) salah di sini. Yang's tidak maksud saya, maksud saya adalah bahwa seluruh proses pembangunan adalah juga salah, dan yang's sesuatu yang's mudah untuk memperbaiki. Mempersenjatai diri dengan alat yang tepat, jelajahi berbagai acara formal maupun proses informal dan memilih orang-orang yang sesuai dengan anda tim. Segera anda'll mencapai titik di mana anda'll menyadari bahwa sebagian besar dari anda "orang-orang masalah" don't ada lagi. Dan silakan don't mendengarkan siapapun (termasuk anda) yang menumbuhkan "kami're tim kecil, kita don't membutuhkan semua bahwa" alasan. Tim pengembang yang kompeten dapat menyiapkan alat-alat yang diperlukan dalam waktu kurang dari seminggu, mengotomatisasi segala sesuatu yang dapat dilakukan secara otomatis, dan tidak pernah melihat ke belakang lagi. PS. "Kode kepemilikan" adalah istilah yang samar-samar, terus-menerus diperdebatkan, dan itu berarti hal yang berbeda untuk orang yang berbeda. Anda dapat menemukan koleksi brilian dari sebagian besar berbeda (dan kadang-kadang bertentangan) pendapat di C2.
Saya pikir sebagian besar pengembang menemukan diri mereka dalam posisi ini di beberapa titik, dan saya berharap bahwa setiap pengembang yang's merasa menjadi korban menyadari bagaimana frustasi itu adalah ketika ia menjadi senior dan merasa terdorong untuk membersihkan kode yang ditulis oleh junior.
Bagi saya, menghindari konflik dalam situasi ini bermuara pada dua hal:
Kesopanan. Berbicara dengan seseorang tentang/nya kode memungkinkan dev untuk tahu bahwa anda're tertarik dan anda dapat mendiskusikan hal ini seperti tumbuh hingga profesional.
Lupa tentang "kode kepemilikan" - tim yang memiliki kode. Lain orang-orang yang ingin membuat perubahan adalah hal yang baik. Jika senior dev membuat perubahan yang "tidak dapat dibaca" atau lebih buruk lagi, kemudian kembali mereka. Anda don't perlu menjadi agresif, biarkan editor tahu bahwa/nya perubahan didn't bekerja, dan anda're lebih dari senang untuk membahas pengembalian.
Ingat, kepemilikan tim dari kode besar dan itu memotong kedua cara. Jika anda melihat sesuatu yang doesn't masuk akal pada orang lain's code, kemudian memperbaikinya. Menjadi terlalu posesif dan tidak komunikatif adalah cara jitu untuk membuat beracun pengembangan lingkungan.
Apa itu tentang proses yang membuat anda ingin bertanggung jawab untuk "kode anda" ? Apakah anda memiliki tanggung jawab untuk menjaga fitur-fitur tertentu bekerja? Apa yang menyebabkan mengatakan "Michael, saya ingin anda untuk mengambil tanggung jawab untuk ..." ? Atau adalah tanggung jawab anda implisit, dalam memimpin dan sisanya dari tim melihat anda setiap waktu beberapa fitur tertentu sedang rusak?
Either way, jika anda memiliki tanggung jawab, maka anda perlu otoritas atas kode. Saat orang lain membuat perubahan unilateral dan menyebabkan datang kembali kepada anda untuk memperbaiki mereka, anda harus duduk dengan memimpin dan meminta untuk memiliki wewenang dan tanggung jawab yang selaras.
Semua orang implicitely 'memiliki kode mereka sendiri', terlepas dari politik, legalistics, atau ekonomi - it's 'alam hal' - anda tentu merasa hubungan pribadi dengan pekerjaan anda sendiri.
Jika anda co-pekerja terlibat dalam perilaku yang anda gambarkan dan tetap responsif ketika anda meminta kepala, yang co-pekerja kasar, untuk sedikitnya, dan mungkin mencoba untuk merusak anda (untuk tidak mengatakan yang terburuk...) - tidak TIDAK terdengar seperti seorang pemain tim.
Seorang rekan sekerja yang baik akan menyentuh dasar dengan anda dan menunjukkan masalah dengan kode anda untuk anda - dan memungkinkan anda memperbaiki/mengubah, atau merespon dengan tepat. Saya sangat bersyukur bahwa bahkan ketika saya masih newbee, mentor saya selalu menunjukkan kepada saya apa yang saya lakukan salah, menjelaskan mengapa dan membiarkan (atau pakai) saya perbaiki. Yang membuat saya menjadi programmer yang lebih baik dan semua orang diuntungkan. Dan yang's apa yang saya selalu lakukan ketika meninjau pekerjaan yang dilakukan oleh orang lain. Maka anda, (atau siapa pun) benar-benar belajar sesuatu dari anda 'jack dari semua perdagangan', dan kode dan tim semua mendapatkan yang lebih baik, termasuk guru: Mengajar membantu pemahaman.
Jika itu's pada semua kemungkinan, saya akan membahas masalah secara pribadi dengan Pemimpin Tim. Berdasarkan keterangan dari situasi, baik pemimpin tim akan mengambil sisi - buruk won't.... Jelas ini membutuhkan hati-hati - anda akan memiliki untuk menilai bahwa untuk diri sendiri.
Tidak bahwa ini akan memecahkan seluruh situasi, tetapi anda dapat menambahkan lebih banyak komentar untuk kode sumber anda.
Semua dan semua, mencoba untuk membuat limun bukannya membuang-buang waktu mengisap lemon. Sebagai Michael mengatakan, secara umum, rekan aren't keluar untuk membuat anda terlihat buruk. Cobalah untuk belajar dari kesalahan anda dan menerapkan mereka untuk revisi masa depan.
Jika anda percaya bahwa perubahan yang memiliki dampak negatif, silakan suara ini (diplomatis). Jika itu aku, aku hanya akan bertanya mengapa perubahan spesifik yang dilakukan dan melihat jika anda dapat mempertahankan aslinya perubahan. Senior co-pekerja adalah manusia juga. It's sangat mungkin bahwa ia merindukan sesuatu dan/atau tidak menyadari dampak negatif dia menyediakan.
Jika anda menulis kode, maka aku harus memeriksanya.
Jika saya mengubah kode anda selama peninjauan, maka kode ini tidak kode lagi yang saya review, tapi kode yang saya berubah. Oleh karena itu perlu ditinjau ulang. Mungkin oleh anda.
Jika saya melakukan kode baru dengan perubahan saya tanpa seseorang meninjau perubahan saya, maka saya telah melakukan (1) unreviewed perubahan, dan (2) kemungkinan terburuk dosa jika kode ulasan diambil serius.
Saya pikir anda menanganinya dengan cara yang benar untuk sekarang - tapi akan segera ada titik kritis di mana ia mengalihkan perhatian anda sejauh yang anda mungkin tidak akan senang coding cara ini pada semua.
Jika aku jadi kau, aku akan meminta cepat satu-ke-satu dengan orang ini dan menjelaskan sudut pandang pertama dengan tenang namun tegas. Kepemilikan tim dari kode dll semua baik-baik saja tetapi jika anda memberikan setiap pengembang cukup ruang untuk menempatkan karya-nya, membuat kesalahan dan meningkatkan anda tidak akan pernah membangun kode yang baik. Ini bisa menjadi area gesekan lebih cepat daripada nanti.
(Ada yang benar-benar jawaban yang berbeda jika berada di tempat kerja.stackexchange. Mencari tahu cara yang benar untuk melakukan tinjauan kode adalah hal yang mudah. Meyakinkan rekan-pekerja untuk mematuhi ini adalah jauh lebih sulit).