Case study: Kiedy największym wyzwaniem nie jest napisanie kodu, lecz zrozumienie cudzego sposobu myślenia.
Na pierwszy rzut oka projekt wydawał się prosty.
Należało wdrożyć nowy system rezerwacji do istniejącej strony internetowej, zachowując jej dotychczasowy wygląd.
Brzmi jak typowa modyfikacja wtyczki WordPressa.
Po rozpoczęciu prac okazało się jednak, że największym wyzwaniem nie był ani WordPress, ani sam system rezerwacji.
Najwięcej czasu zajęło zrozumienie, dlaczego autor strony wykonał ją właśnie w taki sposób.
Strona nie była zepsuta
To nie była naprawa WordPressa.
To była próba usprawnienia procesu, który z czasem przestał odpowiadać potrzebom klienta. Sprawy zapleczowe.
Sama strona została wykonana kilka lat wcześniej w dość old-schoolowym stylu, z wykorzystaniem Advanced Custom Fields.
Do edycji było sześć podstron – osobno usługa dzienna i nocna, każda w trzech wersjach językowych.
Na pierwszy rzut oka wszystko wyglądało przejrzyście.
Dopiero podczas analizy okazało się, że logika całego rozwiązania jest znacznie bardziej złożona, niż sugerowała liczba podstron.
Cudzy kod to trochę jak archeologia
Pisząc własny projekt, znamy każdą decyzję.
Wiemy, dlaczego coś powstało w określony sposób.
Pracując nad cudzym kodem, najpierw trzeba odtworzyć tok myślenia osoby, która tworzyła go kilka lat wcześniej.
Dlaczego wykorzystała właśnie takie pola ACF?
Dlaczego dane są przechowywane w ten sposób?
Dlaczego jedna zmiana wpływa na trzy inne miejsca?
To są pytania, na które nie odpowie dokumentacja, jeśli jej nie ma.
(Dokumentacja była, ale napisana pod procesy klienta, nie admina.)
Programowanie bardzo często nie polega na pisaniu nowego kodu, lecz polega na zrozumieniu starego.
Presja czasu nie pomaga
Projekt miał zostać wykonany szybko.
Dziś wiem, że zbyt optymistycznie oceniłam czas potrzebny na analizę istniejącego rozwiązania.
Im głębiej wchodziłam w projekt, tym bardziej okazywało się, że pozornie prosta zmiana wymaga zrozumienia całej architektury strony. I oczekiwań klienta zarazem.
Samo napisanie kodu nie było największym problemem.
Problemem było zrozumienie zależności.
Gdzie popełniłam błąd
W pewnym momencie zdecydowałam się wykorzystać Gemini do wygenerowania części brakujących modułów.
Uznałam, że przyspieszy to pracę.
Okazało się jednak, że w tak specyficznym projekcie było to złe narzędzie.
Kod wyglądał poprawnie, ale nie rozumiał istniejącej architektury strony.
To nie była wina sztucznej inteligencji.
To była moja decyzja o wyborze narzędzia do zadania, które wymagało przede wszystkim głębokiego zrozumienia istniejącego rozwiązania.
Dzisiaj podjęłabym inną decyzję.
Najpierw jeszcze dokładniejsza analiza.
Dopiero później implementacja.
Nie każdy projekt kończy się sukcesem
Ostatecznie nie dowiozłam tego wdrożenia.
Uznałam, że dalsze próby nie będą uczciwe wobec klienta.
Zwróciłam zaliczkę i zakończyłam projekt.
Nie była to łatwa decyzja.
Ten projekt mocno mną wstrząsnął i na pewien czas odebrał mi pewność siebie.
Z perspektywy czasu widzę jednak, że była to jedna z najcenniejszych lekcji w mojej pracy.
Czego nauczyła mnie ta sytuacja
Dzisiaj dużo ostrożniej oceniam podobne zlecenia.
Nie zakładam już, że skoro zmiana wygląda na prostą, to rzeczywiście taka będzie.
Najpierw chcę zrozumieć sposób działania całego rozwiązania.
Dopiero później planuję wdrożenie.
Coraz częściej dochodzę też do wniosku, że najtrudniejszą częścią pracy webmastera nie jest pisanie kodu.
Jest nią zrozumienie decyzji, które kilka lat wcześniej podjął ktoś inny.
To właśnie analiza, a nie samo programowanie, bardzo często zajmuje najwięcej czasu.
I właśnie dlatego wycena takich projektów nigdy nie powinna opierać się wyłącznie na liczbie godzin potrzebnych do napisania kodu.
Bo czasem największym wyzwaniem jest nie stworzenie nowego rozwiązania, lecz zrozumienie starego.
