Dlaczego statystyki zatwierdzania przez programistów są szkodliwe?

10

Od dawna wierzyłem (i słyszałem od innych), że śledzenie statystyk zatwierdzania, takich jak liczba zatwierdzeń każdego programisty dziennie, jest szkodliwe dla procesu programowania. Powód wydaje się oczywisty - programiści dokonują mniejszych przyrostów, maksymalizując ich liczbę zatwierdzeń na dzień, ale utrudniając podział na dwa segmenty (być może wszystkie ich łatki pośrednie nie spowodują dobrego uformowania repo) i trudniej pracować z historią zatwierdzeń (zmiana nastąpi nagle w wielu zatwierdzeniach, zamiast w jednym, przywrócenie łatki jest trudniejsze itp.).

Czy są jakieś badania, które pokazują, że statystyki zatwierdzania są szkodliwe? Każdy elegancki i dobrze uzasadniony artykuł na ten temat? W równym stopniu dotyczy to tego, dlaczego pomiar niewłaściwej rzeczy prowadzi do optymalizowania niewłaściwej rzeczy, o czym jest to szczególny przypadek.

version-control Neil Mitchell
źródło
8
„Jakikolwiek elegancki i dobrze uzasadniony artykuł”? Twoje pytanie jest eleganckie i dobrze uzasadnione. Czego więcej potrzebujesz? Dostarczyłeś wystarczających dowodów na to, że liczby są trywialne i dlatego bezużyteczne. Czego więcej chcesz od swojego eleganckiego i dobrze uzasadnionego pytania?
S.Lott,
Programiści musieli próbować znaleźć i naprawić błędy w scenariuszach z dużymi zatwierdzeniami i małymi zatwierdzeniami, aby zobaczyć różnicę
Nie wydaje mi się, aby gromadzenie statystyk było samo w sobie szkodliwe, ale użycie ich do oceny programistów byłoby. Nasz VCS gromadzi te informacje wraz z niezliczoną liczbą innych statystyk i są dostępne dla całego zespołu, ale rzadko kiedy na nie patrzymy. Więc nie, zbieranie statystyk nie jest szkodliwe.
MarkJ
Nie debatuję tutaj nad dużymi a małymi zatwierdzeniami (osobiście jestem małym facetem w rodzaju zatwierdzeń), a jedynie zewnętrzną presją, aby zmienić rozmiar zatwierdzenia w celu sfałszowania statystyki (co nigdy nie może być dobre). Idealnie szukam miejsca, w którym mogę wskazać innym, więc nie muszę sam się kłócić :)
Neil Mitchell
2
Uważam, że ten komiks Dilberta stanowi uzasadnienie, podobnie jak wszystko, co kiedykolwiek widziałem.
ebneter

Odpowiedzi:

8

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

Czy tego szukasz? Istnieją tysiące artykułów „tylko dostajesz to, co mierzysz” znalezione przez Google.

S.Lott
źródło
1
Zwykle nie głosowałbym w zasadzie na odpowiedź „tylko link + brak fragmentu”, ale w tym konkretnym przypadku uważam, że jest w porządku, ponieważ „odpowiedź” i tak byłaby tylko pytaniem.
o0 ”.
6

Mierzenie statystyki jest zabawne, ale nie bardziej przydatne niż rejestrowanie liczby godzin, które programista przepracował w ciągu tygodnia.

Po pierwsze, nie bierze pod uwagę jakości kodu. Pewien programista może ciągle popełniać błędy, gdy wciąż naprawia błędy w swoim kodzie. To pokazuje dużą liczbę zatwierdzeń, w porównaniu do programisty, który zatwierdza jedną część gotowego, dopracowanego kodu. Nie pomyślałbyś, że facet z większą liczbą zatwierdzeń był lepszym programistą.

Podobnie, ktoś, kto zwalnia i surfuje SO przez cały dzień tylko po to, aby zatwierdzić raz dziennie, miałby taką samą liczbę zatwierdzeń, jak dedykowany programista, który spędził cały dzień na kodowaniu tylko po to, aby wykonać końcowe zatwierdzenie na koniec dnia, aby zachować swój kod.

Jeśli masz system, w którym liczone są wiersze kodu, facet, który przegląda pliki źródłowe „refaktoryzuje” każdy nawias klamrowy do swojego preferowanego stylu, będzie miał ogromną wartość. Facet, który dokonał ważnej poprawki 1-liniowej, ledwo się pojawi.

Więc nie tworzy żadnej znaczącej statystyki, nawet jeśli programiści nie grają w system. To powinno zapewnić ci tylko ładny wykres. Jednak wszyscy lubią statystyki, więc powiedziałbym, żeby je zachować, ale nie używaj ich do niczego innego niż do zabawy.

gbjbaanb
źródło
Chociaż Twoja opinia jest interesująca, wydaje się, że pytanie brzmi „czy są jakieś badania ...?” którego twoja odpowiedź nie dotyczy.
Bryan Oakley
"Liczba linii". Może zająć kilka dni, aby zbadać problem, który ostatecznie doprowadzi do powstania pojedynczej linii łaty.
5
tylko opowieść , ale klasyczna.
Wrikken
To „kilka dni” (lub co najmniej kilka godzin) badań skutkujące bardzo ważną, ale poprawką pojedynczej linii, zdarza się dość często z mojego doświadczenia.
Johan