Bagaimana seharusnya kode "Penentuan Sasaran" ditangani oleh Manajer Pengembangan?


12

Pertama izinkan saya untuk membuat koin istilah:

pemeliharaan sasaran kode: Memeriksa kode di pagi hari, lalu dengan tenang meninjau semua perubahan yang dibuat oleh pengembang lain pada file hari sebelumnya, (terutama file kode yang Anda kembangkan sebelumnya), dan memperbaiki pemformatan, logika, variabel penamaan ulang, refactoring metode yang panjang, dll., dan kemudian melakukan perubahan pada VCS.

Praktek ini cenderung memiliki beberapa pro dan kontra yang telah saya identifikasi:

  • Pro : Kualitas kode / keterbacaan / konsistensi sering dipertahankan
  • Pro : Beberapa bug diperbaiki karena pengembang lain tidak terlalu terbiasa dengan kode asli.
  • Kontra : Sering kali buang-buang waktu pengembang tujuan-cenderung.
  • Con : Kadang-kadang memperkenalkan bug yang menyebabkan kemarahan menarik oleh pengembang yang berpikir mereka menulis kode bebas bug pada hari sebelumnya.
  • Con : Pengembang lain diperparah dengan nitpicking berlebihan dan mulai tidak suka berkontribusi pada kode tender-tujuan.

Penafian: Agar adil, saya sebenarnya bukan manajer pengembangan, saya pengembang yang benar-benar melakukan "goal tending".

Dalam pembelaan saya, saya pikir saya melakukan ini untuk alasan yang baik (untuk menjaga basis kode kami yang sangat besar menjadi mesin yang diminyaki dengan baik), tetapi saya sangat khawatir bahwa itu juga menciptakan suasana negatif. Saya juga sangat khawatir bahwa manajer saya perlu mengatasi masalah ini.

Jadi, jika Anda adalah manajer, bagaimana Anda mengatasi masalah ini?

UPDATE: Saya tidak bermaksud ini terlalu lokal, tetapi beberapa orang bertanya, jadi mungkin beberapa latar belakang akan menerangi. Saya ditugaskan proyek raksasa (200K LoC) tiga tahun yang lalu, dan hanya baru-baru ini (1 tahun yang lalu) adalah pengembang tambahan ditambahkan ke proyek, beberapa di antaranya tidak terbiasa dengan arsitektur, yang lain masih belajar bahasa (C #). Saya biasanya harus menjawab untuk stabilitas keseluruhan produk, dan saya sangat gugup ketika perubahan mengejutkan dilakukan pada bagian arsitektur inti dari basis kode. Kebiasaan ini muncul karena pada awalnya saya optimis tentang kontribusi pengembang lain, tetapi mereka membuat terlalu banyak kesalahan yang menyebabkan masalah serius yang tidak akan ditemukan sampai berminggu-minggu kemudian, di mana jari akan menunjuk saya untuk menulis kode yang tidak stabil. Sering ini "


3
Tampaknya pengembang Anda tidak cukup memompa ban Anda. Ganti goaltender Anda dengan FxCop atau yang serupa dan tegakkan standar-standar itu secara otomatis sehingga mereka tidak dapat check-in.
Jon Raynor

2
Con: Ini bukan pekerjaanmu. Orang-orang ini seharusnya melakukan tujuan mereka sendiri.
Robert Harvey

10
sebagai pengembang saya akan menemukan ini menyebalkan bagi pengembang lain untuk melakukan ini dengan semua perubahan yang saya buat, dan jika bug diperkenalkan kembali / diperkenalkan sebagai hasilnya maka itu benar-benar tidak dapat diterima
Ryathal

4
@Ryathal: Toko harus memberlakukan standar kode. Kode umumnya dimiliki oleh seluruh tim, jadi jika Anda tidak ingin orang mengubahnya, Anda harus memperbaikinya sejak awal.
Robert Harvey

1
@RobertHarvey enfocing standar adalah satu hal, pengembang nakal diam-diam menegakkan pandangannya tentang "benar" adalah masalah yang berbeda, dan ini tampaknya menjadi kasus yang terakhir.
Ryathal

Jawaban:


52

Kedengarannya seperti apa yang Anda lakukan pada dasarnya setara dengan tinjauan kode kecuali bahwa alih-alih memberikan umpan balik kepada pengembang, Anda membuat semua perubahan yang Anda sarankan dalam tinjauan kode. Anda hampir pasti lebih baik melakukan tinjauan kode aktual di mana Anda (atau orang lain) memberikan umpan balik kepada pengembang asli tentang masalah kualitas kode dan bug yang jelas dan meminta pengembang asli untuk memperbaikinya. Itu menjaga kualitas kode tetap tinggi tetapi juga membantu pengembang menjadi lebih akrab dengan kode asli dan perangkapnya dan membantu meningkatkan perubahan kode di masa depan. Plus, itu tidak memiliki downside menyebabkan "rambut menarik kemarahan" ketika bug diperkenalkan secara diam-diam atau menyebabkan pengembang lain berpikir bahwa mereka sedang dibicarakan di belakang mereka.


4
+1 Besar. Ulasan kode membantu membangun tim sementara "tujuan cenderung" yang dia jelaskan kelihatannya menggosok orang dengan cara yang salah.
Doug T.

2
Ini. Ulasan kode nyata akan menjadi jalur yang jauh lebih baik di sini. Dua keuntungan besar adalah, seperti yang Anda katakan, pengembang belajar arsitektur aplikasi lebih cepat karena Anda menunjukkan kepadanya masalah. Yang kedua adalah Anda tidak akan memperkenalkan bug karena Anda tidak sepenuhnya memahami kode baru yang sedang ditulis. Jawaban sempurna untuk pertanyaan ini.
Mike Cellini

2
Jawaban cemerlang dan terima kasih atas wawasannya. Saya pikir membawa salinan pertanyaan ini dan sikap rendah hati kepada manajer saya dapat meyakinkannya bahwa tinjauan kode akan bermanfaat bagi tim dan akan mengurangi kebutuhan akan "tujuan yang cenderung".
Kevin McCormick

1
Sepakat. Jangan main-main dengan kode orang lain tanpa bertanya. Anda bisa mendapatkan beberapa bug degil dengan cara itu. Saya telah memperbaiki bug yang cenderung tujuan, dan itu tidak menyenangkan. Jika Anda khawatir tentang ketahanan kode, tulis unit test.
Paul Nathan

2
Bahkan jika Anda tidak pernah beralih ke ulasan kode "nyata", cukup berbicara dengan orang lain - menanyakan mengapa mereka melakukan hal-hal tertentu, dan mengapa mereka tidak melakukannya [dengan cara lain], adalah cara yang bagus untuk menyelesaikan banyak hal yang sama. tujuan. +1
TehShrike

14

Sejujurnya, IMHO, ini adalah ide yang buruk.

Saya berharap semangat turun ke selokan, jika belum.

Agar adil bagi Anda, Anda mengakui hal ini.

Ulasan kode rekan baik-baik saja, itu menempatkan tanggung jawab pada devs semua pada satu tingkat, alih-alih itu menjadi skenario "mereka versus kita". (di mana mereka adalah manajemen / prospek).

Mungkin ada beberapa pengembang yang mungkin perlu Anda perhatikan lebih dari yang lain, tetapi selimut memaksa semua kode untuk datang melalui Anda terlebih dahulu adalah konyol.

Dan terlepas dari seberapa baik Anda berpikir Anda, akan ada saat-saat Anda salah, atau "memetik" dan ini hanya akan membuat segalanya lebih buruk.


Itu dan manajer mungkin lebih cenderung membuat kode lebih buruk.
Andy

5

Jika saya adalah manajer, untuk mengatasi masalah ini:

  • Tinjau standar kode dan praktik dengan tim, berikan salinan standar pengkodean
  • Kode peer review secara teratur untuk memperkuat standar dan praktik yang harus diikuti
  • Terapkan nitpicking / format dengan alat otomatisasi sehingga pengembang dipaksa untuk mengikuti standar
  • Singkirkan teman satu tim jahat yang menolak mengikuti standar
  • Berhentilah menjadi goaltender

Niat Anda baik, tetapi implementasinya mengerikan dan seperti yang telah ditunjukkan orang lain, akan menyebabkan moral dan sniping yang buruk di antara anggota tim.

Jika proyek tidak pernah memiliki standar untuk memulai, cobalah untuk mengurangi standar baru secara bertahap daripada hanya membalik saklar.


3

Juju buruk.

Saya bukan manajer pengembangan, tetapi jika saya adalah saya tidak ingin ada pengembang saya untuk menyentuh kode yang bukan bagian dari cacat atau fitur yang ditugaskan kepada mereka. Titik. Jika Anda melihat masalah dengan kode orang lain, maka dengan segala cara bawalah ke perhatian pengembang yang bertanggung jawab, tetapi jangan hanya terjun dan memperbaikinya sendiri, terutama jika Anda belum berkoordinasi dengan pengembang lain ( s) pertama.

Tugas pembersihan hanya dapat dilakukan setelah peninjauan kode formal oleh tim, dan hanya oleh pengembang yang kepadanya tugas tersebut diberikan.

Inisiatif itu bagus secara umum, tetapi kadang-kadang bisa menggigit Anda. Jika Anda memperkenalkan bug ke dalam apa yang kode bekerja, Anda mungkin cepat akan berharap Anda telah memilih jalur karir yang berbeda.

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.