Mengapa pengembang melakukan statistik yang berbahaya?


10

Saya sudah lama percaya (dan mendengar dari orang lain) bahwa melacak statistik komit, seperti berapa banyak komitmen yang dilakukan setiap pengembang per hari, berbahaya bagi proses pengembangan. Alasannya tampak jelas - pengembang akan melakukan penambahan lebih sedikit, memaksimalkan jumlah komit per hari mereka, tetapi membuatnya lebih sulit untuk membagi dua (mungkin semua tambalan menengah mereka tidak akan membuat repo terbentuk dengan baik) dan lebih sulit untuk bekerja dengan sejarah komit (perubahan tiba-tiba akan dilakukan dalam banyak komit, bukan hanya satu, mengembalikan tambalan lebih sulit dll).

Apakah ada studi yang menunjukkan statistik komit berbahaya? Adakah artikel yang elegan dan diperdebatkan dengan baik tentang topik ini? Hal yang sama berlaku adalah apa pun tentang mengapa mengukur hal yang salah membuat orang mengoptimalkan hal yang salah, yang hanya merupakan masalah khusus.


8
"Ada artikel yang elegan dan didebat dengan baik" ?? Pertanyaan Anda elegan dan diperdebatkan dengan baik. Apa lagi yang kamu butuhkan? Anda memberikan bukti yang cukup bahwa angka-angka itu diremehkan dan karenanya tidak berguna. Apa lagi yang Anda inginkan selain pertanyaan Anda yang anggun dan berdebat?
S.Lott

Pengembang perlu mencoba bekerja dengan menemukan dan memperbaiki bug dalam skenario komitmen besar dan komitmen kecil untuk melihat perbedaannya

Saya tidak berpikir mengumpulkan statistik itu berbahaya, tetapi menggunakannya untuk mengevaluasi pemrogram. VCS kami mengumpulkan informasi itu, bersama dengan segudang statistik lainnya, dan tersedia untuk seluruh tim, tetapi kami jarang melihatnya. Jadi tidak, mengumpulkan statistik tidak berbahaya.
MarkJ

Saya tidak memperdebatkan komit besar vs kecil di sini (saya pribadi tipe komit kecil), hanya tekanan eksternal untuk mengubah ukuran komit untuk memalsukan statistik (yang tidak akan pernah baik). Saya idealnya mencari tempat saya bisa mengarahkan orang lain, jadi saya tidak perlu membuat argumen sendiri :)
Neil Mitchell

2
Saya percaya bahwa komik Dilbert ini menjadikan kasus ini sebaik apa pun yang pernah saya lihat.
ebneter

Jawaban:



6

Ini adalah statistik yang menyenangkan untuk diukur, tetapi tidak lebih berguna daripada mencatat jumlah jam kerja seorang pengembang selama seminggu.

Untuk satu, itu tidak memperhitungkan kualitas kode akun. Satu pengembang mungkin terus-menerus berkomitmen karena ia terus memperbaiki bug dalam kodenya. Ini akan menunjukkan sejumlah besar komit, dibandingkan dengan pengembang yang melakukan satu potong kode yang sudah jadi. Anda tidak akan berpikir bahwa pria dengan jumlah komit lebih besar adalah pengembang yang lebih baik.

Demikian pula, seseorang yang malas dan berselancar SO sepanjang hari hanya untuk melakukan sekali sehari akan memiliki jumlah komit yang sama dengan pengembang yang berdedikasi yang menghabiskan sepanjang hari hanya mengkode untuk melakukan komit akhir di akhir hari untuk menjaga kodenya aman.

Jika Anda memiliki sistem di mana baris kode yang dilakukan dihitung, orang yang melalui file sumber 'refactoring' setiap braket keriting dengan gaya yang disukai akan memiliki nilai besar. Orang yang melakukan perbaikan bug penting 1-line hampir tidak akan muncul.

Jadi itu tidak membuat statistik yang berarti bahkan jika pengembang tidak memainkan sistem. Seharusnya tidak memberi Anda apa pun kecuali grafik yang cantik. Namun semua orang menyukai statistik jadi saya akan mengatakan menyimpannya, tetapi jangan menggunakannya untuk hal lain selain kesenangan.


Meskipun pendapat Anda menarik, pertanyaan yang sebenarnya tampaknya adalah "apakah ada studi ...?" yang tidak dijawab oleh jawaban Anda.
Bryan Oakley

"jumlah garis". Mungkin perlu beberapa hari untuk meneliti masalah yang pada akhirnya akan menghasilkan satu tambalan tunggal.

5
hanya dongeng , tapi yang klasik.
Wrikken

Ini "beberapa hari" (atau setidaknya beberapa jam) penelitian yang menghasilkan perbaikan baris yang sangat penting tetapi sering terjadi dalam pengalaman saya.
Johan
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.