W poniedziałek wieczorem zaczęło się od jednego pliku: README z jedną linijką — samą nazwą projektu, bez ani jednego zdania opisu. Projekt istniał — przynajmniej w git.
Co przez cztery dni faktycznie robiłem
Nie pisałem funkcji aplikacji. Nie projektowałem bazy danych. Robiłem coś nudniejszego: budowałem podłogę, po której potem będę chodził.
Pod koniec tygodnia miałem już działający stack. 29 plików, 8915 linii — prawie wszystko konfiguracja. Co dokładnie?
Konteneryzacja: środowisko w Dockerze z bazą danych i narzędziem do śledzenia żądań między serwisami.
Jakość kodu: linter z własnymi regułami, formatter, walidacja commitów — żeby każdy commit wyglądał tak samo bez zastanawiania się.
Testy: środowisko testowe z osobnymi trybami dla testów jednostkowych i E2E, szybszy kompilator TypeScript.
Observability: narzędzie do śledzenia przepływu żądań (Jaeger) od pierwszego dnia. Brzmi jak przedwczesna inwestycja. Wróćmy do tego za chwilę.
Co odpuściłem (świadomie)
Nie ma ADR (Architecture Decision Records) — dokumentów decyzji architektonicznych. Nie ma CI/CD w GitHub Actions. Nie ma Husky’ego (git hooks). Nie ma Makefile. Nie ma security audit.
To wszystko dojdzie później. Na tym etapie każda z tych rzeczy to ryzyko: mogę spędzić na niej dwa dni i wciąż nie mieć działającego kodu.
Jedyna zasada: jeśli muszę to skonfigurować przed napisaniem pierwszej linii domenowej logiki — wchodzi do fundaments. Jeśli można to dodać kiedy zajdzie potrzeba — nie wchodzi.
Jeden wybór, który mnie zaskoczył
Jaeger w pierwszym tygodniu — to był impuls, nie plan. Instalacja zajęła godzinę. Ale miałem w głowie: jeśli nie mam narzędzia do obserwacji od początku, to potem dodam je „jak będzie czas”. A wiadomo jak to się kończy.
Dziś wiem: to była dobra decyzja. Kiedy dwa miesiące później zacząłem debugować interakcje między serwisami — Jaeger już działał.
Jedna rzecz, którą zrobiłbym inaczej
Cztery dni to za długo na samo setup. W połowie środy miałem już działający kontener i testy — ale siedziałem jeszcze nad drobnicami konfiguracji ESLint. Zasada, której brakuje w tej liście: ustal timebox na setup. Dwa dni max, potem piszesz kod i poprawiasz konfigurację w biegu.
Jeśli zaczynasz nowy projekt: te cztery dni to całkowite minimum, żeby nie żałować po miesiącu. Ale cztery dni to też maksimum — potem musisz pisać to, po co właściwie tu jesteś.
Stack techniczny z pierwszego tygodnia (dla ciekawych)
Runtime i build
- NestJS + TypeScript (SWC jako kompilator — szybszy start niż ts-node)
- pnpm (szybszy install niż npm, deterministyczny lockfile)
Konteneryzacja
- Dockerfile wieloetapowy: deps → build → production
- docker-compose z bazą danych (pgvector na start, o tym w osobnym wpisie) i Jaegerem
Jakość kodu
- ESLint z 162 liniami reguł
- Prettier z konfiguracją projektu
- commitlint — każdy commit według konwencji
Testy
- Vitest (unit + E2E) z osobnymi konfiguracjami
Observability
- Jaeger (distributed tracing) od pierwszego dnia
Czego jeszcze nie ma GitHub Actions, Husky, Makefile, Renovate, security audit — to wszystko dojdzie dwa miesiące później, gdy wrócę po przerwie.