Żyjemy w czasach, kiedy hasło ”big data” nie jest już niemal dla nikogo obce. Każdy nasz krok, każde spojrzenie jest analizowane przez niezliczone systemy informatyczne. Statystyki z naszych przeglądarek pozwalają na tworzenie spersonalizowanych reklam. Dlaczego więc nie używamy danych, które dostarczają nam własne repozytoria do polepszenia pracy naszych zespołów?
Zastanawiałeś się kiedyś, kto jest liderem twojego projektu, albo jaki wkład w rozwój kodu mają poszczególni programiści? A może zastanawiałeś się kiedyś w jakich godzinach planować spotkania, tak żeby pasowało to większości zespołu? W tym artykule postaram się udowodnić, że na te i wiele innych pytań może odpowiedzieć analiza historii repozytorium nad którym pracujecie.
W tym artykule skupmy się nad najpowszechniejszym narzędziem do kontroli wersji, a jest nim GIT. Jeśli nie wiesz czym jest GIT najłatwiej będzie jeżeli spytasz jednego ze swoich programistów, albo wujka Google :). Jak każdy system kontroli wersji GIT pozwala na przeglądanie historii zmian repozytorium. Historia ta zawiera nie tylko informację o zmianach, ale także o tym kto te zmiany wprowadził, dokładną datę ich dołączenia do repozytorium oraz wiele innych cennych informacji. Większość narzędzi do hostowania repozytoriów gitowych (GitLab, GitHub, BitBucket) zapewniają podstawowe funkcje do analizy historii repozytorium.
Contributors GraphPodstawową i najłatwiejszą w zrozumieniu funkcjonalnością jest tak zwany „Contributors Graph”, pozwala on na odnalezienie najbardziej aktywnych członków zespołu pracującego nad danym repozytorium. Ten wykres pozwala także na podejrzenie jak ilość commitów (lub linii dodawanych bądź usuwanych z repozytorium) rozkładała się w czasie od momentu powstania danego projektu. Często ta informacja pozwala zidentyfikować problemy z którymi zmagają się programiści. W źle zorganizowanych zespołach można z łatwością zauważyć wzrost liczby commitów tuż przed, bądź w momencie releasu nowej wersji oprogramowania (bądź nowej funkcjonalności). Taka sytuacja często zdarza się też w projektach open-source nad którymi programiści pracują po godzinach i zazwyczaj ciężko jest im zdążyć dokończyć wszystkie funkcjonalności przed planowanym releasem. Zachowanie takie będzie objawiać się lokalnym maksimum widocznym na grafie kontrybucji, w okolicach daty wypuszczenia nowej wersji oprogramowania. Co zrobić z takimi danymi zostawiam wam do rozważenia, może warto poruszyć ten temat z zespołem? Z doświadczenia wiem, że zazwyczaj programiści są świadomi problemu ale sami boją się do niego przyznać.
Punch card GraphCiekawszym i potencjalnie bardziej informacyjnym wykresem jest ”Punch card graph”. Niestety od ręki jest on dostępny tylko na GitHubie, ale bez problemu można użyć jednego z dostępnych narzędzi do wygenerowania wspomnianego wykresu. Karta perforowana (ciekawe skąd wzięła się ta nazwa ;)? ) mówi o tym w jakich dniach i godzinach najczęściej wprowadzane są zmiany do repozytorium. W większości projektów nad którymi pracują programiści zatrudnieni na miejscu w firmie na umowę o pracę ten wykres powinien być bardzo przewidywalny. Największe okręgi powinny pojawiać się w dniach roboczych od godziny 9 do 15-16. Okazuje się jednak, że w wielu wypadkach tak nie jest. Programiści to przecież nie maszyny. Z najczęściej występujących aberracji daje się zauważyć zmniejszona aktywność zespołu w godzinach między 12 a 13 (nienaruszalna godzina obiadu w każdej firmie :) ) oraz przerwy w aktywności na tak zwane spotkania scurmowe (oczywiście tylko w zespołach pracujących w scrumie). Na tym wykresie z łatwością można również zauważyć kiedy nie powinno się przeszkadzać programistom pochłoniętym procesem twórczym, a kiedy warto umówić spotkanie, które pozwoli na chwile odpoczynku. A co jeżeli programiści pracują zdalnie? Wtedy punch card pozwala na kontrolowanie ich pracy. Z łatwością można zauważyć czy wynajęty zespół rzeczywiście pracuje tak jak zadeklarował to w umowie.
Code frequency graph
Każdy doświadczony programista stara się trzymać podstawowej zasady: kod który dotyka powinien zostawić czystszym niż był przed zaaplikowaniem swoich zmian. Ten proces nazywamy refaktoringiem kodu. Jeżeli zespół zaniedba swój kod, może okazać się, że dodanie nowej funkcjonalności, bądź zmiana starej może w przyszłości kosztować exponencjalnie więcej czasu, niż w przypadku kiedy kod byłby jasny i przejrzysty. Taka sytuacja charakteryzuje się znaczną, nieproporcjonalną szybkością przyrostu linii kodu. Wraz ze wzrostem ilości kodu, rośnie też jego skomplikowanie, a co za tym idzie rośnie czas wprowadzania zmian funkcjonalnych. W tym momencie do akcji wchodzi „Code frequency graph”, który w łatwy i przystępny sposób prezentuje stosunek ilości linii dodanych do repozytorium do linii z niego usuniętych. Mając takie informacje team-leader (scrum-master, product-owner, etc.) bez problemu może zarządzić zamrożenie nowych funkcjonalności, w celu zwiększenia jakości kodu nad którym pracuje zespół.
Mam nadzieję, że po przeczytaniu tego artykułu chociaż garstka z was usiądzie przed komputerem wejdzie na stronę swojego repozytorium i przeanalizuję za- 3 kładkę ”Graphs”. Te informacje są tylko wierzchołkiem góry lodowej informacji, które można wyciągnąć z historii repozytorium. Mam nadzieję, że potraktujecie te przykłady jako wstęp do rozwijania wiedzy o swoim repozytorium i przyjrzycie się dokładniej co o Waszej pracy mówią commity każdego z pracowników :)
Krzysztof Studniarek, Starszy Analityk IT w mBanku, 20 lutego 2017