04/08/2026
„Działa? Działa.” A teraz spróbuj dodać do tego jeden czujnik… 🏗️💻
Scenariusz, który zna chyba każdy programista PLC.
Maszyna od miesięcy klepie produkcję bez zająknięcia. Przyjeżdżasz na obiekt na „szybką modyfikację”. Zlecenie brzmi banalnie: dociągnąć sygnał z jednego, nowego czujnika, wrzucić go w logikę i wracać do domu. Szybka piłka, pół godziny roboty z kawą w ręku.
A potem wpinasz się do sterownika, otwierasz projekt, patrzysz na strukturę kodu i... czujesz, jak ucieka z Ciebie cała nadzieja.
Zamiast przejrzystego kodu witasz się z monumentalnym programistycznym spaghetti. Brak komentarzy, a w pamięci straszą zmienne typu temp_3, zmienna_final i NIE_KASOWAC. Z resztkami nadziei wgrywasz zmianę i... cyk.
Maszyna się zatrzymuje, HMI wyświetla tonę błędów, z pozoru prosty sygnał wywraca do góry nogami całą architekturę programu, a ty właśnie wszedłeś na pole minowe.
Dlaczego dołożenie „jednego czujnika” w dojrzałym programie tak często zamienia się w inżynieryjne pole minowe?
Bo „działający kod” i „dobry kod” to dwie bardzo różne rzeczy.
Większość takich historii zaczyna się od pośpiechu i podejścia „grunt, że klepie sztuki”. Tysiące linii kodu pisanych bez podziału na funkcje, statusy rzucane gdzie podpadnie i brak dokumentacji tworzą gigantyczny dług technologiczny. A ten dług płaci później osoba, która przyjeżdża na „szybką poprawkę”.
Kod żyje znacznie dłużej niż nasza pamięć o nim. Dopisując jeden czujnik, nie modyfikujesz izolowanego fragmentu – ruszasz naciągniętą strunę w logice całej stacji. Nagle okazuje się, że zwykła edycja warunku w jednym miejscu blokuje sekwencję, wywraca tryb bazowania albo wpływa na warunki gotowości chwytaka.
Bez czytelnego mapowania I/O i modularności, drobna zmiana wywołuje efekt domina na całej stacji. Zamiast wypić kawę i wracać do domu, spędzasz pół dnia na odplątywaniu uśpionych zależności, sprzątając po kimś (lub po sobie), kto kilka lat temu uznał, że Tag_66 i zmienna_final całkowicie wystarczą.
I tak z „szybkiej modyfikacji na pół godziny” robi się wielogodzinne rzeźbienie, pisanie łatek do łatek i błaganie przy pierwszym uruchomieniu, żeby linia wystartowała na kolejnej zmianie.
Dlatego pisanie czystego, modułowego kodu i trzymanie się standardów to nie sztuka dla sztuki – to polisa ubezpieczeniowa na moment, gdy ktoś (albo Ty sam z parę lat) będzie musiał ten układ rozbudować.
Trafiliście kiedyś na kod, w którym prosta modyfikacja skończyła się pisaniem programu od zera na obiekcie?