W niniejszym artykule przybliżę zagadnienie przeglądu kodu (ang. code review) w sposób… z lekka nietypowy. Samo code review jest tematem z wszech miar technicznym, inżynierskim. Moim celem jest przybliżenie tego zagadnienia osobom nietechnicznym na przykładzie kodu, który jest faktycznie… tekstem recenzji pewnej książki, którą ostatnio przeczytałem.
Na wstępie warto przybliżyć, czym jest przegląd kodu. W bardzo dużym uproszczeniu – kiedy programista napisze pewien spójny kawałek funkcjonalności w formie kodu, prosi inną osobę z zespołu, innego programistę, o jego ocenę. Jeżeli ocena będzie pozytywna, to kod jest dołączany do pozostałej części kodu oprogramowania, natomiast jeżeli ocena będzie negatywna, kod należy poprawić i przedstawić do oceny ponownie. Jeżeli mój wywód jest nieczytelny/nieprzekonywujący, z całą pewnością Google przyjdzie z pomocą – chociażby pierwsza z brzegu definicja code review z Wikipedii (tutaj).
Wiemy już, czym jest code review, zatem do dzieła. Spójrzmy, jak to działa i jaką może z sobą nieść wartość. Nie jestem programistą, zatem na kodzie napisanym w Javie Wam tego nie pokażę, ale mogę pokazać w inny sposób. Jaki? Tak się składa, że przeczytałem ostatnio książkę Davida Allena „Getting Things Done, czyli sztuka bezstresowej efektywności”. Wyszukałem recenzję powyższej pozycji (tutaj) i na niej oprę swój przegląd.
Przegląd kodu posiada kilka warstw. Zacznijmy od jednej z pierwotnych. Na tym etapie autor recenzji przygotowywał już swój wstępny tekst. Był zapewne taki moment, w którym uznał, że jest gotowy, żeby pokazać swoje dzieło innej, zaufanej osobie. Wtedy wkracza druga osoba poproszona przez autora o przegląd. Na tym etapie mogą jeszcze wystąpić drobne niedoróbki (np. błędy interpunkcyjne lub gramatyczne) i to jest moment na ich poprawę. Poza tym, to już kolejna warstwa, weryfikowane są błędy merytoryczne oraz obszary niezrozumiałe dla czytającego. Ciekawe kwestie pojawiają się w kolejnych warstwach.
Pisanie recenzji książek, podobnie jak programowanie, jest pracą twórczą. Recenzję książki, podobnie jak kod programu rozwiązujący dany problem, można napisać na wiele sposobów. I tu zaczyna się zabawa – podczas takiego przeglądu masz możliwość spojrzenia na dane zagadnienie z różnych perspektyw. Z pewnymi stwierdzeniami autora kodu/recenzji można polemizować, co prowadzi do dyskusji. Odnosząc się wprost do konkretnej recenzji książki, nie jestem do niej tak entuzjastycznie nastawiony jak jej autor. Jednak trudno z tym polemizować, czy kwestionować czyjąś fascynację książką. Zawierała ona szereg bardzo ciekawych praktycznych zagadnień, które podsumuję je w dalszej część. Niestety, w moim odczuciu książka miała także momenty, w których czułem się tak, jakbym czytał opis ciężkiej metodyki w stylu PRINCE 2, gdzie nawet dokumentacja jest… produktem. Tak było przy szczegółowym opisie metody Getting Things Done (GTD). Na szczęście takich momentów w całej książce nie było wiele.
Ważne jest to, na co także zwraca uwagę autor recenzji, że nie ma konieczności wdrożenia całego systemu. Można wdrożyć fragment i sprawdzić, czy działa. Brzmi zwinnie? Autor książki zresztą bardzo ciepło wypowiada się o metodykach zwinnych. W moim przypadku, podobnie jak w przypadku autora recenzji, wykorzystałem pewne elementy zaproponowane przez Davida Allena. Autor recenzji nie precyzuje, jakie elementy wykorzystał, co – uważam – mogłoby być cenne dla czytelnika. W moim przypadku zmieniłem organizację dokumentów papierowych, bo jeżeli chodzi o zarządzanie informacją w formie elektronicznej, to mam wypracowane pewne sprawdzone metody, ale w kwestii zarządzania informacja papierową było kiepsko.
Autor recenzji przytacza także, od myślników, „kilka wyrwanych z kontekstu sposobów”, które w książce podaje David Allen. Podane w taki sposób, w moim odczuciu, niewiele wnoszą dla czytelnika. Z mojej perspektywy można przytoczyć 3 pomysły, które pojawiły się w książce, które można wdrożyć u siebie praktycznie od razu:
- jak najczęściej pytaj: Jaki jest następny krok? Dla przykładu w sytuacji, gdy uczestniczymy w spotkaniu, podczas którego dyskutowano o rozwiązaniu pewnego problemu, takie pytanie postawione na zakończenie spotkania mocno ukierunkowuje myślenie uczestników na konkretne, przyszłe działanie. Dodatkowo tak zadane pytanie jest także dobrym testem na sprawdzenie, czy spotkanie było efektywne;
- przy planowaniu zadań określ przynajmniej najbliższe działanie. Często jest tak, że stawiane zadania są na tyle ogólne, że nie wiadomo, co zawierają. Dla przykładu: “nauczę się programować w Javie” oznacza, że zamierzamy nabyć określone kompetencje, ale jak to zamierzamy uczynić? Czy przeglądając tutorial na youtube, czy kupując książkę lub kurs video? Określenie najbliższego działania powoduje, że budujemy łańcuch czynności, które w ostateczności mogą doprowadzać nas do realizacji określonego zadania;
- jeżeli mamy coś do zrobienia i zajmuje to do 2 minut, zróbmy to od razu (autor recenzji także o tym wspomina). Często jest tak, że odkładamy i planujemy realizację spraw, których wykonanie zajmuje przysłowiowe 2 minuty. Nie odkładajmy takich spraw – zróbmy to od razu.
Kluczowe jest jednak to, żeby podkreślić, że bez względu na to, ile z rad Davida Allena przyjmiemy dla siebie ważne jest żeby nasz system był spójny. Oznacza to ni mniej ni więcej tylko to, że cokolwiek chcemy zapisać w dowolnej formie, to mamy wypracowany sposób na każdą taką okoliczność. Co nie mniej ważne, nasz system pozwala nam także na odszukanie dowolnej informacji praktycznie od razu. Brzmi ciekawie? 🙂 Dlatego uważam, że warto tę książkę przeczytać.
Na koniec małe podsumowanie, po co to całe zamieszanie z code review. Jeżeli ktoś jest programistą i chce się w tej umiejętności rozwijać, to code review pozwala mu na rozwinięcie skrzydeł. Mało tego, ten sposób pracy pozwala na rozwój każdej z osób zaangażowanych w ten proces. Analogia do autora piszącego recenzje książek wydaje się być oczywista – działa tu ten sam mechanizm. Co więcej, możemy w tym miejscu wspomnieć o pewnej kulturze przeprowadzania code review. W takiej sytuacji cały zespół powinien zaakceptować wszystkie przyjęte reguły. Takie podejście znacząco wzmacnia zespół, a dodatkowo na końcu odbiorca otrzymuje produkt o wyższej jakości. Czyż nie brzmi to fantastycznie? Wszyscy na tym zyskują 🙂 . Należy jednak pamiętać, że przytoczony model jest dużym uproszczeniem i generalnie skupia się wyłącznie na pozytywnych aspektach.
Nie wiem, czy autor recenzji książki poprosił kogoś o przegląd tekstu czy tego nie uczynił. Nie wiem także, czy wziąłby on pod uwagę jakąkolwiek moją radę przed publikacją swojej recenzji. Generalnie warto dokonywać takiego przeglądu, nie tylko kodu, ale także innych „wytworów” naszej pracy. Zwiększa się znacząco prawdopodobieństwo, że nasz produkt będzie wyższej jakości, a także będzie bardziej zrozumiały dla odbiorców.
W niniejszym artykule tylko lekko została zarysowana kwestia przeglądu kodu. Przypuszczam, że będziemy jeszcze do tego tematu wracać i go pogłębiać. Myślę, że ciekawym tematem byłaby kwestia narzędzi wykorzystywanych podczas code review oraz technik wykorzystywanych podczas tego procesu. Chcesz spróbować code review oraz zapoznać się z książką Davida Allena o GTD? Gorąco do obu zachęcam 🙂 .
Foto źródło: geek-and-poke.com