Zrátané a podčiarknuté: Článok tvrdí, že kód by sa mal považovať za záväzok, kým jednoznačne nerieši nevyhnutný obchodný problém. Inžinierstvo založené na premýšľaní najprv overuje jednoduchšie alternatívy – ako odstránenie funkcií, zmenu procesov alebo využitie natívnych nástrojov – predtým, než sa pustí do budovania vlastného softvéru. Tímy by mali merať úspech podľa výsledkov a odstránenej komplexnosti, pričom AI by mali používať na spochybňovanie architektúry a odhaľovanie rizík, nie len na generovanie ďalšieho kódu.
- Každý pridaný riadok kódu vytvára priebežné náklady na údržbu, testovanie, bezpečnosť, dokumentáciu a migráciu.
- Príklad Shopify nahradil plánovaný vlastný vernostný engine integráciou s podnikovým nástrojom a Liquid snippetmi, čím sa vyhli 5 000+ riadkom Ruby a znížili náklady a údržbu.
- Eraser Test (test gumovaním) sa pýta, či odstránenie funkcie alebo zjednodušenie rozhrania môže vyriešiť problém skôr, ako sa navrhne nový kód.
- RFC-Lite vyžaduje, aby inžinieri na jednej strane jasne vysvetlili navrhované riešenie a jeho kompromisy.
- AI je prezentovaná ako nástroj na validáciu a záťažové testovanie architektúry, nie len ako asistent na generovanie kódu.
Každý riadok kódu sa stáva niečím, čo treba pochopiť, otestovať, zabezpečiť, migrovať a neskôr vysvetliť. Inžinierstvo založené na premýšľaní nie je pomalšie; zabraňuje tomu, aby ste si rýchlejšie postavili nesprávny záväzok.
Nedávno sme spolupracovali s veľkoobjemovým obchodníkom na Shopify, ktorý bol presvedčený, že potrebujú vlastný vernostný engine na zvládnutie komplexnej logiky pre zákazníkov Tier-1. Ich interný tím už vypracoval 40-stranový dokument s technickými požiadavkami na vlastnú súkromnú aplikáciu. Po troch dňoch architektonického prehodnotenia sme celý plán zrušili a implementovali headless integráciu s existujúcim podnikovým nástrojom v kombinácii s niekoľkými strategickými Liquid snippetmi.
Tým, že sme odmietli napísať 5 000+ riadkov vlastného Ruby, ušetrili sme im 50 000 € na počiatočných vývojových nákladoch a odstránili približne 15 hodín mesačnej réžie na údržbu. Obchodník nepotreboval viac kódu; potreboval riešenie. Toto je podstata inžinierstva založeného na premýšľaní: uvedomenie si, že kód nie je aktívum, ale záväzok, ktorý musí byť ospravedlnený.
Vysoká cena ilúzie „rýchlosti doručenia“
Mnohí technickí lídri sú v súčasnosti uväznení v cykle merania produktivity prostredníctvom uzavretých JIRA ticketov alebo pushov na GitHub. Toto je nebezpečná metrika, pretože motivuje k vytváraniu artefaktov namiesto riešenia problémov. V modernom stacku každá nová funkcia zvyšuje plochu pre bezpečnostné zraniteľnosti, výkonnostné regresie a technický dlh.
Keď je tím hrdý na to, že dodáva rýchlo bez predchádzajúceho premýšľania, v podstate sa rúti k útesu. Dvadsaťčlenný inžiniersky tím môže ľahko stráviť 40 % svojich sprint cyklov len riadením vedľajších účinkov predchádzajúcich funkcií, ktoré by nikdy nemali byť postavené. Najčastejšie to vidíme v e-commerce, kde „rýchla oprava“ okrajového prípadu pri pokladni o šesť mesiacov neskôr rozbije dátový pipeline pre celý analytický balík.
Kód vyžaduje testovanie, dokumentáciu a mentálnu energiu od každého nového člena tímu. Ak dokážete vyriešiť problém zmenou obchodného procesu alebo použitím natívnej platformovej funkcie, vyhrali ste. Najelegantnejšie riešenie je to, ktoré vyžaduje nula riadkov údržby.
Premýšľanie na prvom mieste: Prokurátorský prístup k požiadavkám
V DATATIP pristupujeme ku každej novej požiadavke na funkciu, ako keby bola na súde. Skôr než otvoríme IDE, vystupujeme ako prokuratúra a krížovo skúmame nevyhnutnosť kódu. Nejde o byrokratické spomaľovanie; ide o taktické trenie navrhnuté na prevenciu architektonického nafukovania.
Používame jednoduchý rámec na overenie, či je build potrebný. Po prvé, aplikujeme Eraser Test: Môžeme tento problém vyriešiť odstránením funkcie alebo zjednodušením UI? Často pomalá pokladňa nie je problém databázy; je to problém „príliš veľa polí vo formulári“. Po druhé, vyžadujeme RFC-Lite (Request for Comments). Ak inžinier nedokáže vysvetliť logiku a kompromisy v jednoduchej angličtine na jednej strane, nie je pripravený písať kód.
„Náklady na generovanie kódu klesli vďaka AI takmer na nulu, ale náklady na údržbu tohto kódu zostávajú rovnako vysoké ako kedykoľvek predtým. Ak používate AI na písanie viac kódu rýchlejšie, jednoducho akumulujete dlh s vyššou úrokovou sadzbou.“
Používanie AI na validáciu, nielen na generovanie
S nástupom LLM a nástrojov ako Cursor zmizla bariéra vstupu pre odosielanie kódu. To viedlo k záplave priemerných, AI-generovaných PR, ktoré riešia okamžité symptómy, ale ignorujú systémové zdravie. Veríme, že skutočná hodnota AI v roku 2024 spočíva v testovaní logiky pod tlakom, nie v generovaní syntaxe.
Namiesto toho, aby sme AI požiadali o „vytvorenie vlastného middlewaru,“ používame ju na hľadanie okrajových prípadov v našich architektonických plánoch. Požiadame ju, aby simulovala, ako by nová dátová schéma mohla zlyhať pri 10-násobnej záťaži, alebo aby navrhla tri spôsoby, ako dosiahnuť obchodný cieľ len pomocou natívnych Shopify API. To posúva úlohu inžiniera z staviteľa na kurátora a manažéra rizík. Vy ste pilot; AI je motor. Rýchlejší motor vás len rýchlejšie stratí, ak ste si nezmapovali cieľ.
Kompromis: Radikálna úprimnosť vs. požiadavky na funkcie
Prijatie tohto myslenia si vyžaduje kultúrny posun, kde „Nie“ je platný a rešpektovaný inžiniersky výstup. Znamená to povedať stakeholderovi, že vlastný dashboard, ktorý chcú, v skutočnosti spomalí ich stránku a neposkytne žiadne použiteľné údaje. Ide o uprednostnenie dlhodobej stability systému pred krátkodobým dopamínovým hitom novej verzie.
Tento prístup nie je vždy vítaný v zasadacej miestnosti, ale je to jediný spôsob, ako vybudovať vysokovýkonný softvér, ktorý škáluje. Keď prestanete odmeňovať objem, začnete vidieť genialitu inžinierov, ktorí nachádzajú nízkokódové skratky, ktoré udržujú systém štíhly a podnik agilný.
Kľúčové poznatky
- Kód je záväzok: Každý riadok kódu pridaný natrvalo zvyšuje náklady na údržbu a riziko.
- Uprednostňujte výsledky: Merajte úspech inžinierov podľa zložitosti odstránenej zo systému, nie podľa pridaných funkcií.
- Test gumou: Vždy sa pýtajte, či sa problém dá vyriešiť odstránením niečoho, skôr ako navrhnete vytvoriť niečo nové.
- AI ako konzultant: Používajte LLM na hľadanie chýb vo vašej logike a architektúre namiesto len generovania šablónového kódu.
Často kladené otázky
Nie je písanie menšieho množstva kódu škodlivé pre môj kariérny rast ako inžiniera?
Nie, opak je pravdou. Pozície na úrovni senior a staff sú definované návrhom systémov a rozhodovaním, nie rýchlosťou písania. Preukázať, že ste spoločnosti ušetrili šesť mesiacov údržby navrhnutím jednoduchšej alternatívy, je oveľa silnejším kariérnym signálom ako dodanie desiatich priemerných funkcií.
Ako môžem argumentovať voči zainteresovaným stranám, ktoré chcú viac funkcií?
Rámcujte svoj argument z hľadiska nákladov a rizika. Vysvetlite, že každá nová funkcia zvyšuje plochu pre chyby a spomaľuje budúci vývoj. Použite dáta na preukázanie, že existujúce funkcie sú nedostatočne využívané, skôr než pridáte nové na kopu.
Znamená to, že by sme nikdy nemali vytvárať vlastný softvér?
Vôbec nie. Vlastný softvér je pre vašu jedinečnú hodnotovú ponuku – veci, ktoré robia váš biznis odlišným. Ak nástroj tretej strany alebo natívna funkcia platformy dokáže urobiť prácu na 80 % rovnako dobre, použite ho. Ušetrite svoj vlastný kód na tých 20 %, ktoré skutočne poháňajú vašu konkurenčnú výhodu.
Najcennejšou zručnosťou v modernom inžinierstve nie je vedieť, ako stavať; je to vedieť, čo sa oplatí stavať.
Ďalší krok
Použite toto ako článok o inžinierskej filozofii DataTip. Porozprávajte sa s DataTip.