19 czerwca 2025 roku byłem na PiterJS #79 w Petersburgu. Temat wieczoru był odświeżająco mało efektowny: nie jak dostarczyć kolejną funkcję, lecz jak utrzymywać to, co już zostało zbudowane — monitoring, deployment i refactoring.
Program dobrze trzymał się tego motywu. Pavel Shlykov mówił o ulepszaniu starego monolitu, Alexander Panfilov o FrontOps, a Igor Antonov o metrykach wydajności aplikacji webowych. Z każdego z tych tematów wyniosłem praktyczne notatki.
Niespodzianką była część Q&A. Ostatecznie wygrałem dwie nagrody za najlepsze pytania zadawane podczas sesji. To drobny szczegół, ale właśnie on został mi w pamięci najmocniej, bo przypomniał, dlaczego nadal cenię techniczne spotkania na żywo: można zrobić więcej niż tylko wysłuchać przygotowanej prezentacji. Można sprawdzić własne rozumienie tematu, kiedy osoby, które go właśnie przedstawiały, nadal są na miejscu.
Najciekawszym tematem było utrzymanie, nie nowości
Wydarzenia frontendowe łatwo zamieniają się w paradę nowych frameworków, API i abstrakcji. PiterJS #79 był bardziej przyziemny. Zapowiedziany temat dotyczył wspierania oprogramowania, które już istnieje.
To ważne, ponieważ duża część pracy inżynierskiej zaczyna się po pierwszym udanym wdrożeniu. Legacy monolit nie jest automatycznie złym systemem, a „modernizacja” nie musi oznaczać przepisywania wszystkiego od zera. Praktyczne pytanie jest zwykle węższe: które ograniczenie naprawdę boli system teraz i jaka zmiana zmniejszy ten problem, nie wprowadzając większego ryzyka niż to, które usuwa?
Dlatego trzy prelekcje dobrze się uzupełniały. Refactoring zmienia kod. FrontOps zmienia sposób budowania, pakowania, dostarczania i operowania frontendem. Praca nad wydajnością zmienia sposób mierzenia rezultatu. To różne warstwy tego samego problemu: jak utrzymać realny system zrozumiały i kontrolowalny, gdy już urósł.
FrontOps to coś więcej niż Dockerfile
Jedna z moich notatek z meetupu dotyczyła wdrażania FrontOps z Dockerem. Ważne rozróżnienie jest takie, że Docker jest narzędziem, a nie definicją FrontOps.
Odpowiedzialność za frontend nie musi kończyć się, gdy npm run build zwróci sukces. W systemie produkcyjnym ktoś nadal musi myśleć o powtarzalnych buildach, pakowaniu artefaktów, konfiguracji, rollbackach, cache i obserwowaniu awarii. Kontenery mogą uczynić część tych procesów bardziej przewidywalną, ale nie zastępują decyzji operacyjnych.
To przydatna korekta popularnego modelu myślenia: udany build dowodzi, że build się zakończył. Nie dowodzi, że aplikacja zostanie poprawnie wdrożona, będzie poprawnie działać na produkcji ani że łatwo będzie ją odtworzyć po awarii.
Wydajność zaczyna się od ustalenia, co znaczy „wolno”
Prelekcja o wydajności była szczególnie praktyczna w sposobie podejścia do pomiarów. W zapowiedzianym zakresie były czynniki wpływające na szybkość ładowania, różne frontendowe metryki wydajności, sposoby ilościowego opisania „wolno” oraz pytanie, dlaczego optymalizacja nie zawsze jest potrzebna.
Ten ostatni punkt łatwo zlekceważyć. „Zróbmy to szybciej” brzmi obiektywnie, ale bez metryki i widocznego dla użytkownika problemu może zmienić się w kosztowne zgadywanie. Sensowny proces pracy nad wydajnością zaczyna się od zdefiniowania, co faktycznie jest wolne, zmierzenia tego, znalezienia wąskiego gardła, zmiany jednej istotnej rzeczy i ponownego pomiaru.
Metryka sama w sobie nie jest doświadczeniem użytkownika, ale daje dyskusji wspólną jednostkę. Bez pomiarów optymalizacja może stać się zbiorem technicznie imponujących zmian bez jasnych dowodów, że poprawiły problem, który naprawdę miał znaczenie.
Q&A zmieniło dla mnie wartość meetupu
Mógłbym później obejrzeć nagrania i zebrać linki. Dużo trudniej odtworzyć interakcję wokół prelekcji. Dobre pytanie zmusza do skompresowania własnej niepewności do czegoś na tyle konkretnego, aby inny inżynier mógł na to odpowiedzieć.
Dwie nagrody były miłym dodatkiem, ale ważniejsza lekcja była prostsza: przyjście przygotowanym do aktywnego udziału daje z meetupu offline znacznie więcej niż traktowanie go jak playlisty YouTube na żywo.
Dobre pytanie techniczne zwykle ma kontekst i ograniczenie. Zamiast „Jaka architektura jest najlepsza?” bardziej użyteczne może być pytanie, jaki trade-off zmienia się, gdy zespół nie może przepisać systemu legacy, deployment musi zachować kompatybilność wsteczną albo metryka wydajności poprawia się bez odpowiadającej temu korzyści widocznej dla użytkownika.
Nie każde pytanie musi być błyskotliwe. Powinno pomagać ujawnić założenia, granice albo tryby awarii.
Co zabrałbym na kolejny meetup techniczny
- Wiedzieć, dlaczego dana prelekcja jest dla mnie ważna. Przed jej rozpoczęciem zapisać jeden realny problem albo wątpliwość.
- Oddzielać doświadczenie prelegenta od własnego systemu. Dobry case study to dowód, nie uniwersalny przepis.
- Pytać o trade-offy. „Kiedy byś tego nie użył?” często mówi więcej niż „Które narzędzie jest najlepsze?”
- Zapisać jedno konkretne działanie po spotkaniu. Notatka jest bardziej użyteczna, gdy prowadzi do czegoś, co później sprawdzę, przetestuję albo doczytam.
- Nie mylić przekonującej prelekcji z dowodem produkcyjnym. Decyzje dotyczące architektury, deploymentu i wydajności nadal trzeba zweryfikować we własnym środowisku.
Co zostało ze mną
Nie chcę przeceniać tego, co może zmienić jeden meetup. Nie wyszedłem z PiterJS z uniwersalnym przepisem na architekturę, a dobra prelekcja nie zastępuje dokumentacji, profilowania, testów ani danych produkcyjnych.
To, co faktycznie wyniosłem, jest bardziej konkretne: użyteczne notatki o modernizacji legacy monolitu, FrontOps z Dockerem i pomiarach wydajności webowej; dwie nagrody z Q&A; oraz kolejne przypomnienie, że warto pojawiać się osobiście w lokalnych społecznościach developerskich.
Nagranie może zachować prezentację. Najtrudniej zarchiwizować rozmowę, która dzieje się wokół niej.