Co się stanie z Twoją firmą, gdy jedyny programista znający system odejdzie

legacybus factormigracjaElixirWszystkie tagi

Nazwijmy go Tomek. Tomek pracuje u Ciebie od 12 lat. Tomek napisał system, który obsługuje zamówienia, magazyn i fakturowanie. Tomek zna każdy quirk, każdy workaround, każdą "tymczasową łatkę" która działa od 8 lat. Tomek jest jedyną osobą, która potrafi zrestartować serwer, gdy system padnie w niedzielę o 3 w nocy.

Tomek właśnie dostał ofertę za 40% więcej.

Bus factor = 1

W inżynierii oprogramowania jest termin "bus factor" - ilu ludzi musi "wpaść pod autobus" (metaforycznie: odejść, zachorować, pojechać na urlop), żeby projekt utknął. Jeśli ta liczba wynosi 1, masz problem. Nie "potencjalny problem w przyszłości" - masz bombę zegarową, która tyka.

I nie chodzi tylko o odejście. Pomyśl o:

  • Tomek idzie na 3-tygodniowy urlop. System pada w drugim tygodniu
  • Tomek choruje. System wymaga pilnej zmiany, bo zmienił się stawka VAT
  • Tomek ma wypadek. Nie dramatyzujmy, ale takie rzeczy się zdarzają
  • Tomek jest na spotkaniu. Klient dzwoni z błędem krytycznym. Nikt inny nie wie, gdzie szukać

Dlaczego tak się dzieje

Organiczny wzrost systemu

System nie powstał z planem architektonicznym. Zaczęło się od "Tomku, zrób nam prosty formularz do zamówień". Potem dorosło: "Dodaj magazyn. Dodaj faktury. Dodaj raport dla zarządu. Podłącz się do kuriera. Zrób eksport do księgowej."

Przez 12 lat Tomek budował system kawałek po kawałku. Każdy kawałek ma sens, ale tylko w kontekście, który Tomek trzyma w głowie. Nie ma dokumentacji, bo "nie było czasu". Nie ma testów, bo "Tomek wie co sprawdzić". Nie ma README, bo "Tomek pamięta jak to odpalić".

Wiedza w głowie, nie w kodzie

Tomek wie, że:

  • Moduł faktur nie działa, jeśli najpierw nie uruchomi się skrypt fix_vat.sql z 2019 roku
  • Import z Allegro wymaga ręcznego restartu crona co poniedziałek, bo "coś się zacina"
  • Kolumna status w tabeli zamowienia ma 14 możliwych wartości, z czego 3 to "legacy z czasów starego systemu" i nie wolno ich usuwać
  • Serwer produkcyjny ma 3 zadania cron, których nie ma w żadnym repozytorium - Tomek dodał je ręcznie na serwerze
  • Jeśli baza urośnie powyżej 50GB, trzeba ręcznie zarchiwizować tabelę logów, bo "kiedyś zabrakło miejsca i system padł"

Żadna z tych informacji nie jest zapisana. Każda jest krytyczna.

Pseudo-oszczędność na dokumentacji

"Po co dokumentować, skoro Tomek i tak wie?" - to zdanie padło w każdej firmie, z którą rozmawiamy. Oszczędność pozorna: 100 godzin na dokumentację kosztuje ułamek tego, co tydzień przestoju po odejściu Tomka.

Co się dzieje, gdy Tomek odchodzi

Scenariusz optymistyczny

Tomek daje 3 miesiące wypowiedzenia i jest chętny do przekazania wiedzy. Zatrudniasz nowego programistę. Tomek próbuje mu wytłumaczyć 12 lat historii w 12 tygodni. Nowy programista kiwa głową, notuje, a po odejściu Tomka odkrywa, że notatki pokrywają 30% tego, co powinien wiedzieć.

Przez następne 6 miesięcy nowy programista gasi pożary, odkrywając kolejne "Tomkowe sztuczki" metodą prób i błędów. Firma traci czas, pieniądze i nerwy.

Scenariusz pesymistyczny

Tomek odchodzi z dnia na dzień (ma prawo, jeśli firma naruszy warunki umowy). Albo Tomek choruje przewlekle. Zostajesz z systemem, którego nikt nie rozumie, serwer wymaga interwencji, której nikt nie potrafi wykonać, a klienci dzwonią z pytaniem dlaczego ich zamówienia nie przychodzą.

Zatrudniasz firmę zewnętrzną do "ratowania" systemu. Firma patrzy na kod, wzdycha i mówi: "Przepisanie od zera będzie szybsze niż zrozumienie tego". Miesiące przestoju, setki tysięcy złotych kosztów.

Scenariusz realistyczny

Gdzieś pomiędzy. Tomek odchodzi, nowy człowiek przychodzi, jakoś to ciągnie. Ale "jakoś" oznacza:

  • Każda zmiana w systemie trwa 3x dłużej, bo nowy musi najpierw zrozumieć kontekst
  • Błędy, które Tomek naprawiał w 10 minut, teraz zajmują pół dnia
  • Nowe funkcje nie są dodawane, bo nikt nie ma odwagi ruszać kodu
  • System powoli umiera - nie jest rozwijany, tylko łatany

Jak się zabezpieczyć (naprawdę)

Dokumentacja nie wystarczy

Poważnie. Dokumentacja jest ważna, ale nie jest rozwiązaniem. System, który wymaga 200-stronicowej instrukcji obsługi, to system z problemem architektonicznym. Dokumentacja się dezaktualizuje. Ludzie jej nie czytają. Kluczowe informacje są pomijane, bo "to oczywiste" (dla Tomka).

Potrzebujesz systemu, który dokumentuje się sam

To nie marketing - to konkretna filozofia budowy oprogramowania:

Czytelny kod zamiast komentarzy. Elixir ma składnię, która czyta się jak zdania w języku angielskim. Nowy programista otwiera moduł Zamowienia.zmien_status/2 i wie co robi, bez szukania w dokumentacji.

Konwencja nad konfiguracją. Phoenix ma ustaloną strukturę projektu. Każdy programista Elixir wie, gdzie szukać modeli, kontrolerów, szablonów, migracji bazy danych. Nie trzeba "znać projekt" - trzeba znać framework.

Testy jako dokumentacja. Test "wystawienie faktury z błędnym NIP zwraca błąd walidacji" mówi więcej niż 3 strony dokumentacji. Testy nie kłamią, nie dezaktualizują się (bo system by się nie zbudował) i można je uruchomić jednym poleceniem.

Migracje bazy danych w kodzie. Każda zmiana w strukturze bazy jest zapisana jako plik migracji. Nowy programista uruchamia mix ecto.migrate i ma identyczną bazę jak produkcja. Nie potrzebuje "skryptu Tomka z 2019 roku".

Infrastruktura jako kod. Konfiguracja serwera, zadania cron, zmienne środowiskowe - wszystko w repozytorium. Nie w głowie Tomka, nie na karteczce, nie "ręcznie na serwerze". git clone, docker compose up - system działa.

CI/CD - maszyna zamiast człowieka

W firmach z bus factor = 1, deployment wygląda tak: Tomek loguje się na serwer przez SSH, robi git pull, restartuje usługę, sprawdza logi. Jeśli Tomka nie ma - nikt nie deployuje.

W nowoczesnym stacku:

  • Programista pushuje kod do repozytorium
  • Automatyczne testy sprawdzają, czy nic się nie zepsuło
  • Jeśli testy przechodzą, system automatycznie wdraża się na produkcję
  • Jeśli coś pójdzie nie tak, automatycznie wraca do poprzedniej wersji

Zero ręcznej interwencji. Zero wiedzy tajemnej.

Migracja jako ubezpieczenie

Migracja legacy systemu do Phoenix LiveView to nie jest koszt - to ubezpieczenie. Ubezpieczenie od:

  • Odejścia kluczowego pracownika - nowy programista Elixir jest produktywny w tygodniach, nie miesiącach
  • Przestojów - BEAM i supervisor trees gwarantują, że system wstaje sam po awarii
  • Stagnacji - nowe funkcje można dodawać bezpiecznie, bo testy pilnują, że nic się nie zepsuło
  • Uzależnienia od jednego dostawcy - kod jest w standardowym frameworku, każdy programista Elixir może go przejąć

Ile kosztuje to ubezpieczenie vs ile kosztuje brak

Policzmy pesymistycznie. Tomek odchodzi, system stoi tydzień (optimistycznie), naprawy trwają 3 miesiące:

  • Tydzień przestoju: utracone zamówienia, kary za opóźnienia, praca ręczna zamiast systemu
  • 3 miesiące napraw: programista zewnętrzny za 200-400 zł/h, badający system którego nie zna
  • Utrata klientów: ile osób pójdzie do konkurencji, gdy ich zamówienie nie przyjdzie na czas?

Koszt migracji systemu do Phoenix LiveView jest ułamkiem kosztu katastrofy. Z tą różnicą, że migracja to inwestycja, która zwraca się przez lata. Katastrofa to czysta strata.

Zacznij dziś, nie gdy będzie za późno

Nie czekaj, aż Tomek złoży wypowiedzenie. Zacznij teraz:

  1. Spisz wiedzę - nawet niedoskonale. Poproś Tomka o spisanie "rzeczy, które tylko ja wiem o systemie". Daj mu na to tydzień. To powstanie będzie niekompletne, ale lepsze niż nic
  2. Zidentyfikuj krytyczne procesy - które elementy systemu muszą działać, żeby firma działała?
  3. Zaplanuj migrację - nie musisz przepisywać wszystkiego naraz. Zacznij od najkrytyczniejszego modułu

Masz system z bus factor = 1 i chcesz to zmienić? Porozmawiajmy - pomożemy ocenić ryzyko i zaplanować migrację, która zabezpieczy Twoją firmę.