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).

C.A.R. Hoare, držitel Turingovy ceny za definici a návrh programovacích jazyků 1980, řekl: „Jsou dva způsoby návrhu softwarové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 komplikované, že nejsou žádné zjevné nedostatky.“

Často jsem kritizovaný 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 „Nerozumíš osvědčeným postupům (best practices).“ až po „Nenávidíš testování!“. Abych se neopakoval, 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 ospravedlnit zpoždění a vymlouvat se na kvalitu kódu či jeho eleganci. Jestliže klient potřebuje 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ý implikuje, že produkovat lépe udržovatelný kód vyžaduje více času. Budu pokračovat v dávání termínu „osvědčené postupy“ do uvozovek, protože standardy se liší, nepočítám-li ty nejzákladně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řirozeným standardem pro každého slušného programátora. Potřebujete-li víc času, abyste tyto standardy zapracovali, jste přinejlepší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 instinktivně by neměl nazývat proměnné $a, $b, $c, atd.. Připouštím, jsou pokročilejší „osvědčené postupy“, ale hlavní smysl zůstává, „osvědčené postupy“ nejsou omluvou pro nedodrž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ší, nejflexibilnější a nejrobustně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á stanovený jasný termín a/nebo konkrétní rozpočet, které musí být splněny, což často znemožňuje vytvořit něco impozantního. Zde musí programátoři učinit vědomé rozhodnutí, omezit kreativitu, aby splnili zadání. Nemůžete obhájit týden strávený na „pořádné“ cachovací vrstvě pro databázové dotazy nad dvacetiřádkovou tabulkou, která je použitá pouze v administrační panelu navíc jen třemi uživateli. Rozumějte případu použití. Nepotřebujete flexibilní a rozšiřitelný XHR framework, který bude podporovat souběžné požadavky (jakkoliv skvělé může být ho vytvořit), pakliže ho použijete pouze pro aktualizaci počítadla návštěvní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 nejmodernější systém, ale ten, který ví, kdy to nedělat.

Ve světě softwarového vývoje je čas uvedení na trh hnací silou byznysu. Ve světě internetových aplikací je to díky dynamice webu ještě mnohem zřejmější. Jestliže je čas podstatou, tak nejjednodušší řešení je nenabízet nejlepší řešení; to je vždy nejlepší řešení. Čímž se dostáváme k poslednímu bodu kontroverze: technický dluh.

Často slýchávám argument, že šulení povede k nárůstu technického dluhu v dlouhodobém horizontu, a náklady na něj by měly být brány v potaz během všech rozhodnutí. Ve skutečnosti to podporuje můj názor. To je přesně důvod proč rozhodnutí, kde a jak osekávat, je klíčové při práci na projektech orientovaných na termín. Jsou různé druhy „technického dluhu“ a nejrychlejší řešení (alespoň trochu duchaplné), nutně nemusí váš technický dluh zvýšit. Podobně překombinování vás nezbaví technického dluhu. Schopnost činit taková rozhodnutí, často uprostřed projektu, rozlišuje veterány od začátečníků.

Navíc lidé, kteří mluví o nebezpečí technického dluhu, často neberou v potaz dopad na byznys. Technický dluh by měl být porovnáván s aktuální návratností investic (ROI), protože v mnoha případe je efektivně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 technického dluhu, ale ztratili tak příležitosti a/nebo okamžité získání příležitosti, která může být v čase větší než náklady na samotný dluh.

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