6 Minuty
Linus Torvalds, tvůrce Linuxu, ostře zkritizoval údajnou výkonnostní a náborovou metriku, kterou měl údajně používat Elon Musk — počítání řádků kódu. V rozhovoru pro kanál Linus Tech Tips na YouTube Torvalds myšlenku nejen odmítl jako zavádějící, ale označil ji za přímo „nekompetentní“. Jeho komentáře znovu rozpoutaly debatu mezi vývojářskou komunitou o tom, co skutečně odráží dovednosti a produktivitu při tvorbě softwaru.
Proč je počítání řádků kódu nebezpečnou zkratkou
Během rozhovoru moderátor zmínil staré programátorské měřítko: celkový počet řádků kódu (LOC, lines of code). Podle veřejně dostupných zpráv se po převzetí Twitteru (dnes X) objevily informace, že inženýři byli vyzváni, aby si vytiskli své zdrojové soubory — a ti s menším počtem vytištěných řádků byli údajně v ohrožení vyhazovu. Torvalds nebral jehly za zuby; použití počtu řádků k hodnocení inženýrů označil za „čistou nekompetenci“ a doplnil, že „kdokoli, kdo takto uvažuje, je příliš blbý na to, aby pracoval v technologické firmě.“
Tento ostrý výrok zasáhl citlivé místo. Základní problém je jednoduchý: množství není totéž co kvalita. Měření produktivity podle toho, kolik řádků někdo napíše, povzbuzuje nadbytečnost, křehké konstrukce a zbytečnou složitost. Dobře navržený software často dokáže více s menším počtem řádků — a úspornost kódu je známkou řemeslného zpracování, nikoli lenosti. Takové měření navíc přehlíží kontext: refaktoring, abstrakce nebo použití deklarativních jazyků mohou výrazně snížit počet řádků a současně zlepšit čitelnost a údržbu.
Reakce vývojářů: téměř jednotné povzdechnutí
Na Reddittu a v dalších diskusních fórech mezi programátory převládla podpora Torvaldova stanoviska. Komentáře se pohybovaly od sarkastického po rozčílený: „I student prvního ročníku informatiky ví, že počítat řádky kódu je nejhloupější metrika.“ Komunita argumentovala, že takové pravidlo motivuje k nafouklým řešením a generuje více chyb — přesně opačný výsledek, jaký firmy potřebují při škálování produktů nebo stabilizaci platformy.
Příklady, které to dokreslují
- Jeden stručný algoritmus o 100 řádcích může překonat záplatu o 1 000 řádcích, která duplicitně opakuje logiku a skrývá záměr.
- Refaktoring často snižuje počet řádků, přitom zvyšuje srozumitelnost a udržovatelnost — penalizoval by přísný LOC režim takové zlepšení?
- Automatické formátování, rozšířené logování nebo generovaný kód mohou nafouknout počet řádků, aniž by zlepšily funkcionalitu či návrh.
Představte si, že byste odměňovali spisovatele podle délky jejich eseje místo podle jasnosti argumentu. Stejná chybná logika platí, když odměňujete programátory za objem místo za řemeslné provedení. Důsledkem je nejen horší kvalita softwaru, ale i rostoucí technický dluh, který dlouhodobě zpomaluje vývoj. Firmy tak mohou dopadnout v situaci, kdy mají „hodně kódu“, ale slabou architekturu, nízkou testovatelnost a obtížně rozšiřitelný produkt.
Navíc takové metriky podkopávají správné motivace v týmu: místo aby se vývojáři soustředili na systémové vlastnosti jako vysokou dostupnost, jednoduchost rozhraní nebo rychlou odezvu, zaměřují se na kvantitu. Metriky by měly vést žádoucí chování; LOC tuto roli neplní. Například v moderních vývojových prostředích s mikroservisy, serverless funkcemi nebo vysokou mírou závislostí je klíčové hodnotit, jak kód interaguje s ostatními částmi systému, nikoli kolik má linek.
Co by firmy měly měřit místo toho
Pokud tedy ne řádky kódu, co by manažeři měli sledovat? Kvalitativní a kvantitativní metriky, které mají smysl z hlediska udržitelnosti a byznysové hodnoty. Mezi užitečné ukazatele patří zpětná vazba z code review, míra vyskytujících se chyb (bug rate), lead time pro nasazení změn, pokrytí testy (test coverage), míra selhání po nasazení (failure rate) a schopnost doručovat spolehlivé funkce (delivery reliability). Tyto metriky lépe odrážejí skutečný dopad práce vývojáře na produkt a uživatele.
Měkké faktory bývají stejně důležité nebo i důležitější: schopnost spolupráce v týmu, architektonické uvažování, schopnost zjednodušovat složité problémy a komunikovat obchodní kontext technickým kolegům. Silní inženýři často prodávají méně řádků, ale více hodnoty — například tím, že navrhnou opakovaně použitelné moduly, zavedou rozumné testy nebo optimalizují výkonnost kritických cest. Firmy, které ignorují tyto aspekty, riskují odměňovat chování vedoucí k narůstajícímu technickému dluhu a narušení stability produktu — což je nákladná chyba pro každou technologicky orientovanou společnost.
Praktické metody pro lepší měření zahrnují kombinaci nástrojů a procesů: sestavování spojovacích metrik (balanced scorecards), zavedení pravidelných code review s objektivními kontrolními body, metrik pro kvalitu kódu jako cyclomatic complexity nebo maintainability index, a sledování trendů v počtu regresních chyb. Dále pomáhá sledovat metriky nasazení — jak často se nasazuje do produkce, jak dlouho trvá opravit kritickou chybu (MTTR), a jaká je doba od zadání úkolu po jeho nasazení (lead time). Tyto ukazatele dávají manažerům reálný obraz o efektivitě a kvalitě vývoje, aniž by se uchylovali k jednoduchým a zavádějícím číslům.
Další doporučení zahrnuje kultivaci firemní kultury, která podporuje technické rozhodnutí vedoucí k udržitelnosti. To znamená investovat do vzdělávání v oblasti návrhových vzorů, architektury, testování a kontinuální integrace (CI). Automatizované testy, CI/CD pipelines a monitoring v produkci jsou praktické nástroje, které dávají vedení a produktovým vlastníků reálné signály o kvalitě dodaného kódu, jeho spolehlivosti a dopadu na koncového uživatele.
V souhrnu: měřte kvalitu, rychlost doručení a dopad, nikoli jen množství řádků. Takové metriky podporují lepší rozhodování, snižují technický dluh a vedou k robustnějším produktům.
Torvaldsova kritika je proto užitečným připomenutím pro technologické lídry: vybírejte metriky, které podporují udržitelnost a promyšlený design. Jinak riskujete odměňovat chování, které zvyšuje technický dluh a podkopává stabilitu produktu — což je pro společnost závislou na technologii drahá chyba. Místo jednostranných metrik preferujte soubor indikátorů, které společně poskytují vyvážený obrázek o zdraví kódu i týmu.
Zdroj: smarti
Zanechte komentář