Pracodawcy, klienci i współpracownicy oczekują od programistów znacznie więcej niż działającego kodu. Chcą rozwiązań nieszkodliwych, możliwych do zweryfikowania, wypuszczanych małymi przyrostami, opartych na rzetelnych szacunkach i budowanych przez ludzi, którzy wzajemnie szanują swój profesjonalizm i nieustannie się doskonalą. Te dziesięć zasad, zaczerpniętych bezpośrednio z książek Boba Martina, uzupełnionych moim doświadczeniem z projektów różnej skali, nazywam Dekalogiem Programisty IT.
Table of Contents
Dlaczego oczekiwania wobec programistów wychodzą poza sam kod?
Większość wymagań stawianych programistom pozostaje niewypowiedziana. Klient chce, żeby system działał, ale zakłada przy tym, że nie zaszkodzi jego użytkownikom, że można go będzie rozwinąć za rok, że nikt nie będzie jedyną osobą rozumiejącą jego działanie. Gdy jedno z tych założeń zawodzi, dopiero wtedy wymagania stają się głośne, zwykle w najmniej odpowiednim momencie.
Artykuł zrodził się z lektury Boba Martina (przede wszystkim Clean Code i The Clean Coder) i z wieloletniego doświadczenia projektowego. Traktuję to jako checklistę do stosowania z głową, nie katalog reguł do stosowania bez refleksji.
Zasada 1: Przede wszystkim nie szkodzić
Nie szkodzimy społeczeństwu, firmie, klientom ani ich klientom. Nie szkodzimy też strukturze kodu, bo kto go będzie potem naprawiał? Najczęściej my. Trzy przypadki, które warto znać:
Volkswagen – oprogramowanie silników świadomie fałszowało wyniki testów emisji spalin. Sprawa trafiła do sądu, a winę zrzucono na programistów. Brak dokumentowania sprzeciwu wobec nieetycznych decyzji oznaczał brak jakiejkolwiek ochrony.
Toyota – po głośnej sprawie niekontrolowanego przyspieszenia audytorzy opisali kod publicznie jako spaghetti. Tak splątany, że niemożliwe było wywnioskowanie z niego logiki działania.
Healthcare.gov – platforma wdrożona za rządów prezydenta Obamy. Najpierw ogłoszono datę uruchomienia, potem zespół rozpoczął realizację nierealnego harmonogramu.
Wspólny mianownik: decyzje pod presją, bez mechanizmów weryfikacji, które uderzyły zarówno w użytkowników, jak i twórców oraz zlecających. Gdy presja rośnie (a zawsze rośnie) nie szkodzić – to ograniczenie, które nie powinno się przesuwać. Bob Martin w The Clean Coder poświęca temu cały rozdział, z gotowymi scenariuszami rozmów z przełożonymi w sytuacjach konfliktowych.
Mechanizmem zwiększającym pewność, że nie szkodzimy, są testy. Manualne wyłapują więcej przypadków brzegowych. Automatyczne działają szybciej i chronią przed regresją, której nie przewidzieliśmy.
Zasada 2: Tworzyć optymalnie, nie maksymalnie
Kod, dokumentacja, rozwiązanie oparte na AI, cokolwiek dostarczamy powinno być najlepsze, na jakie nas stać w danym kontekście i przy danych ograniczeniach. Celowo używam słowa optymalnie, bo „najlepsze absolutnie” jest celem asymptotycznym, nie praktycznym a często niemożliwym do osiągnięcia.
Kent Beck, twórca metodyki TDD i jeden z sygnatariuszy Manifestu Agile, ujmuje to prosto: najpierw spraw, żeby działało, potem popraw, dopiero potem zabierz się za kolejne zadanie.
Wiele dojrzałych organizacji odkryło empirycznie, że żeby iść szybko, trzeba iść równomiernie. Stałe, przewidywalne tempo bije heroiczne sprinty zakończone tygodniami regresji.
Kluczowe narzędzia: wzorce projektowe, świadoma architektura oraz projektowanie rozwiązań z myślą o przyszłych zmianach.
Praktyczny sygnał ostrzegawczy: gdy testy jednostkowe są trudne do napisania, coś jest nie tak z architekturą. Trudność testowania jest wskaźnikiem nadmiernego sprzężenia i złożoności. To znak, żeby się zatrzymać i przemyśleć projekt.
Pracowałem u klienta, gdzie tempo wprowadzania nowych funkcjonalności z miesiąca na miesiąc spadało. Nie było przestrzeni na pełne przeprojektowanie, ale dzięki małym, iteracyjnym refaktoryzacjom stopniowo udało się je odbudować – klasyczna zasada scouta: zostaw kod trochę lepszym, niż go zastałeś.
Zasada 3: Udowodnić, że to, co zbudowałeś, działa
W matematyce mamy dowody formalne. W oprogramowaniu mamy testy i to jest najbliższy nam mechanizm weryfikacji.
Według badań IBM Systems Sciences Institute, naprawa błędu znalezionego po wdrożeniu na produkcję kosztuje od 4 do 100 razy więcej niż naprawa tego samego błędu wykrytego na etapie projektowania. To nie jest argument za pisaniem testów, bo wypada. To argument finansowy.
Jak wygląda skuteczna piramida testów?
| Poziom testów | Cel | Docelowy czas wykonania zestawu testów | Kiedy uruchamiać |
| Testy jednostkowe | Weryfikacja izolowanych komponentów | Do 2 minut | Przy każdym commicie |
| Testy integracyjne | Sprawdzenie komunikacji między modułami | 5–10 minut | Przy każdym pull requeście |
| Testy end-to-end | Walidacja pełnych ścieżek użytkownika | Do 30 minut | Przy każdym release candidate |
| Testy akceptacyjne | Zgodność z wymaganiami biznesowymi | Zależnie od zakresu | Przed każdym wdrożeniem |
Testy, które wykonują się wolno, nie są uruchamiane. Dlatego ich szybkość to nie luksus, lecz warunek użyteczności.
Zmiana myślenia, którą uważam za najważniejszą: QA nie powinno szukać błędów, które przegapili programiści. Powinno weryfikować, czy kryteria akceptacji zdefiniowane przed kodowaniem zostały spełnione. To wymaga inwestycji z góry: szablonów testów akceptacyjnych i procesu, w którym piszemy pod specyfikację.
W projekcie u klienta, gdy udało się wprowadzić testy jednostkowe faktycznie sprawdzające zachowanie, nie tylko świecące na zielono, release’y stały się wyraźnie mniej stresujące. Gdy coś się psuło podczas aktualizacji, problem lokalizował się w jednym miejscu. Szybka poprawka i jedziemy dalej. Wcześniej jedna zmiana potrafiła uruchomić kaskadę problemów w niepowiązanych miejscach systemu.
Zasada 4: Wypuszczać małymi partiami, nieustannie
Jedna z zasad, którą zespoły najczęściej odkładają na potem i prawie zawsze żałują. Badania przeprowadzone przez Pivotal Labs wykazały, że projekty stosujące TDD i ciągłą integrację z małymi przyrostami miały o 28% krótszy cykl dostarczenia, niż projekty bez tego podejścia.
Małe zmiany oznaczają w praktyce:
- konflikty przy merge’u są rzadkie i małe – code review jest faktycznie możliwy oraz przyjemny dla wszystkich stron
- baza kodu jest zawsze w stanie gotowym do wypuszczenia na produkcję, środowiska testowe lub prezentację dla interesariuszy
- biznes może powiedzieć wdróż co masz i możemy to zrobić natychmiast
- szybciej dowiadujemy się, czy to, co budujemy, odpowiada na rzeczywistą potrzebę
Duże zmiany oznaczają tygodnie, gdy main branch stoi w miejscu, a potem kolejne tygodnie bolesnej integracji. Mając coś na produkcji wcześniej, nawet niekompletną funkcjonalność, możemy obserwować jej zachowanie w prawdziwych warunkach, zamiast dowiadywać się o problemach przy wielkim debiucie.
Małe zmiany mają jeszcze jedną zaletę: mobilizują do porządkowania przy okazji. Dodając małą funkcję i widząc źle nazwane zmienne w sąsiednim pliku, po prostu je poprawiam. Koszt zerowy, jakość kodu rośnie.
Zasada 5: Dbać o jakość w sposób mierzalny
Dobry kod, testy i czysta architektura nie są celem samym w sobie. Są środkiem do konkretnych, mierzalnych wyników. Jeśli nic nie mierzymy, nie wiemy, czy nasze praktyki faktycznie działają.
Trzy metryki, które mają znaczenie
| Metryka | Co mierzy | Sygnał alarmowy |
| Czas wdrożenia nowej funkcjonalności | Efektywność całego procesu wytwarzania | Rośnie z miesiąca na miesiąc |
| Liczba bugów i czas naprawy | Jakość kodu i pokrycie testami | Jeden bug generuje kaskadę kolejnych |
| Czas onboardingu nowego developera | Czytelność kodu i dokumentacji | Więcej niż kilka dni na pierwsze samodzielne zadanie |
Według danych CISQ (Consortium for Information & Software Quality), zła jakość oprogramowania kosztuje firmy w USA ponad 2,41 biliona dolarów rocznie. Zespoły deweloperskie przeznaczają średnio 30–50% czasu pracy na naprawianie błędów i nieplanowany rework, zamiast na budowanie nowych funkcjonalności.
W Agile story pointy mogą pełnić rolę metryki tempa: jeśli zadania wycenione na 5 punktów zajmują coraz więcej czasu, to wyraźny sygnał, że coś w strukturze kodu hamuje postęp.
Narzędzia jak SonarQube mogą wspierać analizę jakości kodu (kohezja, sprzężenia, złożoność cyklomatyczna), ale nie zastępują powyższych wskaźników. Są pomocnym uzupełnieniem, nie substytutem.
Zasada 6: Nieustannie ulepszać, ale z głową
Reguła scouta, będąca mantrą Boba Martina: zostawiaj kod odrobinę lepszym, niż go zastałeś. Zmieniaj nazwy zmiennych, wydzielaj funkcje, redukuj sprzężenia, przy okazji każdego zadania.
Jest tu jednak niuans wart uwagi. Martin sugeruje, by wprowadzać nie tylko ulepszenia, ale i zmiany, nawet pozornie neutralne. Zmień nazwę klasy i sprawdź, co się stanie. Nie podoba ci się struktura metody, zmień ją, obserwuj reakcję systemu. To sposób na ciągłe weryfikowanie elastyczności kodu.
Dobra struktura redukuje strach przed zmianą. Jeśli wiem, że modyfikując jeden moduł mogę oczekiwać jasno zlokalizowanych konsekwencji, bo testy powiedzą mi dokładnie co i gdzie się posypało, zmieniam chętnie. Jeśli każda zmiana grozi efektem domina w niepowiązanych miejscach systemu, przestaję dotykać czegokolwiek. Stagnacja jest gorsza niż niedoskonały refaktoring.
Czyste środowisko to też: dokumentacja w Confluence, komentarze w kodzie ograniczone do niezbędnego i sensownego minimum, README, opisy zadań w Jirze. Jeśli widzę, że coś jest źle opisane, uzupełniam. Nasz produkt to nie tylko kod.
Zasada 7: Maksymalizować wydajność – całościowo, nie tylko w edytorze
Pisanie kodu to jedna składowa pracy. Reszta to budowanie, testowanie, debugowanie, wdrażanie, spotkania, komunikacja z klientem. Wszystko to wpływa na rzeczywistą wydajność.
Jak TDD zmienia czas debugowania?
Badania przeprowadzone przez Uniwersytet w Oulu wykazały, że programiści stosujący TDD doświadczają redukcji czasu debugowania o 30–35% w porównaniu z podejściami tradycyjnymi. Microsoft odnotował w projektach z TDD redukcję liczby defektów o 50–90%.
Kiedyś uruchamiałem debugger kilkadziesiąt razy dziennie. Teraz raz w miesiącu, jeśli w ogóle. Testy jednostkowe zastępują większość sesji debugowania: gdy coś się psuje, widzę z testu dokładnie gdzie, nie szukam po omacku.
Co jeszcze wpływa na wydajność?
Automatyzacja środowiska. Docker Compose z jednym poleceniem startowym to nie luksus, to standard. Onboarding nowego developera nie powinien zajmować tygodnia konfiguracji. Jeśli zajmuje, coś jest nie tak.
Uzależnienie od IDE. Widziałem projekt, gdzie wszystko musiało chodzić przez IntelliJ. Podczas gdy drugi zespół uzależnił się od pluginu działającego tylko na jednej wersji Eclipse. Programiści przechodzący pomiędzy zespołami, tracili czas na naukę narzędzi, zamiast wdrażać się w kod.
Skrypty i automatyzacja procesów. Długie, wieloliniowe polecenia terminalowe wrzucam w skrypt. Skrypt jest łatwy do odpalenia, łatwy do aktualizacji, nie wymaga komunikowania wszystkim, że „teraz trzeba to uruchamiać inaczej.”
Spotkania. Jeśli można coś ustalić przy tablicy w 10 minut, nie potrzebujemy godzinnego call’a. Spotkania też są częścią naszej wydajności.
Zasada 8: Dbać o zastępowalność
Trzymanie wiedzy dla siebie, tworzenie kodu rozumianego tylko przez autora, brak dokumentacji to pułapka. Niezastąpialność nie chroni przed restrukturyzacją firmy ani decyzją zarządu. Chroni za to przed wzięciem urlopu bez telefonu od szefa.
Zastępowalność to wolność. Jeśli system, który zbudowałem, może prowadzić ktokolwiek z zespołu, mogę spokojnie zmienić projekt, pojechać na urlop, zachorować.
Jak to osiągnąć w praktyce:
- Pair programming i code review jako transfer wiedzy
- Czytelny kod jako pierwsza dokumentacja
- Testy jako dokumentacja zachowania systemu
- Skrypty zamiast długich instrukcji w README
- Regularne rozmowy przy tablicy lub przy kawie – niektóre rzeczy wychodzą dopiero przy luźnej rozmowie
Zasada 9: Szacować rzetelnie i komunikować postępy
Słyszałem historię o firmie, która dostała zlecenie na fanpage z „elementami portalu społecznościowego”. Nie doprecyzowała zakresu w umowie. Klient stopniowo dorzucał kolejne funkcje zdjęcia, filmy, komentarze, reagowania powołując się wciąż na „elementy portalu.” Firma w końcu zapłaciła karę umowną, mimo że wydała masę własnych zasobów. Jak dajesz palec, zjedzą całą rękę.
Jak szacować trafniej?
Trzy liczby zamiast jednej. Zamiast podawać jedno oszacowanie, podaję trzy: optymistyczne, średnie i pesymistyczne z wyraźnym opisem, co musi się zdarzyć, żebyśmy byli w danym scenariuszu. Jeśli podasz samą liczbę optymistyczną, klient zapamięta tylko ją.
Im głębsza analiza, tym precyzyjniejsza wycena, ale jest granica. W pewnym momencie czas poświęcony na analizę staje się droższy niż ryzyko błędnej wyceny. Czasem lepiej ruszyć z rozsądnym zakresem i korygować w trakcie, niż przez miesiąc zbierać wymagania, szczególnie gdy sam klient nie do końca wie, czego chce.
Statement of Work. Dokument jasno definiujący co robimy, a czego nie. To inwestycja zwracająca się przy każdym nieporozumieniu z klientem. Warto opisać w nim założenia: jeśli wyceniliśmy portal ze zdjęciami, a nie portal z filmami to powinno być zapisane.
Ciągła komunikacja o postępach. Mając szacunki i widząc, jak się do nich zbliżamy, możemy wcześnie zasygnalizować klientowi zmianę. Wtedy biznes ma czas na decyzję: zmienić scope, przesunąć termin, zwiększyć zespół. Nie dowiaduje się o problemie w dniu, gdy miał dostać gotowy produkt.
Zasada 10: Szanować się nawzajem i nieustannie doskonalić
Gdzieś usłyszałem zdanie: profesjonaliści szanują się wzajemnie za profesjonalizm, nawet jeśli się ze sobą nie zgadzają. Nie pamiętam źródła, ale w środowisku pracy wyczerpuje to temat w zasadzie w całości.
Eliminuje dyskusje o tym, kto używa jakich narzędzi, kto preferuje jakie podejście. W pracy: profesjonalizm.
Ciągłe doskonalenie, ale z zachowaniem równowagi. Pragmatyczny programista Andy Hunta i Dave Thomasa sugerują jedną książkę techniczną miesięcznie, regularne czytanie blogów, uczestnictwo w konferencjach. To piękny ideał. Mamy też życie, rodziny, inne zainteresowania. Rozsądnie: ucz się w pracy, gdy masz przestrzeń. Wypróbuj nowy wzorzec na realnym zadaniu.
Dzielenie się wiedzą to też nauka dla siebie. Badania nad efektywnością uczenia się pokazują, że gdy tłumaczymy coś komuś innemu, przyswajamy materiał znacznie głębiej niż przez samo czytanie. Stąd wartość code review, wewnętrznych prezentacji, rozmów przy tablicy. To „rubber duck debugging” w wersji społecznej – zanim skończyłem tłumaczyć problem koledze, sam znalazłem odpowiedź.
Poszerzaj horyzonty poza IT. Malarstwo uczy dbałości o detale przydatnej w UI. Szachy rozwijają myślenie kilka kroków do przodu, dokładnie to, czego potrzeba przy projektowaniu architektury. Każde ćwiczenie umysłu poprawia jego ogólne funkcjonowanie.
Kiedy NIE stosować wszystkich zasad naraz?
To checklista, nie nakaz. Kontekst decyduje o tym, które zasady mają zastosowanie i w jakim zakresie.
| Kontekst | Podejście |
| Startup weryfikujący hipotezę biznesową | Minimum viable quality. Priorytet to szybka weryfikacja, nie pełne pokrycie testami |
| System healthcare z danymi medycznymi | Większość zasad staje się wymaganiem, nie opcją |
| Dojrzały produkt z dużą bazą użytkowników | Pełna piramida testów, CI/CD, monitoring jakości |
| Wewnętrzny skrypt automatyzujący jedno zadanie | Wystarczy, że działa i jest czytelny |
Kluczowe pytanie przy każdej zasadzie: jaki jest zwrot z tej inwestycji w tym konkretnym kontekście? Jak powiedział Kent Beck: najpierw spraw, żeby działało. Reszta jest iteracją.
Najgorsza sytuacja: idziemy powoli bo stosujemy wszystkie praktyki, i mimo to z każdym miesiącem zwalniamy. Wzięliśmy wszystkie wady złego podejścia, nie mając żadnych zalet dobrego. Jeśli tempo wdrożeń maleje mimo stosowania dobrych praktyk, to znak, że stosujemy je bez celu, nie z głową.
Artykuł oparty na prezentacji wewnętrznej w fireup.pro, inspirowanej książkami Boba Martina – Clean Code i The Clean Coder oraz Pragmatic Programmer Andy’ego Hunta i Dave’a Thomasa oraz Rzemiosło w czystej formie. Standardy i etyka rzetelnych programistów autorstwa Roberta C. Martina Praktyczne przykłady pochodzą z projektów realizowanych w ramach Custom Software Development,System Refactoring i Test Automation w fireup.pro
🚀 Zdjęcia w nagłówku zrobiłem sam, fotografuję amatorsko od lat. Więcej moich prac znajdziesz na https://photography.mwilczek.net/
