Udržitelný kód je ekonomická vlastnost, ne estetická preference

Skoro každý tech lead zná ten okamžik z plánovací schůzky. Navrhne, že se na něco vezme čas pořádně — a ozve se: „Teď to potřebujeme rychle, hezký kód řešit nemusíme.“ A je rozhodnuto. Ten spor se ale neprohrává kvůli termínu. Prohrává se kvůli tomu, jak je položený.

01Spor, který se pořád prohrává

Slova jako „čistý kód“, „elegantní řešení“ nebo „řemeslná kvalita“ mají jeden společný problém: znějí jako preference. A preference v rozpočtu vždycky prohraje s termínem — protože termín je závazek, kdežto preference luxus. Dokud udržitelnost obhajujete vkusem, prohrajete, i když máte pravdu.

Řešení není argumentovat hlasitěji ani moralizovat o profesionalitě. Řešení je vyměnit veličinu, o které se vůbec bavíte.

02Udržitelnost = cena příští změny

Co tedy je udržitelný kód, když ne „hezký“? Definice, která drží: udržitelný kód je takový, u kterého malá funkční změna znamená malý zásah a předvídatelné riziko. Čitelnost, testy, struktura — to jsou prostředky k tomuhle cíli, ne cíl sám.

A pokud kód přežije pilotní fázi, příští změna přijde — a obvykle ne jedna. Otázka pak nezní, jestli se bude měnit, ale kolik ta změna bude stát: kolik času, jak velké riziko, kolik lidí se do ní musí zapojit, jaká je šance, že se rozbije něco jiného. Tohle všechno jsou čísla. Udržitelnost je jejich součet — není to vlastnost vzhledu kódu, je to vlastnost jeho ekonomiky.

03Komplexita je ta daň

Co cenu příští změny zvedá? Hlavní položka má jméno: komplexita. John Ousterhout ji v knize A Philosophy of Software Design definuje prostě — komplexita je všechno, co dělá software těžším na pochopení a na změnu.

Pozná se podle dvou příznaků. Zesílení změny: triviální úprava si vynutí zásah na deseti místech. A kognitivní zátěž: abyste mohli něco bezpečně změnit, musíte si v hlavě udržet příliš mnoho věcí najednou.

Komplexita se nabaluje po troškách — žádný jednotlivý commit ji nevytvoří, a právě proto si jí nikdo nevšimne. A nabaluje se z obou stran: stejnou daň vyrábí zanedbaný kód i přehnaná abstrakce a vrstvy „pro budoucnost“, která nepřijde. Ta druhá je nebezpečnější tím, že vypadá ctnostně. Funguje to ale stejně — daň platíte při každé další změně, donekonečna. „Ošklivost“ je až důsledek. To, co stojí peníze, je komplexita pod ní.

04Není to názor — jsou na to data

Námitka „kvalita nás zpomaluje“ zní jako zdravý rozum. Data ale říkají opak. Výzkum DORA, který roky měří výkonnost dodávky softwaru napříč tisíci týmy, ukazuje konzistentní vzorec: týmy s vysokou výkonností dodávají častěji a zároveň mají míň výpadků.

Nejsou to protiklady — alespoň ne u zralých týmů a zralých systémů, na kterých DORA měří. Schopnosti, které k téhle výkonnosti vedou — malé změny, rychlá zpětná vazba, nízká míra předělávání — jsou přesně to, čemu se říká udržitelnost. „Kvalita versus rychlost“ je na úrovni týmu z větší části falešné dilema. Za horizontem několika týdnů udržitelný kód tým zrychluje, ne zpomaluje.

05Krátkodobě to ale jako tradeoff vypadá

Buďme poctiví v tom, kde je tradeoff reálný. V horizontu příštích dvou týdnů je zkratka opravdu rychlejší. Vynechat návrh, nepsat testy, zkopírovat blok — dnes to ušetří čas. To není iluze.

Iluze je myslet si, že to platí i za půl roku. Křivka ceny změny se u obou cest rozchází: zanedbaný kód je levný dnes a výrazně dražší potom; udržovaný kód je dnes o trochu dražší a výrazně levnější později. Jediná otázka, která rozhoduje, zní: jak dlouho bude tenhle kód žít? U produkčního kódu je odpověď skoro vždycky „déle než pár týdnů“ — a tehdy se ekonomika obrací. U prototypu nebo experimentu může být opačná, a to je v pořádku. Problém nastává, když „prototyp“ tiše přežije do produkce, aniž ho někdo přepíše.

06Refaktoring je splátka, ne úklid

Pokud je komplexita daň, refaktoring je nástroj, jak ji držet nízko. Jenže „refaktoring“ zní zase jako úklid — estetická činnost, na kterou „není čas“. Přerámujte to: refaktoring je průběžná investice, která drží cenu příští změny dole.

Záleží na tom, kdy ho děláte. Velká refaktoringová kampaň je projekt, který management dřív nebo později zařízne. Refaktoring dělaný průběžně — vždy v té oblasti, kterou se zrovna chystáte měnit, těsně předtím, než ji změníte — je skoro zadarmo. Tehdy totiž jen snižujete cenu změny, kterou stejně děláte.

07Jak ten spor vyhrát

Praktická část je v jazyce. Přestaňte u obhajoby kódu používat slova „čistý“, „elegantní“ nebo „best practice“. Říkejte místo toho:

• „Tohle zvedne cenu každé další změny v téhle oblasti.“
• „Tahle úprava bude tady levná a tamhle drahá — a tady je proč.“
• „Zkratku vzít můžeme. Tady je její úrok a tady, kdy ho začneme platit.“

Napojte udržitelnost na čísla, která CTO už dávno sleduje: přesnost odhadů, lead time změny, dobu onboardingu, počet incidentů. Udělejte tu neviditelnou cenu viditelnou. Druhá strana téže mince je technický dluh — když chcete ten náklad pojmenovat a roztřídit, je o tom samostatný článek Technický dluh není bordel v kódu.

08Závěr: udržitelnost je cenovka vaší budoucnosti

Udržitelný kód není řemeslná ctnost, kterou hájíte z principu. Je to cenovka vaší budoucnosti — souhrn toho, kolik vás bude stát všechno, co se systémem ještě uděláte.

Týmy, které „na udržitelný kód nemají čas“, obvykle platí za každou změnu nejvíc. Jen jim ten účet nikdy nepřijde najednou — rozpustí se do pomalých odhadů a opatrných nasazení.

Přerámujte udržitelnost z estetiky na ekonomiku a ten spor se z velké části vyhraje sám.