Mám rád čistý kód. Kvalita kódu ovšem mnohdy musí ustoupit byznys požadavkům a nemusí to být nutně špatně. Leon Fayer o tom sepsal pěkný článek Your Code May Be Elegant. S jeho laskavým svolením jsem text přeložil do češtiny (překlad uvolňuji pod licencí Creative Commons by-nc-sa).</i>

C.A.R. Hoare, držitel Turin­govy ceny za definici a návrh progra­mo­vacích jazyků 1980, řekl: „Jsou dva způsoby návrhu softwa­rového designu: Jeden způsob je udělat to tak prosté, že zjevně nejsou žádné nedostatky, a druhý způsob je udělat to tak kompli­ko­vané, že nejsou žádné zjevné nedostatky.“

Často jsem kriti­zo­vaný za svou mantru přístupu k vývoji. Tvůj kód může být elegantní, ale můj, kurva, funguje. Dostává se mi odpovědí v rozsahu od „Nero­zumíš osvědč­eným postupům (best practi­ces).“ až po „Nenávidíš testování!“. Abych se neopa­ko­val, rozhodl jsem se sepsat svůj pohled na věc. Vaše volba zda souhlasíte či nikoliv.

Především tvrdím, že věta „projekt může mít zpoždění, ale kód [vypadá lépe / snadněji se udržuje / je čistší]“ (vyberte, co se hodí) je ve své podstatě chybná. Pokud má projekt zpoždění, není hotový. Tečka. Není způsob, jak ospra­ved­lnit zpoždění a vymlouvat se na kvalitu kódu či jeho eleganci. Jestliže klient potře­buje vánoční kampaň a vy doručíte nejlepší produkt v historii, ale 29. prosince, tak je to k ničemu.

Podívejme se na argument „osvědč­ených postupů“, který impli­kuje, že produ­kovat lépe udržo­va­telný kód vyžaduje více času. Budu pokrač­ovat v dávání termínu „osvědčené postupy“ do uvozo­vek, protože standardy se liší, nepoč­ítám-li ty nejzák­lad­nější, které by měl každý programátor mít zapsány za ušima ještě předtím, než spáchá svůj první „Hello World“. „Osvědčené postupy“ by měly být přiro­zeným standardem pro každého slušného programátora. Potře­bu­je­te-li víc času, abyste tyto standardy zapra­co­vali, jste přinej­lepším nováčkem na programátorské scéně. Triviální příklad: každý ostřílený programátor by měl řádně odsazovat řádky kódu a instink­tivně by neměl nazývat proměnné $a, $b, $c, atd.. Připouštím, jsou pokroč­i­lejší „osvědčené postu­py“, ale hlavní smysl zůstává, „osvědčené postupy“ nejsou omluvou pro nedod­ržení termínu. Navíc ostřílení programátoři by měli v takovém případě vědět kdy a především jak to ošulit. Což mě přivádí k dalšímu bodu: překombinování

Jako zkušený programátor rozumím touze vytvořit nejlepší, nejfle­xi­bil­nější a nejro­bust­nější systém. Opravdu. Ale rovněž rozumím běžným obchodním omezením každého projektu: čas a peníze. Většina projektů má stano­vený jasný termín a/nebo konkrétní rozpočet, které musí být splněny, což často znemožňuje vytvořit něco impozant­ního. Zde musí programátoři učinit vědomé rozhod­nutí, omezit kreati­vitu, aby splnili zadání. Nemůžete obhájit týden strávený na „pořádné“ cacho­vací vrstvě pro databázové dotazy nad dvace­tiřád­kovou tabul­kou, která je použitá pouze v administ­rační panelu navíc jen třemi uživa­teli. Rozumějte případu použití. Nepotře­bu­jete flexi­bilní a rozšiři­telný XHR framework, který bude podpo­rovat souběžné požadavky (jakkoliv skvělé může být ho vytvořit), pakliže ho použi­jete pouze pro aktua­li­zaci počítadla návštěv­níku na stránce. Rozumějte rozsahu. Nemůžu to zdůraznit víc: dobrý inženýr není ten, který ví, jak vytvořit nejmo­der­nější systém, ale ten, který ví, kdy to nedělat.

Ve světě softwa­rového vývoje je čas uvedení na trh hnací silou byznysu. Ve světě inter­ne­tových aplikací je to díky dynamice webu ještě mnohem zřejmější. Jestliže je čas podsta­tou, tak nejjed­no­dušší řešení je nenabízet nejlepší řešení; to je vždy nejlepší řešení. Čímž se dostáváme k posled­nímu bodu kontro­verze: technický dluh.

Často slýchávám argument, že šulení povede k nárůstu technic­kého dluhu v dlouho­dobém horizontu, a náklady na něj by měly být brány v potaz během všech rozhod­nutí. Ve skuteč­nosti to podpo­ruje můj názor. To je přesně důvod proč rozhod­nutí, kde a jak osekávat, je klíčové při práci na projek­tech orien­to­vaných na termín. Jsou různé druhy „technic­kého dluhu“ a nejrych­lejší řešení (alespoň trochu duchapl­né), nutně nemusí váš technický dluh zvýšit. Podobně překom­bi­nování vás nezbaví technic­kého dluhu. Schop­nost činit taková rozhod­nutí, často upros­třed projektu, rozlišuje veterány od začátečníků.

Navíc lidé, kteří mluví o nebez­pečí technic­kého dluhu, často neberou v potaz dopad na byznys. Technický dluh by měl být porov­náván s aktuální návrat­ností investic (ROI), protože v mnoha případe je efektiv­nější spustit aplikaci dříve. Takto vám může narůstat technický dluh, ale také vám okamžitě narůstá zisk a technický dluh můžete splatit časem. To může být vhodnější než zpozdit uvedení na trh, jen proto, abyste dodali bez technic­kého dluhu, ale ztratili tak příleži­tosti a/nebo okamžité získání příleži­tosti, která může být v čase větší než náklady na samotný dluh.

Jako softwa­rový vývojáři si často myslíme, že naše práce je tvořit software, ale ve skuteč­nosti je to jen prostře­dek, jak umožnit byznysu dosáh­nout jejich cílů. Tvůj kód může být elegantní, ale pokud nesplnil zadání, tak, kurva, nefunguje.