Używasz wyników ciągłej kompilacji jako części wskaźników przeglądu wydajności? [Zamknięte]


11

Mój szef planuje wykorzystać dane z naszej ciągłej kompilacji (buduje i uruchamia testy przy każdym zatwierdzeniu) jako część naszych przeglądów wydajności (w naszej metodzie „jakości”). Wydaje mi się to NAPRAWDĘ złym pomysłem, ale chciałbym wiedzieć, czy ktoś to studiował, czy widział wcześniej.

Myślę, że nasi programiści nie będą poddawać się tylu testom, jak w innym przypadku, z obawy, że testy się nie powiodą. Wydaje mi się, że zamienia cenne narzędzie programistyczne w kij, którym można pokonać programistów.

Oczywistym kontrargumentem jest to, że zachęci to ludzi do większej ostrożności przed popełnieniem, a tym samym do wyższej jakości.

Czy jestem tu poza bazą? Proszę odłożyć na bok pytanie, czy powinniśmy w ogóle robić oceny wydajności, czy też nie - na co odpowiedziano gdzie indziej.


8
Każdy system, w który można grać, jest strasznym wkładem w ewaluację wydajności.
Steve Jackson,

Każdy ma opcję nie testowania?
JeffO,

1
@ Steve, a „systemy”, z którymi nie można grać, dają ci wąski wąski obraz większego obrazu. Naprawdę dokładne śledzenie wydajności wymagałoby pracy nóg.
wałek klonowy

2
Zauważ, że niektóre rzeczy działają dobrze na komputerach programistów, ale zawodzą na serwerze kompilacji (przypadkowa zależność od zewnętrznego słoika, niewłaściwy sposób użycia / i \ na pudełkach Linuksa itp.). Głównym powodem serwera kompilacji jest wyłapanie tych rzeczy, a nie nękanie innych za to, że nie testują ich najpierw. Innymi słowy, to zły pomysł.

1
Dalsze działania: po tym, jak to zrobiliśmy, zauważyłem, że największy problem nie miał nic wspólnego z innymi inżynierami i chęcią napisania odpowiednich testów, ale raczej z faktem, że nasze istniejące testy były NAPRAWDĘ niestabilne, więc każde zatwierdzenie miało całkiem spore szanse przełamanie bez winy osoby dokonującej zatwierdzenia. Ten czynnik osłabił entuzjazm wszystkich do testowania znacznie bardziej niż jakichkolwiek efektów przeglądu wydajności.
Michael Kohne,

Odpowiedzi:


7

Przeglądy wydajności są w porządku, ale co z przydatnymi danymi, takimi jak:

  • Procent pokrycia testem jednostkowym funkcji
  • Możliwość dotrzymania terminów
  • Jasna i zwięzła dokumentacja
  • Przestrzegaj odpowiednich konwencji kodowania
  • Dobrze komunikuje się z innymi
  • Możliwość przekształcania wymagań i historii użytkowników w zadania

Są to wszystkie dobre sposoby mierzenia wydajności, ale problemy, jakie wydaje się mieć przy zarządzaniu, polegają na tym, że w rzeczywistości wymagają ... ummm ... no cóż, wiesz ... AKTYWNA PRACA z ich strony.

Niestety większość kierownictwa ma takie podejście: „Do diabła z tym, chcę oceniać moich pracowników na podstawie wskaźników, które tak naprawdę nie wymagają ode mnie nadążania za tym, co robią”.


1
+1 za dostarczanie kilka dobrych wyborów co metryki użyteczne.
David Ruttka,

3

Moim zdaniem granie w system tutaj jest całkiem prawdopodobne, a twój szef musi znaleźć sposoby, aby temu zapobiec. Innym przypadkiem, o którym nie wspomniałeś, jest to, że programiści dokonują mnóstwa razy, dzięki czemu następuje zalew odpraw, w którym liczba modyfikacji jest stosunkowo niska, tak jakby była część recenzji, w której używana jest liczba kompilacji jest to miejsce, w którym staje się to nowe narzędzie, które można łatwo wykorzystać w niewłaściwy sposób. Myślę o odprawach, w których zmienia się nazwę czegoś lub zmienia się białe miejsce, jest odprawą i liczy się, ponieważ jakaś forma wydajności byłaby pedantycznym poglądem.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.