Każda linia kodu staje się czymś, co później trzeba zrozumieć, przetestować, zabezpieczyć, zmigrować i wyjaśnić. Inżynieria „najpierw myślenie” nie jest wolniejsza – zapobiega szybszemu budowaniu niewłaściwego obciążenia.

Niedawno pracowaliśmy z dużym sprzedawcą na Shopify, który był przekonany, że potrzebuje zbudowanego na zamówienie silnika lojalnościowego do obsługi złożonej logiki dla klientów Tier-1. Jego wewnętrzny zespół przygotował już 40-stronicowy dokument wymagań technicznych dla dedykowanej aplikacji prywatnej. Po trzech dniach przeglądu architektury porzuciliśmy cały plan i wdrożyliśmy integrację headless z istniejącym narzędziem klasy enterprise, uzupełnioną kilkoma przemyślanymi fragmentami kodu Liquid.

Rezygnując z napisania ponad 5000 linii kodu w Ruby, zaoszczędziliśmy klientowi 50 000 € początkowych kosztów rozwoju i wyeliminowaliśmy około 15 godzin miesięcznego nakładu na utrzymanie. Sprzedawca nie potrzebował więcej kodu – potrzebował rozwiązania. Na tym polega inżynieria „najpierw myślenie”: na uznaniu, że kod nie jest aktywem, lecz obciążeniem, które musi być uzasadnione.

Wysoki koszt złudzenia „szybkości wdrażania”

Wielu liderów technicznych tkwi dziś w pułapce mierzenia produktywności liczbą zamkniętych zgłoszeń w JIRA lub wypchniętych commitów na GitHubie. To niebezpieczna miara, ponieważ premiuje tworzenie artefaktów zamiast rozwiązywania problemów. W nowoczesnym stosie technologicznym każda nowa funkcja zwiększa powierzchnię podatną na luki bezpieczeństwa, regresje wydajności i dług techniczny.

Gdy zespół szczyci się szybkim wdrażaniem bez wcześniejszego namysłu, w praktyce przyspiesza w kierunku przepaści. 20-osobowy zespół inżynierski może z łatwością przeznaczać 40% swoich sprintów wyłącznie na radzenie sobie ze skutkami ubocznymi wcześniejszych funkcji, które nigdy nie powinny były powstać. Najczęściej widzimy to w e-commerce, gdzie „szybka poprawka” przypadku brzegowego w checkoucie po sześciu miesiącach psuje potok danych całego pakietu analitycznego.

Kod wymaga testów, dokumentacji i wysiłku umysłowego od każdej nowej osoby dołączającej do zespołu. Jeśli problem da się rozwiązać zmianą procesu biznesowego lub natywną funkcją platformy – to wygrana. Najbardziej eleganckie rozwiązanie to takie, które nie wymaga ani jednej linii utrzymania.

Najpierw myślenie: podejście prokuratora do wymagań

W DATATIP traktujemy każdą prośbę o nową funkcję tak, jakby stawała przed sądem. Zanim otworzymy IDE, występujemy w roli oskarżenia i przesłuchujemy konieczność napisania kodu. Nie chodzi o biurokratyczne spowalnianie, lecz o taktyczne tarcie, które ma zapobiegać rozrostowi architektury.

Aby sprawdzić, czy budowa jest konieczna, stosujemy prosty schemat. Najpierw przeprowadzamy test gumki: czy problem można rozwiązać, usuwając funkcję lub upraszczając interfejs? Często wolny checkout to nie problem bazy danych, lecz problem „zbyt wielu pól formularza”. Po drugie wymagamy RFC-Lite (Request for Comments). Jeśli inżynier nie potrafi wyjaśnić logiki i kompromisów prostym językiem na jednej stronie, nie jest jeszcze gotowy, by pisać kod.

„Dzięki AI koszt generowania kodu spadł niemal do zera, ale koszt jego utrzymania pozostaje tak wysoki jak zawsze. Jeśli AI służy do pisania większej ilości kodu szybciej, po prostu zaciąga się dług na wyższy procent”.

AI do walidacji, a nie tylko do generowania

Wraz z rozwojem LLM i narzędzi takich jak Cursor bariera wejścia w dostarczanie kodu zniknęła. Doprowadziło to do zalewu przeciętnych, generowanych przez AI pull requestów, które leczą bieżące objawy, ignorując kondycję całego systemu. Uważamy, że prawdziwa wartość AI w 2024 roku polega na testowaniu wytrzymałości logiki, a nie na generowaniu składni.

Zamiast prosić AI o „zbudowanie własnego middleware”, używamy jej do znajdowania przypadków brzegowych w naszych planach architektonicznych. Prosimy ją o symulację, jak nowy schemat danych mógłby zawieść przy 10-krotnym obciążeniu, albo o zaproponowanie trzech sposobów osiągnięcia celu biznesowego wyłącznie za pomocą natywnych API Shopify. Zmienia to rolę inżyniera z budowniczego w kuratora i menedżera ryzyka. Inżynier jest pilotem, AI – silnikiem. Szybszy silnik sprawi tylko, że szybciej się zabłądzi, jeśli cel podróży nie został wyznaczony.

Kompromis: radykalna szczerość a prośby o nowe funkcje

Przyjęcie takiego sposobu myślenia wymaga zmiany kultury, w której „nie” jest prawidłowym i szanowanym wynikiem pracy inżynierskiej. Oznacza to powiedzenie interesariuszowi, że wymarzony dashboard na zamówienie w rzeczywistości spowolni jego witrynę i nie dostarczy żadnych danych, na podstawie których można działać. Chodzi o przedłożenie długoterminowej stabilności systemu nad krótkotrwały zastrzyk dopaminy z nowego wydania.

To podejście nie zawsze jest popularne w zarządzie, ale to jedyny sposób na budowanie wydajnego oprogramowania, które się skaluje. Gdy przestaje się nagradzać wolumen, zaczyna się dostrzegać błyskotliwość inżynierów, którzy znajdują niskokodowe skróty utrzymujące system w dobrej formie, a biznes – w zwinności.

Najważniejsze wnioski

• Kod jest obciążeniem: każda dodana linia kodu to trwały wzrost kosztów utrzymania i ryzyka.
• Liczą się rezultaty: sukces inżynierii warto mierzyć złożonością usuniętą z systemu, a nie dodanymi funkcjami.
• Test gumki: zanim zaproponuje się budowę czegoś nowego, zawsze należy zapytać, czy problemu nie da się rozwiązać, usuwając coś.
• AI jako konsultant: LLM warto wykorzystywać do znajdowania błędów w logice i architekturze, a nie tylko do generowania powtarzalnego kodu.

---

Najczęściej zadawane pytania

Czy pisanie mniejszej ilości kodu nie szkodzi mojej karierze inżyniera?

Nie, jest wręcz przeciwnie. O rolach na poziomie Senior i Staff decydują projektowanie systemów i podejmowanie decyzji, a nie szybkość pisania. Wykazanie, że dzięki zaproponowaniu prostszej alternatywy firma zaoszczędziła pół roku utrzymania, jest znacznie mocniejszym sygnałem w karierze niż wdrożenie dziesięciu przeciętnych funkcji.

Jak odpierać naciski interesariuszy, którzy chcą więcej funkcji?

Argumentację warto oprzeć na kosztach i ryzyku. Należy wyjaśnić, że każda nowa funkcja zwiększa powierzchnię podatną na błędy i spowalnia przyszły rozwój. Zanim na stos trafią kolejne funkcje, warto pokazać na danych, w jakim stopniu istniejące funkcje są niedostatecznie wykorzystywane.

Czy to oznacza, że nigdy nie należy budować oprogramowania na zamówienie?

Wcale nie. Oprogramowanie na zamówienie służy unikalnej propozycji wartości – temu, co wyróżnia firmę. Jeśli narzędzie zewnętrzne lub natywna funkcja platformy wykona zadanie w 80% równie dobrze, warto z nich skorzystać. Własny kod należy zachować dla tych 20%, które faktycznie budują przewagę konkurencyjną.

Najcenniejszą umiejętnością we współczesnej inżynierii nie jest wiedza, jak budować, lecz wiedza, co warto zbudować.

Następny krok

Ten artykuł przedstawia filozofię inżynierską DataTip. Porozmawiaj z DataTip.