W październiku rozważałem uproszczenie architektury weryfikacji adresu. Pomysł był przekonujący: dwa osobne moduły, które zawsze współpracują, mogłyby działać jako jeden. Mniej kodu, mniej interfejsów, mniej koordynacji.
Przez dwa dni serio to analizowałem. Skończyło się na jednym zdaniu: odrzucone.
I to zdanie — to „nie” z uzasadnieniem — okazało się jednym z cenniejszych dokumentów, jakie mam.
Dlaczego „uproszczenie” było pułapką
Pomysł scalenia był logiczny na poziomie powierzchownym: oba moduły są ze sobą powiązane, często działają razem, dzielą część danych. „Połączymy je w jeden” brzmi jak Dobra Praktyka.
Problem leżał głębiej.
Jeden moduł trzyma historię adresów — zmienia się rzadko, ale z implikacjami prawnymi. Każda zmiana adresu to zdarzenie z datą, powodem, stanem weryfikacji.
Drugi moduł decyduje, co użytkownik może robić w danej dzielnicy — zmienia się automatycznie, gdy zmienia się poziom weryfikacji. Kilka razy szybciej. Bez historii. Bez implikacji prawnych.
Gdybym je scalił, każda zmiana uprawnień wymagałaby zamrożenia całej historii adresowej. I odwrotnie: każde sprawdzenie, co użytkownik może zrobić, ładowałoby dane, których nie potrzebuje.
„Uproszczenie” sprawiłoby, że system stałby się cięższy, wolniejszy i trudniejszy do testowania — bez żadnej korzyści.
Co jest w takim dokumencie
Zapis odrzuconego pomysłu zawiera:
- Co konkretnie proponowałem (żeby za rok nie zinterpretować tego inaczej)
- Dlaczego brzmi to przekonująco (żeby rozumieć, co było kuszące)
- Dlaczego odrzucam (faktyczne rozumowanie, nie zdawkowe „bo nie”)
- Co by się stało, gdybym to zrobił (konkretne konsekwencje)
To ostatnie jest najważniejsze. Gdy za rok ktoś (albo ja sam) wróci do tego pomysłu, zobaczy nie tylko decyzję, ale jej koszty.
Praca solo: bez kogo zapisujesz decyzje?
Przy pracy zespołowej każda ważna decyzja przechodzi przez dyskusję — i ta dyskusja zostaje w czyjejś głowie, jeśli nie na papierze.
Solo dev tej dyskusji nie ma. Jedyną formą „drugiego zdania” jest własna przyszłość — ja za miesiąc, gdy wrócę do tego kodu.
Dokumenty z „nie” są moją formą rozmowy z przyszłym sobą. Mówią: „rozważałem to, nie bez powodu zdecydowałem inaczej, przeczytaj zanim zrobisz zmianę.”