Kodeks w 5 minut
Cała doktryna w pigułce: dziesięć przykazań — każde najpierw krótko, a potem po ludzku.
- IDokumentuj dla agenta, nie dla archiwum.
Zapisuj wiedzę o projekcie tak, żeby następna osoba (albo AI) zrozumiała ją przed dotknięciem kodu — i rób to od razu, nie „kiedyś”. Notatka pisana na bieżąco oszczędza godziny zgadywania; pisana po fakcie i tak się zdezaktualizuje.
- IISzukaj w historii, zanim napiszesz linijkę.
Zanim zaczniesz robić coś od zera, sprawdź, czy ktoś już tego nie rozwiązał w projekcie. Zwykle istnieje gotowy fragment albo powód, dla którego coś działa tak, a nie inaczej — minuta szukania jest tańsza niż dzień wymyślania na nowo.
- IIIWeryfikuj, nie deklaruj.
Zanim ktoś powie „działa”, ma to pokazać — uruchomić, sprawdzić, udowodnić. „Chyba działa” nie istnieje; albo jest dowód, albo robota nie jest skończona.
- IVDry-run jest domyślny; --execute świadomy.
Każde narzędzie, które zmienia dane, najpierw pokazuje plan — co i ile zmieni — a dopiero po Twojej akceptacji robi to naprawdę. To jak bezpiecznik: chroni przed zniszczeniem czegoś jednym pochopnym kliknięciem.
- VBackup to mechanizm rollbacku, nie ostrożność.
Kopia zapasowa robiona przed każdą zmianą to nie nadgorliwość — to jedyna droga powrotu, gdy coś pójdzie nie tak. Bez niej cofnięcie błędu bywa po prostu niemożliwe.
- VIProd jest święty — nie dotykasz bez „wdrażaj”.
Wersji, której używają prawdziwi klienci (produkcja), nie rusza się bez Twojego wyraźnego „wdrażaj”. Zapisanie zmian to jeszcze nie ich publikacja na żywo — to dwie różne decyzje, a tę drugą podejmujesz świadomie.
- VIIDane użytkownika są nienaruszalne.
Dane Twoich użytkowników — konta, zamówienia, opinie, historia — są nietykalne. Przy każdej operacji na bazie pilnujemy, by nic z nich nie zginęło ani się nie pomieszało, bo to majątek firmy i zaufanie klientów.
- VIIITaguj każdy deploy i pisz, co user zyskał.
Każde wdrożenie na żywo dostaje czytelny znacznik z datą — żeby zawsze było wiadomo, co dokładnie działa u klientów i móc szybko wrócić do poprzedniej wersji. Do tego krótki opis prostym językiem: co użytkownik na tym zyskał.
- IXMały, spójny commit; jeden temat.
Zapisuj zmiany małymi paczkami, każda o jednej rzeczy — osobno poprawka, osobno nowa funkcja. Dzięki temu łatwo zrozumieć, co się zmieniło, a w razie problemu cofnąć tylko jedną rzecz, nie wszystko naraz.
- XPlan → iteruj → review.
Najpierw pokaż plan albo kilka przykładów (trzy, nie sto), zbierz opinię, i dopiero potem rób to na większą skalę. Tak unikasz wyprodukowania setek rzeczy, które trzeba wyrzucić — i wychodzi produkt nie tylko działający, ale i przyjemny w odbiorze.