Programista PHP w Poznaniu

#Programista PHP w Poznaniu pracuje dla handlu, nie dla samej technologii

Poznań jest zapleczem handlowym i produkcyjnym Wielkopolski i to widać w zleceniach, z którymi przychodzą tutejsze firmy. Rzadko kto zamawia “aplikację w PHP” dla samej aplikacji. Zamawia system ofertowy, który handlowcy otworzą na tablecie w hali targowej, integrację sklepu z magazynem, panel B2B dla hurtowników albo ratunek dla aplikacji, którą dziesięć lat temu napisał lokalny software house i która wciąż wystawia faktury, choć nikt już nie pamięta dlaczego działa. Programista PHP w Poznaniu jest w praktyce inżynierem od przepływu zamówień, dokumentów i stanów magazynowych, a PHP jest językiem, w którym ten przepływ od dwudziestu lat jest tu zapisany.

To nie jest przypadek. PHP napędza systemy, na których wielkopolski handel wyrósł: sklepy internetowe, platformy B2B, panele administracyjne, integracje z księgowością. W samym Poznaniu wyrosło na tym stosie Allegro, a setki mniejszych firm handlowych zbudowały wokół PHP swoje wewnętrzne narzędzia. Efekt jest taki, że w mieście krąży ogromna masa działającego, przynoszącego pieniądze kodu PHP w różnym wieku i różnej kondycji. Praca z tym kodem, jego rozwijanie, integrowanie i modernizowanie, to codzienność tego rynku, znacznie częstsza niż budowanie czegokolwiek od zera.

Ta strona opisuje, co konkretnie robię jako programista PHP dla firm z Poznania: jakie integracje powtarzają się na tym rynku, jak wygląda modernizacja starych aplikacji, dlaczego harmonogram projektu układa się tu pod kalendarz targowy i kiedy programista zwyczajnie nie jest potrzebny.

#Kalendarz MTP wyznacza terminy, których nie da się przesunąć

Międzynarodowe Targi Poznańskie narzucają rytm, który każdy wykonawca pracujący dla wielkopolskich firm musi znać. Budma na początku roku dla budownictwa, ITM Industry Europe dla przemysłu, Drema dla branży meblarskiej i drzewnej, Polagra dla spożywczej. Dla firmy, która się wystawia, targi to termin nieprzesuwalny: katalog produktów musi być aktualny, konfigurator musi działać na słabym targowym wifi, formularz zapytań musi przyjąć ruch z hali, a handlowcy muszą mieć dostęp do cen i stanów bez dzwonienia do biura.

Z perspektywy inżynierskiej wynika z tego kilka twardych reguł. Migracje wersji PHP, wymiany frameworka i inne prace o szerokim froncie ryzyka planuję tak, żeby zamknęły się na kilka tygodni przed imprezą, nigdy w tygodniu poprzedzającym. Ostatni sprint przed targami to wyłącznie poprawki, testy obciążeniowe na profilu ruchu z poprzedniej edycji i przegląd monitoringu. W trakcie targów obowiązuje zamrożenie wdrożeń: żadnych aktualizacji zależności, żadnych zmian w integracjach, tylko dyżur i obserwacja. Po targach przychodzi druga fala pracy, bo zebrane leady trafiają do CRM i nagle okazuje się, że eksport zapytań ofertowych do systemu handlowego, odkładany od roku, jest potrzebny na wczoraj.

Firmy, które przerabiały wdrożenie nowej wersji serwisu na dwa dni przed Budmą, znają koszt ignorowania tego rytmu. Dlatego pierwsze pytanie na rozmowie o projekcie dla wystawcy nie brzmi “jaki framework”, tylko “kiedy macie najbliższe targi”.

#Integracje PHP z enova365, Comarch ERP Optima i Subiektem

Najczęstsze zlecenie od firm handlowych z Poznania nie dotyczy frontendu. Dotyczy szwu między sklepem albo platformą B2B a systemem ERP, w którym firma naprawdę żyje. W Wielkopolsce ten system to zwykle enova365, Comarch ERP Optima albo Subiekt, czasem coś starszego, co komunikuje się wyłącznie przez wymianę plików na FTP. Zadanie brzmi zawsze podobnie: stany magazynowe i ceny mają płynąć do sklepu, zamówienia w drugą stronę, statusy wysyłek wracać do klienta, a faktury trafiać w obieg KSeF bez ręcznego przepisywania.

Prosta wersja tej integracji, czyli skrypt wywoływany z crona, który w pętli odpytuje API, działa do pierwszego dnia z prawdziwym ruchem. Potem ERP przestaje odpowiadać w trakcie synchronizacji, to samo zamówienie wchodzi dwa razy, a różnice w stanach magazynowych wychodzą dopiero przy inwentaryzacji. Dlatego każdą integrację buduję na kilku zasadach, które są nudne dokładnie tak, jak powinny być. Przetwarzanie komunikatów jest idempotentne, więc ponowne przetworzenie tego samego zamówienia nie tworzy duplikatu. Wymiana idzie przez kolejkę z automatycznymi ponowieniami i osobnym torem dla komunikatów, których nie udało się przetworzyć, zamiast przez wywołania w locie, które znikają razem z timeoutem. Każda operacja zostawia ślad, z którego księgowość jest w stanie odtworzyć, co, kiedy i w którą stronę zostało przesłane. Po wejściu obowiązkowego KSeF ten ślad przestał być luksusem, a stał się wymogiem, bo rozjazd między systemem handlowym a fakturami w KSeF trzeba umieć wyjaśnić.

Od strony PHP to praca na kliencie HTTP z sensowną obsługą błędów, mapowaniu danych z tolerancją na niespodzianki po stronie ERP i testach integracyjnych na nagraniach prawdziwych odpowiedzi, żeby zmiana w API wyszła w CI, a nie na produkcji w piątek.

#Modernizacja starych aplikacji PHP, które wciąż zarabiają

Drugi filar poznańskich zleceń to aplikacje z lat 2008 do 2016: systemy ofertowe, panele B2B, autorskie CMS-y i sklepy, pisane przez lokalne software house’y albo przez programistę, który dawno zmienił pracę. Te systemy zarabiają, więc nikt ich nie wyłączy, ale strach przed dotknięciem kodu rośnie z każdym rokiem. Typowe objawy: produkcja stoi na PHP 7.4 albo starszym, bo hosting jeszcze pozwala, zależności są wklejone do repozytorium zamiast zarządzane Composerem, testów nie ma, a wiedza o tym, czemu pewien fragment wygląda dziwnie, odeszła z ostatnim pracownikiem, który go rozumiał.

Modernizację takiego systemu prowadzę zawsze w tej samej kolejności i nigdy jako wielkie przepisanie. Najpierw kopia deweloperska i analiza statyczna: PHPStan pokazuje, gdzie kod polega na zachowaniach usuniętych w PHP 8, a audyt zależności pokazuje, które biblioteki mają następców, a które trzeba będzie zastąpić. Potem testy charakteryzujące wokół ścieżek, które przynoszą pieniądze, czyli złożenie zamówienia, wycena, wystawienie dokumentu. Dopiero mając tę siatkę bezpieczeństwa uruchamiam Rectora do mechanicznych przekształceń i przechodzę wersje PHP przyrostowo, wydanie po wydaniu, z osobnym wdrożeniem na każdy krok. Stare ścieżki kodu usuwam po zweryfikowaniu nowych na produkcji, nie przed.

Cel inżynierski jest zawsze ten sam: aplikacja na wspieranej wersji PHP, z zależnościami pod kontrolą Composera, z testami na ścieżkach krytycznych i z kodem, który następny programista otworzy bez archeologii. Biznesowo oznacza to, że firma znów może zamawiać zmiany, zamiast omijać własny system szerokim łukiem.

#WordPress i WooCommerce to też praca w PHP

Spora część zapytań o programistę PHP w Poznaniu dotyczy w praktyce WordPressa i WooCommerce, bo na nich stoi warstwa marketingowa i sklepowa wielu wielkopolskich firm. To nie jest inna dyscyplina. WooCommerce jest aplikacją PHP z własnym systemem hooków, warstwą bazodanową i REST API, i dokładnie tak należy go traktować, gdy kończą się możliwości gotowych wtyczek.

Praca programisty zaczyna się tam, gdzie logika jest specyficzna dla firmy: cennik B2B zależny od kontrahenta i wolumenu, walidacja zamówień pod reguły magazynu, synchronizacja produktów z ERP, eksport zamówień w formacie, którego oczekuje spedycja. Takie rzeczy zamykam we własnych wtyczkach, z logiką podpiętą pod hooki zamiast modyfikacji rdzenia czy motywu, z zapytaniami przez warstwę bazodanową WordPressa z przygotowanymi parametrami i z endpointami REST tam, gdzie z danymi ma rozmawiać system zewnętrzny. Kod trzyma standardy WordPress Coding Standards, przechodzi przez repozytorium i środowisko testowe, a aktualizacje rdzenia i wtyczek nie nadpisują niczego, bo nic nie zostało wstawione w cudze pliki.

Granicę stawiam uczciwie także w drugą stronę. Jeśli projekt polega na złożeniu strony z gotowego motywu i konfiguracji wtyczek z katalogu, to jest robota wdrożeniowca, nie programisty, i kosztuje odpowiednio mniej. Mówię to na etapie wyceny, bo płacenie stawki inżynierskiej za klikanie w konfigurator nie ma sensu. Szerzej o pracy z samym WordPressem piszę na stronie programowania WordPress w Poznaniu, a o warstwie sklepowej przy programiście WooCommerce w Poznaniu.

#Warsztat: PHP 8.3, Composer, testy i profilowanie

Konkrety warsztatowe, bo o nie pytają działy IT. Nowy kod piszę na PHP 8.3, ze ścisłym typowaniem zadeklarowanym w każdym pliku i typami na parametrach oraz wartościach zwracanych. Zależności wyłącznie przez Composera, z zablokowanymi wersjami i audytem znanych podatności w CI. Analiza statyczna PHPStanem na poziomie, który w nowym kodzie nie przepuszcza ignorowanych błędów; w kodzie przejętym poziom podnoszę etapami, żeby narzędzie pomagało, a nie paraliżowało. Testy w PHPUnit, z pokryciem dobieranym według ryzyka biznesowego: ścieżka zamówienia i rozliczeń ma testy zawsze, formatka edycji banera niekoniecznie.

Wydajność traktuję jako pracę na pomiarach. Zanim cokolwiek przyspieszę, profiluję: Xdebug na środowisku deweloperskim, profiler produkcyjny tam, gdzie problem widać tylko pod prawdziwym ruchem. Typowe znaleziska w aplikacjach z tego rynku są przewidywalne, zapytania wykonywane w pętli zamiast jednego z warunkiem, brak indeksów pod realne wzorce filtrowania, cache, którego nie ma albo który jest, ale nigdy nie jest trafiany. Poprawki idą od największego zysku, a po każdej wraca pomiar na tych samych metrykach, bo optymalizacja bez pomiaru to zgadywanie.

Proces dowożenia jest równie nieefektowny co skuteczny: git z przeglądem kodu, CI uruchamiające linting, analizę statyczną i testy przy każdej zmianie, wdrożenia przez środowisko testowe w uzgodnionych oknach, monitoring błędów na produkcji. Nic z tej listy nie jest ozdobą. Każdy element jest odpowiedzią na jakąś awarię, którą ktoś kiedyś przeżył w tygodniu targowym.

#Politechnika, UAM i rachunek za rekrutację seniora

Poznań kształci programistów na Politechnice Poznańskiej i na UAM, więc na rynku nie brakuje ludzi, którzy znają PHP. Problem, z którym przychodzą lokalne firmy, leży piętro wyżej. Absolwent poprowadzi CRUD-a w Laravelu, ale migracji piętnastoletniego systemu ofertowego na PHP 8.3 bez zatrzymania sprzedaży nie zrobi, bo tego nie uczy żaden przedmiot, tylko kilka takich migracji w nogach. Seniorzy z tym doświadczeniem w Poznaniu są, ale konkuruje o nich Allegro, technologiczne zaplecze Żabki i software house’y pracujące dla klientów zagranicznych, płacące stawki, których firma handlowa z dwudziestoma pracownikami nie uzasadni dla jednego etatu.

Rachunek dla takiej firmy wygląda więc następująco. Rekrutacja seniora PHP trwa miesiącami, a po zatrudnieniu firma płaci pełny etat, którego realna potrzeba wynosi może jedną trzecią czasu, bo system wymaga intensywnej pracy przy modernizacji i integracjach, a potem spokojnego utrzymania. Alternatywą jest senior kontraktowy: intensywne zaangażowanie na czas projektu, potem mniejszy, przewidywalny wymiar na rozwój i opiekę, bez kosztów rekrutacji i bez ryzyka, że jedyny programista w firmie odejdzie razem z całą wiedzą.

Żeby ten drugi model nie tworzył nowego uzależnienia, wszystko od pierwszego dnia jest po stronie firmy: repozytorium, dostępy, dokumentacja decyzji architektonicznych i sesje przekazania wiedzy. Jeśli firma kiedyś zatrudni własnego programistę, dostanie on projekt, który da się przejąć w tygodnie. Taki standard przekazania traktuję jako część usługi, nie jako gest dobrej woli.

#Profile typowych wdrożeń i ich cele inżynierskie

Zamiast obietnic, trzy profile projektów, które na tym rynku wracają regularnie, z celami inżynierskimi, po których można rozliczyć wykonanie.

Producent z ofertą targową. Firma produkcyjna z okolic Poznania wystawia się na dwóch imprezach MTP rocznie i potrzebuje konfiguratora produktów spiętego z cennikiem w ERP. Cele: konfigurator działa offline’owo na tabletach handlowców przy zrywanym łączu, ceny i dostępności pochodzą z enova365 z synchronizacją, której opóźnienie jest znane i akceptowane przez handel, a zapytania z targów lądują w CRM tego samego dnia. Harmonogram liczony wstecz od daty targów, z zamrożeniem zmian na dwa tygodnie przed.

Hurtownia z panelem B2B na starym PHP. System zamówień hurtowych z 2012 roku, PHP 5.6, brak testów, autor nieosiągalny. Cele: aplikacja na PHP 8.3 i wspieranym stosie, zależności pod Composerem, testy charakteryzujące na ścieżce zamówienia i rozliczeń, dokumentacja pozwalająca przejąć projekt kolejnemu zespołowi. Warunek brzegowy: sprzedaż nie zatrzymuje się ani na dzień, więc migracja idzie etapami za siatką testów.

Sklep WooCommerce zintegrowany z Subiektem. Sprzedawca detaliczny z rosnącym kanałem online, stany magazynowe przepisywane ręcznie. Cele: synchronizacja stanów i cen z Subiektem przez kolejkę z idempotentnym przetwarzaniem, zamówienia trafiające do ERP bez ręcznego przepisywania, dokumenty w obiegu KSeF, log operacji czytelny dla księgowości. Kryterium odbioru: inwentaryzacja po kwartale bez niewyjaśnionych rozjazdów między sklepem a magazynem.

#Kiedy programista PHP nie jest potrzebny

Uczciwość na etapie kwalifikacji oszczędza obu stronom pieniędzy, więc granicę opisuję wprost. Programista nie jest potrzebny, gdy zadanie zamyka się w konfiguracji: prosta strona firmowa na gotowym motywie, sklep na standardowych wtyczkach bez integracji, zmiana treści i grafik. Nie jest też potrzebny, gdy prawdziwym problemem jest treść oferty albo proces handlowy, bo żaden refaktor nie naprawi cennika, którego handlowcy nie rozumieją. Bywa wreszcie, że firmie potrzebna jest nie praca programistyczna, tylko stabilna opieka techniczna nad działającym serwisem, z aktualizacjami, kopiami i monitoringiem; do tego służy opieka techniczna WordPress w Poznaniu.

Praca dla programisty zaczyna się tam, gdzie pojawia się logika, której nie ma w żadnym gotowym rozwiązaniu: integracja z ERP, reguły cenowe B2B, modernizacja odziedziczonego kodu, wymagania wydajnościowe pod konkretny szczyt ruchu. Prosty test: jeśli wymaganie da się opisać zdaniem “system ma zrobić X, gdy stanie się Y”, a żadna sprawdzona wtyczka ani moduł tego nie robi, to jest zadanie na kod. Jeśli nie, taniej będzie bez programisty i taką rekomendację też można ode mnie usłyszeć.

#Współpraca B2B i pierwszy krok

Pracuję w modelu B2B, na umowie i fakturze VAT, w jurysdykcji UE. Wycena jest indywidualna, bo zależy od stanu zastanego kodu i zakresu integracji, a nie od cennika; zanim ją podam, chcę zobaczyć repozytorium albo kopię aplikacji i przepuścić ją przez analizę statyczną. Projekt dzielę na etapy z mierzalnym efektem, więc po każdym etapie można współpracę zakończyć z działającym rezultatem, a nie z połową budowy. Własność jest po stronie klienta od pierwszego dnia: kod w repozytorium firmy, dostępy na kontach firmy, dokumentacja pisana dla następnego zespołu.

Najlepszy pierwszy krok to krótka wiadomość z trzema informacjami: co system ma robić, z czym ma się integrować (ERP, płatności, logistyka, KSeF) i jakie terminy są nieprzesuwalne, łącznie z datami targów. Nie trzeba kompletować dostępów ani pisać specyfikacji; do pierwszej rozmowy wystarczy opis problemu i, jeśli istnieje, dostęp do kodu tylko do odczytu. Odpowiadam w ciągu jednego dnia roboczego, a jeśli z przeglądu wyjdzie, że zadanie nie wymaga programisty albo że taniej rozwiąże je inna usługa, usłyszysz to wprost razem z uzasadnieniem.