Tại sao nhà phát triển cam kết thống kê có hại?


10

Tôi từ lâu đã tin (và nghe từ những người khác) rằng việc theo dõi số liệu thống kê cam kết, chẳng hạn như có bao nhiêu cam kết mỗi nhà phát triển thực hiện mỗi ngày, có hại cho quá trình phát triển. Lý do có vẻ rõ ràng - các nhà phát triển sẽ cam kết với số tiền nhỏ hơn, tối đa hóa số lần cam kết mỗi ngày của họ, nhưng làm cho việc chia đôi khó khăn hơn (có lẽ tất cả các bản vá trung gian của họ sẽ không rời khỏi repo được hình thành tốt) và khó hơn để làm việc với lịch sử cam kết (một thay đổi sẽ đột nhiên trong nhiều lần xác nhận, thay vì chỉ một lần, hoàn nguyên một bản vá khó hơn, v.v.).

Có nghiên cứu nào cho thấy thống kê cam kết có hại không? Bất kỳ bài viết thanh lịch và tranh luận tốt về chủ đề này? Áp dụng tương tự sẽ là bất cứ điều gì về lý do tại sao đo lường điều sai dẫn đến việc mọi người tối ưu hóa điều sai, vấn đề này chỉ là một trường hợp đặc biệt.


8
"Bất kỳ bài viết thanh lịch và tranh luận" ?? Câu hỏi của bạn là thanh lịch và tranh luận tốt. Bạn cần thêm gì nữa à? Bạn đã cung cấp bằng chứng phong phú rằng các con số được chơi một cách tầm thường và do đó vô dụng. Bạn muốn gì hơn là câu hỏi thanh lịch và được tranh luận của bạn?
S.Lott

Các nhà phát triển cần phải cố gắng làm việc với việc tìm và sửa các lỗi trong các kịch bản cam kết lớn và cam kết nhỏ để xem differenc.e

Tôi không nghĩ rằng việc thu thập số liệu thống kê có hại trong chính nó nhưng sử dụng nó để đánh giá các lập trình viên thì sẽ như vậy. VCS của chúng tôi thu thập thông tin đó, cùng với vô số các số liệu thống kê khác và có sẵn cho toàn đội nhưng chúng tôi hầu như không bao giờ nhìn vào nó. Vì vậy, không, thu thập số liệu thống kê không có hại.
MarkJ

Tôi không tranh luận về những cam kết lớn và nhỏ ở đây (cá nhân tôi là một loại người cam kết nhỏ), chỉ đơn thuần là áp lực bên ngoài để thay đổi kích thước cam kết để giả mạo một thống kê (không bao giờ có thể tốt). Tôi lý tưởng đang tìm kiếm một nơi nào đó mà tôi có thể chỉ cho người khác, vì vậy tôi không phải tự mình tranh luận :)
Neil Mitchell

2
Tôi tin rằng truyện tranh Dilbert này làm cho trường hợp cũng như bất cứ điều gì tôi từng thấy.
ebneter

Câu trả lời:


8

http://www.mit.edu/~hauser/Papers/Hauser-Katz%20Measure%2004-98.pdf

Đây có phải là thứ bạn đang tìm kiếm? Có hàng ngàn bài viết "bạn chỉ có được những gì bạn đo lường" được tìm thấy bởi Google.


1
Thông thường tôi sẽ không đưa ra một câu trả lời cơ bản chỉ liên kết + không có đoạn trích, nhưng trong trường hợp cụ thể này tôi thấy nó ổn, vì "câu trả lời" dù sao cũng sẽ chỉ là câu hỏi.
o0 '.

6

Đây là một thống kê thú vị để đo lường, nhưng không hữu ích hơn việc ghi lại số giờ mà một nhà phát triển làm việc trong tuần.

Đối với một, nó không tính đến chất lượng mã. Một nhà phát triển có thể cam kết liên tục khi anh ta tiếp tục sửa lỗi trong mã của mình. Điều này sẽ cho thấy số lượng lớn các cam kết, so với một nhà phát triển cam kết một đoạn mã hoàn thành, được đánh bóng. Bạn sẽ không nghĩ rằng anh chàng có số lượng cam kết lớn hơn là nhà phát triển tốt hơn.

Tương tự, ai đó chần chừ và lướt SO cả ngày chỉ để cam kết một lần một ngày sẽ có cùng số lượng cam kết như nhà phát triển chuyên dụng đã dành cả ngày để mã hóa để thực hiện cam kết cuối cùng vào cuối ngày để giữ an toàn cho mã của mình.

Nếu bạn có một hệ thống trong đó các dòng mã được cam kết được tính, anh chàng đi qua các tệp nguồn 'tái cấu trúc' mỗi dấu ngoặc nhọn theo kiểu ưa thích của anh ta sẽ có giá trị rất lớn. Anh chàng đã làm một lỗi siêu quan trọng 1 dòng sẽ hầu như không xuất hiện.

Vì vậy, nó không tạo ra bất kỳ thống kê có ý nghĩa nào ngay cả khi các nhà phát triển không chơi trò chơi trên hệ thống. Nó sẽ cung cấp cho bạn không có gì ngoại trừ một biểu đồ đẹp. Tuy nhiên mọi người đều thích số liệu thống kê nên tôi nói hãy giữ chúng, nhưng đừng sử dụng chúng cho bất cứ điều gì khác ngoài niềm vui.


Trong khi ý kiến ​​của bạn là thú vị, câu hỏi thực tế dường như là "có nghiên cứu nào không ...?" mà câu trả lời của bạn không giải quyết.
Bryan Oakley

"số dòng". Có thể mất vài ngày để nghiên cứu một vấn đề mà cuối cùng sẽ dẫn đến một bản vá dòng đơn.

5
chỉ là một câu chuyện , nhưng một cổ điển.
Wrikken

Nghiên cứu "vài ngày" này (hoặc ít nhất vài giờ) dẫn đến việc sửa chữa một dòng rất quan trọng nhưng xảy ra khá thường xuyên theo kinh nghiệm của tôi.
Johan
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.