Code Review – dlaczego tak trudno o dyscyplinę?

Jest wiele powodów, dla których utrzymanie dyscypliny i regularność przeprowadzania inspekcji kodu nie jest zadaniem łatwym. W tym krótkim wpisie chciałem przyjrzeć się bliżej jednemu, ale za to takiemu, którego miałem okazję doświadczyć z trzech różnych perspektyw.

  • Jako autor kodu, przeglądanego w ramach Code Review
  • Jako reviewer, przeglądając kod koleżanek i kolegów z zespołu
  • Jako Scrum Master, obserwując pracę zespołu developerskiego z boku

Wymówką #1 był zawsze brak czasu. Nie robimy lub przestajemy robić regularne Code Review, bo nie mamy czasu. Co więcej, nie mamy czasu nie tylko na to, by przejrzeć kod, ale również, żeby wprowadzić konieczne poprawki zidentyfikowane wcześniej. Prędzej czy później przychodzi moment otrzeźwienia, w którym zadajemy sobie pytanie „jak mogliśmy w ogóle do tego dopuścić?” i odkrywamy, że utknęliśmy w błędnym kole, które wygląda mniej więcej tak.

Błędne koło

  1. Odkładamy w czasie Code Review, bo jesteśmy zajęci (naprawianiem bugów lub pędzeniem na oślep byle zdążyć przed deadlinem)
  2. Ilość kodu czekającego na przejrzenie rośnie
  3. Im więcej kodu do przejrzenia tym naturalnie łatwiej o pomyłkę…

…ale przede wszystkim…

im więcej kodu do przejrzenia, tym większy opór wewnętrzny przed wprowadzaniem grubszych, ale koniecznych zmian

  1. Jakość kodu oraz produktu spada
  2. Pojawia się więcej bugów
  3. Goto 1 – wracamy do punktu wyjścia

Na postawę z punktu trzeciego mogą mieć wpływ dwa bardzo bliskie sobie błędy poznawcze, które przyjęło się nazywać efektem przywiązania (commitment bias/attachment effect) oraz efektem utopionych kosztów (sunk cost fallacy).

„Commitment bias is the tendency to be consistent with what we have already done or said we will do in the past, particularly if this is public.”

Association for Qualitative Research Glossary

Sunk costs are a favorite subject of economists. Simply put, they are payments or investments which can never be recovered. An android with fully functioning logic circuits would never make a decision which took sunk costs into account, but you would. As an emotional human, your aversion to loss often leads you right into the sunk cost fallacy.”

You Are Not So Smart

Mamy zatem tendencję do takich zachowań i postaw, które będą spójne z tym, co zrobiliśmy w przeszłości, a niechęć do zmiany obranego wcześniej kierunku jest tym większa im więcej „zainwestowaliśmy” już w dane przedsięwzięcie. Taki mechanizm może mieć miejsce w przypadku Code Review, gdzie inwestycją jest czas i wysiłek poświęcony na napisanie nowego kawałka kodu.

Wiele razy łapałem się na tym, że dużo trudniej było mi wywrócić do góry nogami naraz jakiś większy fragment kodu. Wiedziałem jednocześnie, że gdybym konieczne zmiany wprowadzał regularnie i na bieżąco, nie byłoby to takie bolesne. Podobne zdanie wyraziło również wielu programistów, z którymi na ten temat rozmawiałem.

Jak temu zaradzić?

Odpowiedź nasuwa się sama. Przerwać błędne koło robiąc częściej Code Review. Dziękuję Kapitanie Oczywistość. Tylko jak często?

Z badania przeprowadzonego przez SmartBear Software (2500 inspekcji obejmujących 3.2 miliony linii kodu na przestrzeni 10 miesięcy) wynikają następujące rekomendacje:

  • 200-400 linii kodu to optymalna ilość do przejrzenia w ramach jednej inspekcji
  • Tempo większe niż 500 linii/godzinę powoduje znaczny spadek wykrywalności błędów
  • Sesje dłuższe niż 60 minut negatywnie wpływają na skupienie uwagi i wydajność

Oczywiście liczby te będą się wahać mniej lub bardziej w jedną, lub drugą stronę w zależności od wielu różnych czynników. Niemniej ogólna prawidłowość nakazuje traktować Code Review jako jeszcze jedną pętlę sprzężenia zwrotnego, fundament zwinnego podejścia.

By DonWells [CC BY 3.0 (https://creativecommons.org/licenses/by/3.0)], from Wikimedia Commons

Pair programming jako Code Review w czasie rzeczywistym

Na koniec chciałbym przywołać jeszcze jedno z moich ulubionych podejść jakim jest spojrzenie na Pair Programming jak na Continous Code Review (czyli Code Review odbywającego się „w czasie rzeczywistym”). Praca w parach nie musi (i nie powinna) zastąpić formalnej sesji inspekcji kodu, ciężko natomiast wyobrazić sobie krótszą (a tym samym tańszą) pętlę sprzężenia zwrotnego. Zatem jeśli zależy nam na wbudowywaniu jakości w produkt jak najwcześniej jak to możliwe, powinniśmy znaleźć równowagę między jednym i drugim podejściem.

http://www.ambysoft.com/artwork/comparingTechniques.jpg

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *