Každý řádek kódu se stává něčím, čemu je později třeba rozumět, co je třeba testovat, zabezpečit, migrovat a vysvětlovat. Inženýrství založené na promyšlení není pomalejší; brání tomu, abyste rychleji vybudovali špatný závazek.

Nedávno jsme spolupracovali s Shopify obchodníkem s vysokým objemem prodejů, který byl přesvědčen, že pro složitou logiku svých Tier-1 zákazníků potřebuje věrnostní engine vyvinutý na míru. Jeho interní tým už připravil 40stránkový dokument technických požadavků na zakázkovou privátní aplikaci. Po třech dnech architektonické revize jsme celý plán zrušili a implementovali headless integraci s existujícím enterprise nástrojem, doplněnou o několik strategických Liquid snippetů.

Tím, že jsme odmítli napsat více než 5 000 řádků Ruby na míru, jsme mu ušetřili 50 000 € na počátečních nákladech na vývoj a odstranili zhruba 15 hodin měsíční režie na údržbu. Obchodník nepotřeboval více kódu; potřeboval řešení. To je podstata inženýrství založeného na promyšlení: uvědomit si, že kód není aktivum, ale závazek, který musí být obhájen.

Vysoká cena iluze „rychlosti dodávek“

Mnoho technických lídrů je dnes chyceno v cyklu, kdy produktivitu měří počtem uzavřených ticketů v JIRA nebo odeslaných commitů na GitHub. Je to nebezpečná metrika, protože motivuje k vytváření artefaktů místo řešení problémů. V moderním stacku každá nová funkce zvětšuje plochu pro bezpečnostní zranitelnosti, výkonnostní regrese a technický dluh.

Když je tým hrdý na rychlé dodávky bez předchozího promyšlení, v podstatě zrychluje směrem k útesu. Dvacetičlenný inženýrský tým může snadno strávit 40 % svých sprintů jen řešením vedlejších účinků dřívějších funkcí, které nikdy neměly vzniknout. Nejčastěji to vidíme v e-commerce, kde „rychlá oprava“ okrajového případu v checkoutu o šest měsíců později rozbije datovou pipeline celé analytické sady.

Kód vyžaduje testování, dokumentaci a mentální energii každého nového člena, který do vašeho týmu nastoupí. Pokud dokážete problém vyřešit změnou obchodního procesu nebo využitím nativní funkce platformy, vyhráli jste. Nejelegantnější řešení je to, které vyžaduje nula řádků údržby.

Nejdřív přemýšlet: přístup žalobce k požadavkům

V DATATIP zacházíme s každým požadavkem na novou funkci, jako by stál před soudem. Než otevřeme IDE, vystupujeme v roli žalobce a podrobujeme nutnost kódu křížovému výslechu. Nejde o byrokratické zpomalování; jde o taktické tření, jehož cílem je zabránit architektonickému bobtnání.

K ověření, zda je vývoj nutný, používáme jednoduchý rámec. Nejprve aplikujeme test gumy: Dokážeme tento problém vyřešit odstraněním funkce nebo zjednodušením UI? Pomalý checkout často není problém databáze; je to problém „příliš mnoha polí ve formuláři“. Za druhé vyžadujeme RFC-Lite (Request for Comments). Pokud inženýr nedokáže vysvětlit logiku a kompromisy srozumitelnou řečí na jedné stránce, není připraven psát kód.

„Náklady na generování kódu díky AI klesly téměř na nulu, ale náklady na údržbu tohoto kódu zůstávají stejně vysoké jako vždy. Pokud AI používáte k tomu, abyste psali více kódu rychleji, jen hromadíte dluh s vyšší úrokovou sazbou.“

AI pro validaci, nejen pro generování

S nástupem LLM a nástrojů jako Cursor zmizela bariéra vstupu pro dodávání kódu. To vedlo k záplavě průměrných PR generovaných AI, které řeší okamžité symptomy a ignorují zdraví systému jako celku. Věříme, že skutečná hodnota AI v roce 2024 spočívá v zátěžovém testování logiky, nikoli v generování syntaxe.

Místo abychom AI žádali „postav vlastní middleware“, používáme ji k hledání okrajových případů v našich architektonických plánech. Žádáme ji, aby simulovala, jak by nové datové schéma mohlo selhat při desetinásobné zátěži, nebo aby navrhla tři způsoby, jak dosáhnout obchodního cíle pouze s nativními Shopify API. Role inženýra se tak posouvá od stavitele ke kurátorovi a manažerovi rizik. Vy jste pilot; AI je motor. Rychlejší motor vás jen rychleji zavede do neznáma, pokud nemáte zmapovaný cíl.

Kompromis: radikální upřímnost vs. požadavky na funkce

Přijetí tohoto myšlení vyžaduje kulturní posun, v němž je „Ne“ platným a respektovaným inženýrským výstupem. Znamená to říct stakeholderovi, že dashboard na míru, který chce, ve skutečnosti zpomalí jeho web a nepřinese žádná použitelná data. Jde o to upřednostnit dlouhodobou stabilitu systému před krátkodobou dávkou dopaminu z nového vydání.

V zasedačkách tento přístup není vždy populární, ale je to jediný způsob, jak vytvářet vysoce výkonný software, který škáluje. Když přestanete odměňovat objem, začnete vidět brilantnost inženýrů, kteří nacházejí low-code zkratky udržující systém štíhlý a byznys agilní.

Klíčové poznatky

• Kód je závazek: Každý přidaný řádek kódu trvale zvyšuje náklady na údržbu i riziko.
• Upřednostněte výsledky: Měřte úspěch inženýrství složitostí odstraněnou ze systému, ne přidanými funkcemi.
• Test gumy: Než navrhnete stavět něco nového, vždy se zeptejte, zda lze problém vyřešit tím, že něco odstraníte.
• AI jako konzultant: Používejte LLM k hledání chyb ve své logice a architektuře, ne jen ke generování boilerplate kódu.

---

Často kladené otázky

Není psaní menšího množství kódu špatné pro můj kariérní růst jako inženýra?

Není, platí opak. Role na úrovni Senior a Staff definuje návrh systémů a rozhodování, ne rychlost psaní. Doložit, že jste firmě ušetřili šest měsíců údržby návrhem jednodušší alternativy, je mnohem silnější kariérní signál než dodat deset průměrných funkcí.

Jak se ohradit vůči stakeholderům, kteří chtějí další funkce?

Formulujte své argumenty v pojmech nákladů a rizika. Vysvětlete, že každá nová funkce zvětšuje prostor pro chyby a zpomaluje budoucí vývoj. Než na hromadu přidáte další funkce, ukažte na datech, jak málo se využívají ty stávající.

Znamená to, že bychom nikdy neměli vyvíjet software na míru?

Vůbec ne. Software na míru je určen pro vaši jedinečnou hodnotovou nabídku—pro věci, které odlišují vaše podnikání. Pokud externí nástroj nebo nativní funkce platformy zvládne práci z 80 % stejně dobře, použijte je. Svůj vlastní kód si nechte pro těch 20 %, které skutečně vytvářejí vaši konkurenční výhodu.

Nejcennější dovedností v moderním inženýrství není vědět, jak stavět; je to vědět, co stojí za to postavit.

Další krok

Využijte tento článek jako ukázku inženýrské filozofie DataTip. Kontaktujte DataTip.