A kódsorok visszatértek (és rosszabb, mint korábban)

A kódsorok visszatértek termelékenységi mutatóként, és a szoftvercsapatoknak mindenhol meg kell ijedniük. Amit egykor a mérnöki teljesítmény veszélyesen félrevezető mércéjének minősítettek, az csendben visszakerült a tárgyalótermekbe, a teljesítményértékelésekbe és a mesterséges intelligencia által generált irányítópultokba – és ezúttal sokkal súlyosabbak a következmények az Ön vállalkozására nézve.

Miért váltak a kódsorok valaha is termelékenységi mutatóvá?

A kódsorok (LOC) megszállottsága az 1960-as és 1970-es évekre nyúlik vissza, amikor a szoftver még új volt, a menedzserek még mindig össze voltak zavarodva, és valamit – bármit – számolni jobb érzés volt, mint a semmit sem számolni. Ha egy fejlesztő több sort ír, akkor biztosan több munkát végez, igaz?

A logika mindig hibás volt. Bill Gates híresen figyelmeztetett arra, hogy a szoftver termelékenységének kódsorokkal történő mérése olyan, mint a repülőgépgyártás tömegének mérése. Egy kétszer nehezebb repülőgép nem kétszer olyan jó. A kód sem kétszer olyan hosszú.

Az 1990-es évekre és a 2000-es évek elejére az ipar nagyrészt tovább fejlődött. Az agilis módszerek, az eredményalapú mérés és a technikai adósság egyre növekvő ismerete a rossz ötletek szemétgyűjtőjébe taszította a LOC-t. A mérnökök ünnepeltek. A termékmenedzserek alkalmazkodtak. A vállalkozások elkezdték mérni, hogy mi számít valójában: a szolgáltatások kiszállítása, a hibák kijavítása, a felhasználói eredmények elérése.

Mi hajtja a kódmegszállottság visszatérését?

Két erő összeesküdt ennek a zombi-metrikának a feltámasztására: AI kódgeneráló eszközök és végrehajtói nyomás a látható termelékenység bizonyítására.

Miközben a GitHub Copilot, Cursor és hasonló eszközök elárasztották a piacot, a vállalatok tülekedtek, hogy igazolják mesterségesintelligencia-befektetéseiket. A ROI kimutatásának legegyszerűbb módja? Számolja meg az eszközök által előállított kódsorokat. Hirtelen a mérnöki csapatok sorok ezreit generálták naponta – és a vezetők ezt a számot kiemelt teljesítményként kezdték kezelni.

Eközben a távmunka és az elosztott csapatok új szorongást keltettek a vezetőkben, akik nem látták, hogy a fejlesztők fizikailag gépelnek. Megnőtt a kereslet a számszerűsíthető kimeneti mérőszámok iránt. A LOC a láthatóság illúzióját kínálta. Objektívnek érezte. Mérhetőnek érezte. Biztonságban érezte magát.

Ez nem tartozik ezek közé.

Miért rosszabb a visszatérés, mint az eredeti probléma?

Amikor az emberi fejlesztők túl sok kódot írtak, hogy felfújják LOC-számaikat, a kárt az emberi sebesség korlátozta. Egy fejlesztő csak ilyen gyorsan tud gépelni, annyi redundáns funkciót kitalálni, vagy annyi megjegyzésblokkot betömni egy munkanap alatt.

Az AI mindent megváltoztat. Egyetlen fejlesztő mesterséges intelligencia asszisztenssel most több tízezer sort generálhat órák alatt. Ha teljesítményértékelésük a mennyiséget jutalmazza, minden ösztönzésük megvan arra, hogy szabadon engedjék a mesterséges intelligenciát – bőbeszédű, dagadt, karbantarthatatlan kódot állítsanak elő, amely lenyűgözően néz ki egy táblázatban, és katasztrofális a termelésben.

"A legveszélyesebb mérőszám az, amelyet könnyű játszani. Ha a jutalom kódsorok, az eredmény nem nagyobb termelékenység, hanem több kód. Ezek nagyon különböző dolgok."

A downstream hatások súlyosak és összetettek. A felduzzadt kódbázisokat nehezebb hibakeresni, lassabb a telepítés, drágább a karbantartása, és sokkal sebezhetőbb a biztonsági kizsákmányolásokkal szemben. A felesleges kód minden sora egy jövőbeli kötelezettség, amely a mérlegben ül, és láthatatlan, amíg valami kritikus dolgot meg nem tör.

Mit kell inkább mérni a modern vállalkozásoknak?

A jó hír az, hogy léteznek jobb alternatívák, amelyeket a nagy teljesítményű mérnöki szervezetek már teszteltek. Ha vállalkozása jelenleg bármilyen minőségben nyomon követi a LOC-t, azonnal cserélje ki olyan mutatókra, amelyek ténylegesen korrelálnak az üzleti eredményekkel:

Üzembe helyezés gyakorisága: Milyen gyakran szállít a csapata működő szoftvert a termelésbe? A nagy teljesítményű csapatok naponta többször telepítik, nem negyedévente.

A változtatások átfutási ideje: Mennyi idő telik el a végleges kódmódosítástól az éles verzióban történő futtatásig? A rövidebb jobb – ez azt jelenti, hogy a folyamat karcsú és érzékeny.

Módosítási hibaarány: A telepítések hány százaléka okoz incidenciát

Frequently Asked Questions

Are lines of code ever a useful measurement for anything?

LOC has limited use in very specific contexts, such as estimating the rough scope of a legacy codebase for migration planning, or calculating software complexity using derived metrics like cyclomatic complexity. However, it should never be used as a productivity metric or a measure of individual developer performance. In those contexts, it actively incentivizes bad outcomes.

How do AI coding tools change the lines of code problem?

AI coding assistants dramatically accelerate the generation of code, which means the volume problem scales exponentially when LOC is treated as a success metric. Teams using AI tools with LOC-based incentives will produce massive, bloated codebases far faster than pre-AI teams could. The solution is to pair AI tools with outcome-based metrics so the speed of generation is matched by a corresponding focus on quality and usefulness.

What's the fastest way for a business to shift away from vanity metrics?

The fastest path is to consolidate your operational tools onto a platform that tracks outcomes by design rather than bolting reporting onto existing workflow tools. When your business OS connects team activity to business results in real time, the right metrics surface naturally and vanity metrics lose their appeal because better information is always available.

Your business deserves metrics that tell the truth. Stop counting lines of code and start measuring outcomes that actually drive growth. Explore Mewayz at app.mewayz.com and see how 138,000 businesses have built smarter operations — starting at just $19 per month.

Related Posts

• 23 éves a NetNewsWire
• gRPC: A szolgáltatás meghatározásától a vezetékes formátumig
• A Telnet halálának napja
• Barátság fenntartása