Code review: po co właścicielowi strony przegląd kodu

Prowadzisz stronę internetową, sklep online albo małą aplikację. Ktoś napisał do nich kod: wykonawca, znajomy, agencja, która już się z projektu wycofała, albo ty sam po kilku weekendach z poradnikami. Działa, przeważnie. Nie wiesz jednak, czy jest solidny, czy trzyma się na taśmie klejącej. Code review, czyli przegląd kodu, to drugie spojrzenie kogoś, kto go nie pisał. Odpowiada na to pytanie, zanim mały problem zamieni się w kosztowny.

Przegląd kodu strony lub aplikacji

Kiedy przegląd się opłaca

Zanim zapłacisz za gotową pracę. Przegląd pokazuje, czy otrzymany kod jest sensowny, czy pełen prowizorki.
Gdy przejmujesz projekt. Odziedziczony kod bez dokumentacji jest czarną skrzynką, dopóki ktoś go nie objaśni.
Gdy coś ciągle się psuje. Formularz, który czasem nie działa, wolno ładująca się strona, błąd, który wraca po każdej poprawce.
Przed startem lub dużą wyprzedażą, gdy każdy błąd kosztuje prawdziwe pieniądze.
Gdy sam piszesz kod i chcesz się dowiedzieć, co robić lepiej.

Co wykrywa przegląd

Recenzent czyta kod linijka po linijce i szuka:

Błędów: logiki, która zawodzi w niektórych przypadkach, na przykład przy pustym koszyku, dacie na końcu miesiąca albo nazwisku z apostrofem.
Ryzykownych miejsc: haseł wpisanych w kod, danych od użytkowników używanych bez sprawdzenia, komunikatów o błędach, które zdradzają za dużo.
Słabych punktów: kodu, który działa dziś, ale przestanie, gdy wzrośnie ruch albo zostanie zaktualizowana biblioteka.
Czytelności: niejasnych nazw, długich funkcji i powtórzonego kodu, przez które każda przyszła zmiana jest wolniejsza i droższa.

Problemy są uporządkowane według wagi, więc wiesz, co poprawić najpierw, a co może poczekać.

Czego przegląd nie robi

Przegląd polega na czytaniu i objaśnianiu kodu; nie uruchamia go na twoim serwerze i nie testuje działającej strony. Nie jest pełnym audytem bezpieczeństwa ani testem obciążeniowym. Proponowane poprawki traktuj jako propozycje: osoba, która utrzymuje projekt, powinna przetestować każdą z nich, zanim trafi na produkcję.

Jak wybrać, co przesłać

Rzadko trzeba przesyłać całą stronę. Wybierz najważniejsze części:

Tam, gdzie płyną pieniądze: koszyk, płatności, ceny i rabaty.
Tam, gdzie użytkownicy coś wpisują: rejestracja, logowanie, formularze kontaktowe i wyszukiwarka.
Tam, gdzie są kłopoty: plik lub funkcja, za którą stoi widoczny błąd.

Kilkaset linijek z właściwego miejsca powie więcej niż tysiące linijek wszystkiego.

Jak przygotować kod

Usuń poufne dane. Zastąp hasła, klucze API i dane klientów symbolami zastępczymi, na przykład PASSWORD_HERE.
Podaj język i wersję, na przykład PHP 8 albo JavaScript z Reactem.
Opisz, co kod ma robić, w jednym lub dwóch prostych zdaniach.
Skopiuj dokładny komunikat o błędzie, jeśli jest, w całości.
Napisz, na czym się skupić: na błędzie, szybkości, czytelności czy ryzykownych miejscach.

Jak wykorzystać wynik

Przekaż przegląd osobie, która utrzymuje kod, i ustalcie kolejność poprawek, zaczynając od krytycznych. Jeśli nie jesteś osobą techniczną, podsumowanie napisane prostym językiem pomoże ci zadać właściwe pytania i ocenić odpowiedzi.

Podsumowanie

Code review to niezależne spojrzenie, które wyłapuje błędy, ryzykowne miejsca i słabe punkty, zanim zrobią to twoi klienci. Jeśli go potrzebujesz, zamów przegląd kodu: wklejasz do 100, 400 lub 1000 linijek i opisujesz, co nie działa, a dostajesz pisemne wyjaśnienie, co robi kod, listę problemów uporządkowaną według wagi i poprawione fragmenty do przetestowania we własnym projekcie. Płatność zostaje zwolniona dopiero po zaakceptowaniu pracy.