Dzisiejszym wpisem odbiegnę trochę od typowego dla mojego bloga technicznego bełkotu. Zamiast tego skupię się dziś bardziej na zagadnieniu związanym z samym procesem (cyklem?) wytwarzania oprogramowania. Jak możecie przeczytać w nagłówku, dziś postaram się odpowiedzieć na pytanie dlaczego warto praktykować Code Review.

W większości firm tworzących soft, w której przykłada się wagę do jakości tworzonego oprogramowania prowadzona jest praktyka Code Review. W mojej osobistej karierze zawodowej, tak na prawdę zetknąłem się z tym zagadnieniem dopiero odkąd rozpocząłem pracę w Objectivity. A jako, że pracuję już tutaj prawie dwa lata, nabrałem już w przeprowadzaniu przeglądów kodu trochę praktyki. Zebrałem więc na ten temat trochę swoich spostrzeżeń, którymi postanowiłem się w tym miejscu podzielić.

Co to takiego?

Dla tych wszystkich, którzy nie zetknęli się wcześniej z tym zagadnieniem lub słyszeli, ale nie do końca są pewni, o co chodzi, krótka definicja. Przegląd Kodu (ang. Code Review) polega mniej więcej na tym, że po zakończeniu implementacji jakiegoś konkretnego kawałka funkcjonalności, zwykle przed „wbitką” zmian do systemu kontroli wersji, pokazujemy nasz kod koledze z zespołu do oceny. Jeśli ocena wykonanej pracy wypadnie pozytywnie, możemy „zacommitować” zmiany. Jeśli natomiast nasz recenzent ma uwagi, musimy niestety wprowadzić poprawki i poprosić o ocenę ponownie. Dla porządku dorzucam jeszcze link do definicji Code Review w wikipedii.

Dla kogoś, kto nigdy nie miał z Code Review do czynienia, powyższa definicja może brzmieć groźnie… Większość osób nie lubi być poddawana ocenie i może odbierać to osobiście. Jednak jeśli zrozumie się cel i sens tej praktyki, można dojść do wniosku, że to jedno z bardziej przydatnych „narzędzi” pozwalających tworzyć dobre oprogramowanie.

Dlaczego warto praktykować Code Review?

No więc dlaczego warto praktykować Code Review? Na początku wpisu wspomniałem coś, o jakości kodu… Myślę, że ten wniosek jest najprostszy do zauważenia. Jeśli ktoś, najlepiej bardziej doświadczony od nas, spojrzy na nasze „wypociny”, na pewno znajdzie wiele miejsc, gdzie może zaproponować inne, lepsze rozwiązanie danego problemu. Poza tym osoba taka może zauważyć miejsca, w których nie do końca trzymaliśmy się dobrych praktyk programistycznych i nam je wytknąć. Dzięki temu, po takich poprawkach kod będzie na pewno o wiele lepszy.

Można też na to spojrzeć z innej strony. Jeśli Code Review prowadzone jest bezwzględnie przed każdym „commitem” do repozytorium (a moim zdaniem tylko tak powinno to wyglądać, jeśli chcemy mieć z tego jak największe korzyści), to dzięki temu każdy członek zespołu może zapoznać się z obszarami systemu, z którymi normalnie by się nie zetknął. Przecież podczas pracy nad dużymi projektami, często możemy utknąć przy jednej części systemu na dłuższy czas. Taka prośba o przegląd od kogoś pracującego nad czymś innym jest świetną okazją do zapoznania się z jego „odcinkiem”.

Jest też trzeci powód, który mi się w tym momencie nasuwa. Poniekąd wynika z pierwszego przytoczonego przeze mnie powodu. Jest to możliwość nauki od innych, często lepszych od siebie. I jest to nauka na wielu poziomach: jedno to zapoznanie się z zastosowaniem w praktyce wzorców projektowych (jako wspomniane wcześniej usprawnienie naszego rozwiązania danego problemu), czy wykorzystanie nowej technologii ale nawet tak prosta, wydawałoby się rzecz, jak poznawanie nowych, nieznanych nam wcześniej skrótów Resharpera… Ile to razy ja komuś przeglądam kod, lub ktoś mi, pada pytanie „Ooo, a jak to zrobiłeś?! Jaka to kombinacja klawiszy??!!”

Zdaję sobie sprawę, że powodów, dla których warto przeprowadzać Code-Review jest więcej, tyle przyszło mi do głowy tak na szybko… Jeśli chcecie, możecie się podzielić swoimi przemyśleniami na temat w komentarzach ;)

Jak?

Skoro wiemy już mniej więcej, dlaczego warto praktykować Code Review, warto wspomnieć jeszcze jak dobrze to robić. Jest wiele szkół i podejść do tego tematu… Jedni podchodzą do tego zbyt „olewatorsko” inni z kolei za bardzo skupiają się na szczegółach i są zbyt czepialscy. Ja uważam, że należy znaleźć „złoty środek”. Moim zdaniem byt pobieżne review nie zapewni odpowiedniej jakości kodu i do repozytorium mogą się prześliznąć przeróżne kwiatki. Z kolei, jeśli recenzent jest przesadnie szczegółowy, może to opóźnić zakończenie zadania. Istniej też ryzyko spowodowania niebezpieczeństwa, że nie uda się wykonać wszystkiego, co zostało zaplanowane na daną iterację. Sam w mojej karierze zetknąłem się z sytuacją, że „developowałem” coś przez pół dnia, a następne dwa dni spędzałem na poprawkach po review… W takich przypadkach, myślę, że ważne jest aby inni członkowie zespołu (w tym PM lub Scrum Master, jeśli pracujecie w Scrum’ie) potrafili takie sytuacje wychwycić i odpowiednio zareagować ;)

Na co zwracać uwagę

To tyle, jeśli chodzi o moje przemyślenia na temat ogólnego podejścia do review. Warto do tego dorzucić trochę konkretów, czyli listę rzeczy, na które powinno się zwracać uwagę recenzując czyiś kod:

Błędy logiczne

Czasem zdarza nam się zrobić prosty błąd pisząc porównanie wartości w instrukcji „if”, kod działa dla danej ścieżki testowej i wydaje nam się, że wszystko jest OK, a wystarczy, że spojrzy na to ktoś inny i od razu wychwyci, że to i to nie będzie działać w takim a takim przypadku

Nazewnictwo zmiennych, czytelność kodu

Pisanie kodu, który mówi sam za siebie jest bardzo ważne w późniejszym jego utrzymaniu, dlatego warto zwracać uwagę czy wszystkie nazwy zmiennych dobrze określają swoje przeznaczenie; to samo tyczy się takich kwestii jak odpowiednie wcięcia, nawiasy klamrowe itp. (tego wszystkiego dobrze jest pilnować takimi narzędziami jak StyleCop i FxCop ale mimo wszystko warto być czujnym również podczas review)

Potencjalni kandydaci do refactoringu

Jeśli widzimy, że ktoś napisał metodę na trzy ekrany to jak dla mnie jest to naturalny kandydat do rozbicia tego na mniejsze logiczne kawałki. Jeśli widzimy rozbudowaną „ifologię” to może warto (jeśli się da) zaproponować przepisanie tego na strategię? To tylko najprostsze przykłady, wszystko oczywiście zależy od kodu, który recenzujemy

Komentarze

Tutaj w zależności od podejścia, jeśli stosujecie zasadę samo-komentującego się kodu to ta zasada może Was nie dotyczyć. Jednak jeśli macie (tak jak u mnie) wymóg komentowania wszystkich właściwości i metod publicznych w klasie i stosujecie do tego narzędzie typu GhostDoc lub Atomineer, to warto też zwrócić na te komentarze uwagę, bo „toole” te często potrafią wygenerować dość śmieszne ale niestety niepoprawnie gramatycznie teksty, nie mówiąc już o tym, że mogą one być niewystarczające do opisania tego, co dana metoda lub właściwość rzeczywiście robi

Testy jednostkowe

Po pierwsze czy w ogóle są… a jeśli tak, to czy rzeczywiście testują to, co mają testować… Można przecież napisać testy, które teoretycznie pokrywają 100% funkcjonalności a tak naprawdę nie testują niczego…

Złożoność obliczeniowa / performance

Często widać na pierwszy rzut oka, że dana metoda jest napisana mało wydajnie. Zawsze warto na to od razu zwrócić uwagę zamiast czekać do fazy testów wydajnościowych

Tak jak w poprzednim paragrafie, na pewno to nie wszystkie sprawy, które trzeba kontrolować. Są to jedynie te, które uważam za najważniejsze. Jeśli chcecie coś do tego dodać, zapraszam do komentowania pod postem!

Podsumowanie

Mam nadzieję, że tym wpisem wyjaśniłem dlaczego warto praktykować Code Review. Moim zdaniem dobre Code Review jest na wagę złota! To naprawdę podnosi zarówno jakość kodu jak i umiejętności programistów i to w dość krótkim czasie – czuję to po sobie. Moim zdaniem ważne jest też, żeby podchodzić do tego ze zdrowym rozsądkiem i nie demonizować. To nie może być coś, czego się ludzie boją, wręcz przeciwnie jest to miejsce do chwalenia za innych za dobrze wykonaną robotę! A jak jest w waszych firmach w tej kwestii?