Code review – dlaczego to jest takie ważne?

Code review – dlaczego to jest takie ważne?

Cześć Wam! Tydzień temu miałem przyjemność opublikować post o tematyce biegowej, więc dzisiaj ruszam z tematyką programowania. Zapraszam.

CODE REVIEW

Krótka notka dla osób które nie wiedzą, co to jest code review (więc jeśli wiesz co to jest, możesz pominąć ten akapit). Jak sama nazwa wskazuje, jest to sprawdzenie kodu przez kolegę z zespołu. Code review to najczęściej stosowane rozwiązanie ale niestety istnieją również zespoły, w których nikt kodu nie sprawdza, a programista wrzuca kod do głównej gałęzi na „słowo harcerza” co jest moim zdaniem złą praktyką. W systemach takich jak np. github administrator projektu może z góry ustawić ograniczenia, które uniemożliwią dołączenie kodu do określonej gałęzi bez uzyskania np. jednego, dwóch lub więcej "zatwierdzeń" (approve) od kolegów z zespołu. Code review polega na sprawdzeniu kodu pod względem jakości, powtórzeń, nazw czy odpowiedniego formatowania, nie wspominając już o tym, że kod po prostu musi spełniać wymagania funkcjonalne – czyli ma działać.

      Pewnie niejednokrotnie spotkaliście się już z uczuciem, że skończyliście zadanie, wystawiliście pull/merge requesta, z uśmiechem na twarzy przeciągając w JIRZ-e kolejne zadanie jako “in progress” aż tu nagle gong, powiadomienie z githuba  “Changes requested”…czyli koledze z zespołu coś się nie podoba 🙂 Przejdźmy razem przez najczęściej spotykane sytuacje.

Źródło: https://moodup.team/

Po co mam to poprawiać? Przecież mój kod działa

     Moim zdaniem code review to jedna z najlepszych form nauki. Kiedy dostajemy komentarze do naszego kodu powinniśmy się cieszyć – poważnie. Możemy ocenić swoje umiejętności na kodzie, który sami napisaliśmy i powinniśmy go rozumieć w stu procentach. Kiedy dostajemy sensowne komentarze z prośbą o zmianę, mamy szansę stać się lepszymi programistami, bo ktoś zwrócił nam uwagę na coś o czym wcześniej nawet nie pomyśleliśmy. Często żyjemy w przeświadczeniu, że rozwiązanie X jest najlepsze ale kolega z zespołu może nas uświadomić wskazując jeszcze lepsze rozwiązanie. Kiedy w projekcie każdy pull/merge request dołączany jest do głównej gałęzi bez jakichkolwiek komentarzy to znaczy, że coś jest nie tak…albo jest to projekt uczelniany 🙂

Kolega się na mnie uwziął, już czwarty raz każe zmieniać mi nazwę metody…

     Oczywiście mogą zdarzyć się przypadki, kiedy kolega z zespołu ma gorszy dzień i na siłę wymyśla zmiany. Co wtedy robić? Zamiast narzekać pod nosem  polecam szybkie i skutecznie rozwiązanie – czyli rozmowę z osoba która nam ten kod sprawdziła. Kiedy to nie poskutkuje problem najlepiej zgłosić Scrum Masterowi czy osobie odpowiedzialnej za projekt. I proszę – nie mylcie tego z kablowaniem. Bo przecież nie będziecie pisać, że “Marek chyba wyszedł z pracy godzinę wcześniej niż powinien” a o sprawie która jest fundamentalna. Nękanie poprzez code review może mieć poważne skutki na dalszy rozwój projektu. Pamiętajcie, że w tym procesie nie chodzi o czepianie się na siłę czy „wrzucę jakikolwiek komentarz byleby było, że coś robię”. Przyznam jednak, że z takimi skrajnymi przypadkami jeszcze osobiście nigdy się nie spotkałem ale słyszałem kilka takich historii.

Pull requesta wystawił mój o wiele bardziej doświadczony kolega, nawet nie sprawdzam i klikam approve

     Bardzo złe podejście. To, że pull requesta stworzył kolega z większym doświadczeniem to nie znaczy, że napisany przez niego kod jest bezbłędny. Po pierwsze: analizując kod lepszego programisty od nas możemy się dużo nauczyć. A po drugie: nie myli się tylko ten, kto nic nie robi. Nie bójcie się analizować kodów osób bardziej doświadczonych od Was i zgłaszać poprawki.

Po co sprawdzać kod? Przecież doskonalić można bez końca…

     To nie do końca prawda. Najpewniej znajdzie się ktoś kto stwierdzi, że napisałby dany fragment kodu w lepszy sposób – niemniej jednak nadal uważam, że code review jest bardzo potrzebne. W omawianym procesie na pewno nie chodzi o to, by na siłę szukać lepszych rozwiązań. Chodzi o ogólne spojrzenie, sprawdzenie czy kod pod względem logicznym jest w porządku. Ważne jest też, by osoba niezwiązana z projektem czytając napisane oprogramowanie mogłaby się w tym bez problemu rozeznać. 

Podsumowanie

     Podsumowując pamiętajcie jak ważną role w projekcie czy we własnym rozwoju może pełnić code review. Jeśli w waszym zespole nie ma takiej praktyki – wdróż ją 🙂 To świetna odskocznia w ciągłym pisaniu kodu czy „wiszeniu” na callach. Uważnie sprawdzając kod można nie tylko znaleźć błędy czy rzeczy do polepszenia ale też sporo się nauczyć. I proszę, nigdy nie traktujcie komentarzy do kodu jako atak personalny na waszą osobę.

 

                                                                                                                                                                                         Pozdrawiam serdecznie,
                                                                                                                                                                                         biegajacyprogramista.pl

Dodaj komentarz

ten + 8 =

Close Menu