[Rekrutacja: Kawa na ławę] Kod

W dzisiejszym wpisie spójrzmy na kod. W końcu po to dołączamy do projektu IT, aby brać udział w rozwijaniu kodu.

Na rozmowie raczej nie usłyszysz słów “nasz kod źródłowy jest słaby”. Raczej padną okrągłe zdania o wyzwaniach i planach na przyszłość.

Moje zdanie w tym temacie jest następujące: gdy ktoś lubi porządek, to ten porządek ma. Gdy ktoś jest bałaganiarzem, to będzie bałagan. Tak samo działa to z kodem – nie ma takiej magii, że nagle projekt zrobi się cudowny. Do tego konieczna jest całkowita zmiana na poziomie managerskim.

Ten post jest częścią serii Rekrutacja: kawa na ławę.

Jak zatem łatwo wysondować, jaki kodzik w projekcie produkują? Najlepiej byłoby zajrzeć do repozytorium, ale to może okazać się niemożliwe ze względów formalnych. Poza tym, nawet gdyby ktoś udostępnił kod źródłowy, to nie wiadomo czy to cała prawda. Może zostały nam pokazane najlepsze fragmenty, a na co dzień wylądujemy w zupełnie innym miejscu?

Jak widać, pytania wprost niezbyt tutaj działają. Ale spróbujmy popytać nie wprost.

Jaki system kontroli wersji jest używany?

Zacznijmy niewinne. W programowaniu jest bardzo mało przypadków, gdy wybór jest całkowicie jasny, taki zero-jedynkowy. Zazwyczaj poprawna odpowiedź brzmi “To zależy!”, a eksperta poznaje się po tym, że wie od czego coś zależy. Jednak w przypadku systemu kontroli wersji odpowiedź jest jedna: Git.

Bardzo daleko mi do ekstremizmu w technologiach, ale w tej kwestii wiem, że Git wyprzedza swoich rywali. Miałem okazję pracować dość długi czas z SVN, TFVC i Git. Poznałem te systemy dobrze, bo profesjonalnie migrowałem duże repozytoria z TFVC/SVN do Git.

Tak, to prawda, że są takie funkcjonalności w TFVC, których Git nie ma i mieć nie będzie. Są też takie, że do Git’a trzeba doinstalować dodatki. Ale praktyka jest taka, że żaden inny system nie ma tak szerokiego wsparcia od strony narzędzi i społeczności. Git to jest must-have udanego projektu.

Jeśli w projekcie jest coś innego niż Git, zapytałbym o powód i o plany na przyszłość. Jaki jest powód, że jeszcze nie używacie Git’a? Jaka jest polityka firmy w tym zakresie?

Czy wykorzystywana jest statyczna analiza kodu? Jak duży jest dług techniczny oraz technologiczny projektu?

Często na pytanie o jakość kodu odpowiedź będzie wymijająca, bo zespół sam tego nie wie. Dlatego dobrze mieć narzędzia, które obiektywnie to zmierzą. Można łatwiej wykrywać problemy w kodzie, zespół bardziej dba o jakość (niwelujemy efekt stłuczonej szyby), a przede wszystkim wszyscy wiemy na czym stoimy.

SonarQube i alternatywne rozwiązania są również doskonałym orężem w rękach biznesu. Krótko pisząc, gdy słyszę, że jest SonarQube, to wiem, że raczej będzie szło w dobrą stronę.

Warto na tym etapie dopytać również o stopień aktualności używanych bibliotek i narzędzi.

Ile czasu zajmie uruchomienie aplikacji na świeżej maszynie deweloperskiej?

Tutaj lekko zapytamy o to, jak będą wyglądały nasze pierwsze kroki w projekcie. Jest to również pytanie o to, jak jakościowo projekt się prezentuje.

Jeśli odpowiedź brzmi: “Jak Zbyszek, nasza projektowa złota rączka, znajdzie dla Ciebie chwilę, to w 4 dni wszystko postawisz”, to chyba najlepiej nie jest. I raczej daleko temu projektowi do pięknego pipeline CI/CD.

Jeśli odpowiedź brzmi: “Tutaj masz link do naszego repozytorium, ściągnij i odpal projekt” (czyli jakieś 30 minut), to pewnie aplikacja jest w niezłej kondycji.

Jak wygląda testowanie aplikacji?

Przy okazji tego punktu możemy dowiedzieć się, jak bardzo zespół dba o jakość. Zapytajmy o kilka ważnych rzeczy. Jaki % kodu pokryty jest testami jednostkowymi? Ile ścieżek biznesowych pokryte jest testami E2E? Ile czasu zajęłoby postawienie od zera nowego środowiska testowego? W jakim stopniu proces deploymentu jest zautomatyzowany? Jak bardzo proces deploymentu rózni się pomiędzy środowiskami? Czy mamy na pokładzie Continuous Integration? Czy zespół stosuje TDD jako codzienną praktykę?

Czy kod jest recenzowany?

Jak wygląda Code Review w projekcie? Zerknięcie przez ramię i klepnięcie zgody czy współpraca nad jakością rozwiązania? Czy są ustawione polityki na branchach (PR, Gated Checkin)?

Jakie narzędzia pomocnicze są stosowane w projekcie?

Jakiego serwera buildów używa zespół (Jenkins, VSTS, AppVeyor, …)? Jakie narzędzie wspomaga zarządzanie pracą (VSTS, Jira, Bitbucket, …)?

Podsumowanie

Jak widać, pytać można o wiele aspektów i każdy z nich zdradzi pewne szczegóły i fakty. Chcąc uzyskiwać odpowiedzi szczere warto zadawać pytania otwarte i moderować dyskusję w odpowiedni sposób.

Jeśli chodzi o sama kondycję projektu, to warto pamiętać, że kluczowe jest nastawienie i chęć poprawy. Wiadomo, że najwdzięczniejszym projektem do pracy będzie ten innowacyjny i korzystający ze świeżych technologii. Jednak nie warto odrzucać również projektów w słabej kondycji, ale takich, gdzie management bardzo chce poprawić stan rzeczy i właśnie w tym momencie szuka człowieka, który podejmie się takiego zadania.

Najmniej przyjemna, z punktu widzenia własnego rozwoju kompetencji, jest sytuacja, gdy projekt jest zapuszczony, a management i zespół uważają, że wszystko jest OK. Takich projektów bym unikał.