15 października 2025 zrobiłem commit, którego nie zalecam.
362 000 linii dodanych. Jeden commit. Jeden tag w git: feat(auth): complete authorization system.
To nie był dobry moment ani dobra praktyka. Ale jest historią, którą warto opowiedzieć — o tym, jak wygląda budowanie krytycznej infrastruktury w pojedynkę przez kilka miesięcy. I o tym, co się dzieje z dyscypliną, gdy pracujesz bez zewnętrznych punktów kontrolnych.
Przed kodem były dokumenty
Zanim napisałem pierwszą linię kodu autoryzacji, przez kilka tygodni pisałem.
System autoryzacji dla platformy sąsiedzkiej to nie jest prosty check ról. To system, w którym błędna decyzja projektowa na początku kosztuje tygodnie przepisywania potem. Dlatego zanim dotknąłem klawiatury: dokumenty decyzyjne.
Kilkanaście takich dokumentów — każdy z decyzją, rozważonymi alternatywami i uzasadnieniem. Model uprawnień (action + subject zamiast ról bezpośrednich). Jak geograficzna izolacja dzielnic działa jako granica bezpieczeństwa, nie tylko produktowa. Jak cache uprawnień powinien się zachowywać przy zmianie roli użytkownika. Co oznaczają tokeny API dla platformy, której klientami mają być jednostki samorządowe.
To ironia, którą widzę wyraźnie z perspektywy: pisałem staranne dokumenty, podejmowałem przemyślane decyzje — i wysłałem to wszystko w jednym commicie, gdzie te decyzje toną w szumie 362 000 linii.
Dokumenty istnieją. Kod je odzwierciedla. Ale związek między jednym a drugim jest niewidoczny w historii git.
Skąd się wzięło tyle linii
System autoryzacji w juz-ide to kilka warstw współpracujących ze sobą: uprawnienia (action + subject), role przypisane do użytkownika, geograficzny kontekst dzielnicy jako granica izolacji, cache uprawnień, integracja z domenowymi zdarzeniami i API tokeny dla zewnętrznych integracji.
Każda warstwa rozrastała się przez tygodnie. Projekt na osobnej gałęzi, lokalne commity wewnętrzne, praca postępuje. Ale był konkretny wzorzec, który sprawił, że gałąź tak spuchła: każda nowa decyzja wymagała cofnięcia się do poprzedniej.
Budujesz uprawnienia dla geograficznej aplikacji społecznościowej — i w połowie implementacji uświadamiasz sobie, że „granica dzielnicy” to decyzja bezpieczeństwa, nie tylko produktowa. Nie dodajesz kolejnego check’a. Wracasz i sprawdzasz, czy cały model był poprawny.
Ten cykl — budowanie, odkrycie czegoś fundamentalnego, przeprojektowanie — powtórzył się kilka razy przez trzy tygodnie. Każde powtórzenie wydłużało gałąź. Każde odkrycie było słuszne. Efekt kumulatywny: gałąź spuchła tak, że w dniu merge’a wrzuciłem wszystko naraz. Mówiłem sobie, że „nie dało się tego rozbić bez utraty spójności” — dziś wiem, że to była wymówka. Dało się. Po prostu tego nie zrobiłem.
Anatomia 362 tysięcy
Najpierw uczciwie, skąd ta liczba. „362K+” wpisałem sam — w treść commita, jako podsumowanie tygodni pracy na gałęzi. To nie jest pojedynczy, atomowy diff hand-made’owego kodu. Gdy dziś patrzę na git, ten jeden merge to suma mnóstwa mniejszych zmian, a samą liczbę napędziły trzy rzeczy, które puchną najszybciej.
Pierwsza — testy. System autoryzacji jest typem domeny, gdzie testy to nie opcjonalna dokumentacja — to jedyny sposób weryfikacji, że system robi to, co dokumenty mówią że ma robić. Testy pokrywają każdą regułę uprawnień, każdy przypadek graniczny z geografią, każde „co się dzieje gdy użytkownik zmienia adres zamieszkania”. Przy tej skali kod testów dorównuje lub przekracza kod logiki.
Druga część to generowany kod — typy TypeScript, schematy OpenAPI, pliki migracji bazy danych. Ten kod jest poprawny z definicji (generuje go narzędzie), ale wchodzi do diffa i puchnie licznik.
Trzecia, zaskakująco duża część to dokumentacja: pliki konfiguracyjne i instrukcje dla moich agentów AI, które wjechały do repo przy okazji. Tekst, nie kod — ale licznik linii tego nie rozróżnia.
A właściwa logika — kod, który recenzent musiałby naprawdę zrozumieć — to najmniejszy kawałek tego wszystkiego. I to właśnie ten kawałek jest niemożliwy do przejrzenia w jednym podejściu, bo tonie w pozostałych trzech.
Gdybym był dyscyplinowany i robił merge co tydzień, te same 362K linii rozłożyłoby się na kilkanaście commitów. Recenzja każdego z nich byłaby możliwa. Łączny nakład pracy na code review: kilka godzin tygodniowo zamiast jednego niemożliwego maratonu.
Recenzja samego siebie
Pracując w pojedynkę nie mam code review. Recenzentem jestem ja — dzień, dwa po napisaniu, ze świeżymi oczami.
Przy 362K linii „świeże oczy” tracą sens. Nie da się przejrzeć tego sensownie. Można tylko sprawdzić, czy się kompiluje, czy testy przechodzą, czy lokalne środowisko nie wybucha. Strukturalne błędy w decyzjach architektonicznych — niewidoczne. Nieoczywiste konsekwencje wyboru modelu uprawnień — niewidoczne. Miejsca, gdzie logika działa poprawnie, ale jest krucha na przyszłe zmiany — niewidoczne.
Mam wrażenie, że kilka decyzji z tego commita wróci do mnie za pół roku z pytaniem „dlaczego tak?”. I nie będę pamiętał — bo kontekst jest w dokumentach, których data nie jest zsynchronizowana z datą commita.
Security review w ciemno
Kod autoryzacji jest security-critical. Gdy system decyduje „czy ten użytkownik może wykonać tę akcję”, błędne odpowiedzi mają konsekwencje: użytkownicy widzą dane, których nie powinni widzieć. Wykonują operacje, których nie powinni. Eskalują uprawnienia.
Przy 362K linii w jednym commicie security review jest technicznie niemożliwy. Przeglądałem tyle, ile byłem w stanie — testy były przewodnikiem, dokumenty były przewodnikiem. Ale wiem, że są przypadki brzegowe, które przeoczyłem. Część wyjdzie przy testowaniu. Część nie wyjdzie dopóki system nie dostanie prawdziwych użytkowników.
Co zrobiłem zamiast pełnego review: automatyczne tooling bezpieczeństwa uruchamiane przy każdym push — statyczna analiza kodu, skanowanie zależności pod kątem znanych podatności. To nie zastępuje rzetelnej recenzji, ale łapie oczywiste rzeczy. Dla solo developera przy tej skali — to najlepsze, co możesz zrobić. I szczera odpowiedź brzmi: to za mało.
Security review kodu autoryzacji przy 362K linii to głównie zaufanie do testów i nadzieja, że dokumenty decyzyjne były wystarczająco przemyślane. Niekomfortowe przyznanie.
Co to znaczy dla pracy solo
Przy projekcie zespołowym duże commity to problem z code review. Przy projekcie solo to problem z myśleniem.
Pisząc przez tygodnie bez przerwy na „zatrzymaj się i przejrzyj” — tracę perspektywę. Widzę drzewa, nie las. Decyzje podejmowane po dwóch tygodniach intensywnego pisania są gorsze niż te podejmowane po jednym dniu pracy i jednej nocy przerwy.
Jest też subtelniejszy problem: długa gałąź bez merge’a daje poczucie postępu bez weryfikacji. Piszesz, commitujesz lokalnie, widzisz jak drzewo commitów rośnie — i czujesz, że idzie dobrze. Ale ten postęp jest niewidoczny dla „siebie z zewnątrz” — dla mnie przeglądającego historię za miesiąc, dla ewentualnego przyszłego współpracownika, dla security review.
Październik 2025 nauczył mnie, że rytm pracy jest architekturą samą w sobie. To, jak kroisz pracę na commity i kiedy robisz merge, wpływa na jakość kodu tak samo jak wybór bibliotek.
Co zmieniłem
Dwie konkretne reguły po październiku 2025.
Merge do develop minimum raz w tygodniu — nawet jeśli feature jest nieukończony. Nieukończony kod na głównej gałęzi jest do zaakceptowania, jeśli jest za feature flagą albo wyraźnie oznaczony jako work-in-progress. Alternatywa — tygodnie rozjazdu i jeden potworny commit — jest gorsza.
Dokument decyzyjny z wersją minimalną — każdy większy system teraz zaczyna się od opisu, co jest „minimum viable implementation” tej decyzji. Wersja, którą da się wdrożyć i wysłać w ciągu jednego, dwóch dni. Jeśli nie potrafię opisać takiej wersji — projekt jest prawdopodobnie za duży i trzeba go rozbić na sekwencję mniejszych.
System autoryzacji mógłby wyglądać tak: podstawowy check uprawnień (dzień 1), geograficzna izolacja dzielnicy (dzień 3), cache (dzień 5), tokeny API (dzień 8). Każdy jako osobny, recenzowalny commit. Razem — ten sam efekt końcowy, bez 362K linii w ciemno.