Ekonomia Kodu: Dlaczego "Szybko" znaczy "Wolno"?

Wyobraź sobie, że piszesz kod "na szybko", byle dowieźć funkcjonalność na piątek. Ignorujesz testy, kopiujesz fragmenty (Copy-Paste), tworzysz klasy-molochy. Na początku idzie świetnie. Ale po pół roku dodanie prostej zmiany (np. nowej stawki VAT) zajmuje tydzień, bo zmiana w jednym miejscu wywołuje błędy w pięciu innych.

To jest właśnie Dług Techniczny. Clean Code to spłacanie odsetek na bieżąco. Kod czyta się 10 razy częściej, niż się go pisze (podczas code review, debugowania, wdrażania nowych funkcji). Inwestycja godziny w napisanie czytelnego kodu zwraca się wielokrotnie w przyszłości. W JSystems uczymy, że profesjonalizm to umiejętność powiedzenia biznesowi: "Nie zrobimy tego szybciej, bo zrobimy to źle, a to was będzie kosztować więcej".

10 Przykazań Czystego Kodu (Wersja dla Praktyków)

1. Nazwy to dokumentacja (Intention-Revealing Names)

Najtrudniejsza rzecz w informatyce? Nazywanie rzeczy. Zmienna d nic nie znaczy. Zmienna daysSinceCreation mówi wszystko.

Zła nazwa: public List<int> Get() { ... }

Dobra nazwa: public List<Employee> GetActiveEmployees() { ... }

Kod powinien czytać się jak prozę. Jeśli musisz zaglądać do wnętrza funkcji, by wiedzieć, co ona robi – nazwa jest do zmiany.

2. Zasada Pojedynczej Odpowiedzialności (SRP - SOLID)

Klasa lub funkcja powinna mieć tylko jeden powód do zmiany. Jeśli Twoja klasa UserService zajmuje się: (1) walidacją peselu, (2) zapisem do bazy i (3) wysłaniem e-maila powitalnego – łamiesz SRP. Rozbij to na PeselValidator, UserRepository i EmailSender. Dzięki temu zmiana w sposobie wysyłki maili nie zepsuje logiki walidacji.

3. Funkcje: Krótkie i robiące jedną rzecz

Idealna funkcja ma 5-10 linii. Jeśli Twoja funkcja ma 200 linii i zawiera sekcje oddzielone komentarzami (// walidacja, // zapis), to prosi się o "Extract Method". Poziom wcięć (zagnieżdżone if-y) nie powinien przekraczać dwóch. To redukuje tzw. Złożoność Cyklomatyczną.

4. DRY (Don't Repeat Yourself) vs WET (Write Everything Twice)

Duplikacja kodu to źródło wszelkiego zła. Jeśli poprawiasz błąd w jednym miejscu, a zapominasz o jego kopii w innym pliku – masz buga. Ale uwaga! Na szkoleniach w JSystems uczymy też pragmatyzmu. Czasem lepiej powtórzyć kod, niż tworzyć sztuczną abstrakcję, która wiąże ze sobą niezależne moduły. Zasada WET (Write Everything Twice) mówi: poczekaj z refaktoryzacją, aż powtórzysz kod trzeci raz.

5. Komentarze kłamią

Kod się zmienia, komentarze rzadko. Nie ma nic gorszego niż komentarz, który mówi co innego niż kod.

Zamiast pisać: // Sprawdź czy pracownik ma prawo do premii

Wydziel metodę: if (employee.IsEligibleForBonus())

Komentarze są dopuszczalne tylko wtedy, gdy wyjaśniają DLACZEGO coś zrobiliśmy (np. "Używamy tego algorytmu, bo jest szybszy dla małych zbiorów"), a nie CO zrobiliśmy.

6. Obiekty vs Struktury Danych (Prawo Demeter)

Nie rozmawiaj z obcymi. Kod typu order.Customer.Address.ZipCode to łamanie enkapsulacji. Jeśli zmieni się struktura klienta, musisz poprawić kod w 50 miejscach. Lepiej: order.GetZipCode().

7. Testy Unitowe jako specyfikacja

W JSystems wyznajemy zasadę: Kod bez testów to kod legacy w momencie napisania. Testy dają Ci odwagę do refaktoryzacji. Jeśli boisz się dotknąć kodu, "żeby nie wybuchło", to znaczy, że brakuje testów. Clean Code jest nierozerwalnie związany z TDD.

8. Obsługa błędów (Exceptions over Return Codes)

Nie zwracaj -1 ani null jako błędu. Rzucaj wyjątkami. Wyjątki nie zaśmiecają głównego przepływu sterowania (Happy Path). I na litość boską – nigdy nie rób pustego catch!

9. Formatowanie i Konwencje

Zespół musi ustalić jeden styl (nawiasy w nowej linii czy tej samej?). Używajcie narzędzi typu Prettier, ESLint czy StyleCop, które formatują kod automatycznie przy zapisie. Dyskusje o wcięciach na Code Review to strata czasu.

10. Zasada Skauta

"Zostaw miejsce biwakowe czystszym, niż je zastałeś". Widzisz mały bałagan w pliku, który edytujesz? Zmień nazwę zmiennej, usuń nieużywany import. Te mikropoprawki kumulują się w czasie, zapobiegając gniciu kodu (Code Rot).

Code Review – poligon doświadczalny JSystems

Teoria jest prosta, praktyka boli. Dlatego nasze szkolenia opierają się na warsztatach z Code Review. Uczestnicy piszą kod, a następnie wspólnie (na rzutniku) go "masakrujemy" – w pozytywnym sensie. Szukamy złych nazw, łamania SOLID, braku testów. Uczymy, jak dawać i przyjmować feedback.

Pokazujemy też, jak refaktoryzować kod krok po kroku, używając skrótów klawiszowych IDE (IntelliJ, Visual Studio), co sprawia, że czyszczenie kodu jest szybkie i bezpieczne.

Podsumowanie: Jakość to nawyk

Czysty kod nie powstaje, gdy masz "więcej czasu". Czysty kod to nawyk, który budujesz codziennie. To szacunek do współpracowników i do samego siebie z przyszłości. Jeśli chcesz, by Twoja praca była przyjemnością, a nie walką z ogniem – zacznij dbać o higienę kodu już dziś.

Czujesz, że Twój kod mógłby być lepszy? Zapraszamy na warsztatowe szkolenia z zakresu architektury oprogramowania, w tym obejmujące clean code. Nauczymy Cię pisać kod, z którego będziesz dumny.

FAQ – Clean Code