Röviden: A cikk amellett érvel, hogy a kódot addig tehernek kell tekinteni, amíg egyértelműen meg nem old egy szükséges üzleti problémát. A gondolkodással kezdő mérnöki munka az egyedi szoftver építése előtt megvizsgálja az egyszerűbb alternatívákat – például funkciók eltávolítását, folyamatok módosítását vagy natív eszközök használatát. A csapatoknak az eredmények és a megszüntetett komplexitás alapján kell mérniük a sikert, az AI-t pedig az architektúra megkérdőjelezésére és a kockázatok feltárására kell használniuk, nem csupán több kód generálására.
- Minden hozzáadott kódsor folyamatos karbantartási, tesztelési, biztonsági, dokumentációs és migrációs költséget teremt.
- A Shopify-példában egy tervezett egyedi hűségprogram-motort vállalati integráció és Liquid-snippetek váltottak fel, így elmaradt több mint 5000 sor Ruby-kód, a költségek és a karbantartási igény pedig csökkentek.
- A Radírteszt azt kérdezi, hogy egy funkció eltávolítása vagy egy felület egyszerűsítése megoldhatja-e a problémát, mielőtt új kódot javasolnánk.
- Az RFC-Lite megköveteli, hogy a mérnökök egyetlen oldalon, világosan elmagyarázzák a javasolt megoldást és annak kompromisszumait.
- Az AI itt validálási és architektúra-stressztesztelési eszközként jelenik meg, nem csupán kódgeneráló asszisztensként.
Minden kódsorból később olyasmi lesz, amit meg kell érteni, tesztelni, biztonságossá tenni, migrálni és elmagyarázni. A gondolkodással kezdő mérnöki munka nem lassabb – megakadályozza, hogy gyorsabban építsük fel a rossz terhet.
Nemrég egy nagy forgalmú Shopify-kereskedővel dolgoztunk, aki meg volt győződve arról, hogy egyedileg fejlesztett hűségprogram-motorra van szüksége összetett Tier-1 ügyféllogikájának kezeléséhez. Belső csapatuk már elkészített egy 40 oldalas műszaki követelménydokumentumot egy egyedi privát alkalmazáshoz. Háromnapos architektúra-felülvizsgálat után az egész tervet elvetettük, és egy meglévő vállalati eszközzel headless integrációt valósítottunk meg, néhány stratégiai Liquid-snippettel kiegészítve.
Azzal, hogy nem írtunk meg több mint 5000 sor egyedi Ruby-kódot, 50 000 € kezdeti fejlesztési költséget spóroltunk meg nekik, és megszüntettünk havonta nagyjából 15 óra karbantartási terhet. A kereskedőnek nem több kódra volt szüksége, hanem megoldásra. Ez a gondolkodással kezdő mérnöki munka lényege: felismerni, hogy a kód nem vagyon, hanem teher, amelyet indokolni kell.
A „szállítási sebesség” téveszméjének magas ára
Sok technológiai vezető jelenleg abban a csapdában ragadt, hogy a produktivitást a lezárt JIRA-jegyek vagy a feltöltött GitHub-commitok számával méri. Ez veszélyes mérőszám, mert a problémák megoldása helyett artefaktumok létrehozására ösztönöz. Egy modern stackben minden új funkció növeli a biztonsági sérülékenységek, a teljesítményromlás és a technikai adósság felületét.
Amikor egy csapat büszke arra, hogy gondolkodás nélkül, gyorsan szállít, lényegében egy szakadék felé gyorsít. Egy 20 fős mérnöki csapat könnyen elköltheti sprintciklusai 40%-át pusztán olyan korábbi funkciók mellékhatásainak kezelésére, amelyeket soha nem kellett volna megépíteni. Ezt leggyakrabban az e-kereskedelemben látjuk, ahol egy pénztári szélsőséges esetre adott „gyors javítás” hat hónappal később az egész analitikai csomag adatfolyamát tönkreteszi.
A kód tesztelést, dokumentációt és szellemi energiát igényel minden új munkatárstól, aki csatlakozik a csapatához. Ha egy problémát üzleti folyamat módosításával vagy natív platformfunkció használatával meg tud oldani, nyert. A legelegánsabb megoldás az, amely nulla sor karbantartást igényel.
Gondolkodással kezdve: az ügyészi megközelítés a követelményekhez
A DATATIP-nél minden új funkcióigényt úgy kezelünk, mintha bíróság előtt állna. Mielőtt megnyitnánk egy IDE-t, a vád szerepét töltjük be, és keresztkérdésekkel vizsgáljuk a kód szükségességét. Ez nem bürokratikus lassítás, hanem taktikai súrlódás, amelynek célja az architektúra felduzzadásának megakadályozása.
Egy egyszerű keretrendszerrel ellenőrizzük, hogy szükség van-e fejlesztésre. Először alkalmazzuk a Radírtesztet: megoldható-e a probléma egy funkció eltávolításával vagy a felhasználói felület egyszerűsítésével? Egy lassú pénztár gyakran nem adatbázis-probléma, hanem „túl sok űrlapmező” probléma. Másodszor megkövetelünk egy RFC-Lite-ot (Request for Comments). Ha egy mérnök nem tudja egyszerű nyelven, egyetlen oldalon elmagyarázni a logikát és a kompromisszumokat, akkor még nem áll készen a kód megírására.
„A kódgenerálás költsége az AI-nak köszönhetően szinte nullára esett, de a kód karbantartásának költsége ugyanolyan magas, mint valaha. Ha az AI-t arra használja, hogy gyorsabban írjon több kódot, egyszerűen magasabb kamatra halmoz fel adósságot.”
Az AI validálásra, nem csak generálásra
Az LLM-ek és az olyan eszközök térnyerésével, mint a Cursor, eltűnt a kódszállítás belépési korlátja. Ez középszerű, AI által generált PR-ok áradatához vezetett, amelyek az azonnali tüneteket kezelik, miközben figyelmen kívül hagyják a rendszer egészségét. Úgy gondoljuk, hogy 2024-ben az AI valódi értéke a logika stressztesztelése, nem pedig a szintaxis generálása.
Ahelyett, hogy arra kérnénk az AI-t, hogy „építsen egy egyedi middleware-t”, arra használjuk, hogy szélsőséges eseteket találjon az architektúra-terveinkben. Megkérjük, szimulálja, hogyan hibásodhat meg egy új adatséma tízszeres terhelés alatt, vagy javasoljon három módot egy üzleti cél elérésére kizárólag natív Shopify API-k használatával. Ez a mérnök szerepét építőből kurátorrá és kockázatkezelővé alakítja. Ön a pilóta; az AI a hajtómű. Egy gyorsabb hajtóművel csak hamarabb téved el, ha nem térképezte fel az úti célt.
A kompromisszum: radikális őszinteség kontra funkcióigények
Ennek a szemléletnek az elfogadása olyan kulturális váltást igényel, amelyben a „nem” érvényes és tiszteletben tartott mérnöki eredmény. Azt jelenti, hogy közöljük egy érintettel: az általa kért egyedi dashboard valójában lelassítja az oldalát, és nem ad semmilyen cselekvésre alkalmas adatot. Arról szól, hogy a rendszer hosszú távú stabilitását előnyben részesítjük egy új kiadás rövid távú dopaminlöketével szemben.
Ez a megközelítés nem mindig népszerű a tárgyalóteremben, de ez az egyetlen módja annak, hogy nagy teljesítményű, skálázható szoftvert építsünk. Amikor abbahagyja a mennyiség jutalmazását, elkezdi észrevenni azoknak a mérnököknek a zsenialitását, akik megtalálják azokat a low-code rövidítéseket, amelyek karcsún tartják a rendszert és agilisan az üzletet.
A legfontosabb tanulságok
- A kód teher: Minden hozzáadott kódsor tartósan növeli a karbantartási költséget és a kockázatot.
- Az eredmények az elsők: A mérnöki sikert a rendszerből eltávolított komplexitással mérje, ne a hozzáadott funkciókkal.
- A Radírteszt: Mielőtt valami új építését javasolná, mindig kérdezze meg, megoldható-e a probléma valaminek a törlésével.
- Az AI mint tanácsadó: Az LLM-eket arra használja, hogy hibákat találjanak a logikájában és az architektúrájában, ne csak boilerplate kódot generáljanak.
Gyakran ismételt kérdések
Nem árt a mérnöki karrieremnek, ha kevesebb kódot írok?
Nem, éppen ellenkezőleg. A senior és staff szintű szerepköröket a rendszertervezés és a döntéshozatal határozza meg, nem a gépelési sebesség. Ha bizonyítani tudja, hogy egy egyszerűbb alternatíva javaslatával hat hónapnyi karbantartást spórolt meg egy cégnek, az sokkal erősebb karrierjelzés, mint tíz középszerű funkció leszállítása.
Hogyan mondjak nemet azoknak az érintetteknek, akik több funkciót szeretnének?
Érveit a költségek és a kockázatok nyelvén fogalmazza meg. Magyarázza el, hogy minden új funkció növeli a hibák felületét és lassítja a jövőbeli fejlesztést. Adatokkal mutassa meg, mennyire kihasználatlanok a meglévő funkciók, mielőtt újabbakat tennének a halomra.
Ez azt jelenti, hogy soha ne építsünk egyedi szoftvert?
Egyáltalán nem. Az egyedi szoftver az Ön egyedi értékajánlatához való – azokhoz a dolgokhoz, amelyek megkülönböztetik a vállalkozását. Ha egy külső eszköz vagy egy natív platformfunkció 80%-os hatékonysággal el tudja végezni a feladatot, használja azt. Az egyedi kódot tartogassa arra a 20%-ra, amely valóban a versenyelőnyét hajtja.
A modern mérnöki munka legértékesebb készsége nem az, hogy tudjuk, hogyan kell építeni, hanem az, hogy tudjuk, mit érdemes megépíteni.
Következő lépés
Használja ezt a DataTip mérnöki filozófiájáról szóló cikkként. Beszéljen a DataTippel.