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