Neprofesionální kód: Když chybí testy a standardy

Celý článek

Představte si, že jste soukromý lékař. Jednoho dne vás navštíví pacient a chce se objednat na operační zákrok. “Nepřehánějte to, pane doktore. Vyšetřením byste se akorát zdržoval, a to nemáte zapotřebí. Určitě víte, co děláte. Cože, anesteziolog? A neprodraží to operaci?” namítá na váš standardní postup.

Scénář, který by se nejspíš v žádné nemocnici neodehrál. Jak je tedy možné, že se s takovou praxí běžně potkávají programátoři?

Srovnávat práci a odpovědnost lékaře a softwarového vývojáře se může zdát na první pohled zcestné. Stačí si ale uvědomit, kdo všechno je na běžném softwaru závislý.

Podnikatel a účetní, kteří pomocí webové aplikace vystavují faktury. Investiční společnosti, spravující stovky milionů korun. A v neposlední řadě i ten lékař, který předepisuje léky a eviduje diagnózy pacientů. Odbytá práce programátora vede v lepším případě ke ztrátám finančním, personálním a časovým, v tom horším také na životech.

Kodex programátora

Zatím co smyšlený doktor z našeho příběhu, nebo třeba daňový poradce, novinář či advokát, je vázán zákony a pravidly profesních komor, u vývojářů profesionalitu žádný předpis nedefinuje. Komoru programátorů byste také hledali marně.

Chybí také tlak spotřebitelů. Kdy naposledy jste se jako koncový uživatel ptali provozovatele, jak zajišťuje kvalitu softwarového vývoje, než jste mu svěřili svá citlivá data nebo dokonce důležitou firemní agendu?

Jak by taková pravidla, jakýsi “Kodex programátora”, měl vypadat? Začněme u testů.

Jak například Matthias Noback ve svém článku argumentuje, jejich absence je zjevným projevem neprofesionality. Problémem jsou i nekompletní, špatně napsané nebo nakonfigurované testy, protože vyvolávají iluzi bezpečí a vy se spoléháte na kód, který ve skutečnosti otestován není. Nebo hůř – testy ve všech případech “projdou”.

Je nicméně alarmující, kolik manažerů a programátorů považuje v roce 2019 psaní byť jenom unit testů za zdržování a otravný úkol. Jak víte, zda váš kód funguje bezchybně, i s hraničními hodnotami nebo nepravděpodobným chováním uživatele, pokud není otestovaný? Odpověď je jednoduchá. Nevíte.

“If you still don’t have tests, this is unprofessional. This is engineering, not banging rocks together.” @Ocramius#Symfony_Live

— alcaeus (@alcaeus) September 26, 2019

Kdo to bude číst

Šetření času na testech není zdaleka jediným znakem neprofesionálního kódu. Druhým zásadním omylem je přesvědčení, že kód píšeme pro počítač a ne pro lidi. Už ze samotné podstaty vyšších jazyků, jako jsou Java, Python nebo PHP, přitom vyplývá, že mají být čitelné především pro člověka. Psát kryptickou směs znaků, srozumitelnou jenom vám a stroji, na kterém běží, postrádá jakýkoli smysl.

Kód, kterému rozumí počítač, vygeneruje kompilátor nebo interpreter. Kód, kterému rozumí váš kolega, musíte napsat sami. Ano, čitelnost může být na úkor optimalizace. A v drtivé většině případů je to tak v pořádku. Protože šetříte čas programátorů, kteří váš kód čtou po vás, na úkor výkonného procesoru.

S tím úzce souvisí také téma code reviews. Mindset a atmosféra, která konstruktivním code reviews přeje, a vývojáři, kteří výtky v nich neberou osobně, jsou stěžejní nejen pro zajištění kvality kódu. Čtením práce vašich kolegů dochází ke sdílení znalostí v týmu (případně i mezi týmy). Navíc jde o skvělý způsob, jak integrovat juniorní vývojáře. A naopak, i oni mohou vnést nadhled a nápady zvenčí, které dlouholetým seniorům občas chybí.

A mohl bych pokračovat dále. Chybějící coding standards (“vždyť já vím, jak se to má správně psát”) v době, kdy jej lehce zkontrolují nebo dokonce opraví automatizované nástroje, absence kvalitní a aktualizované dokumentace, psaní nicneříkajících commitovacích zpráv a tak dále.

Na nic není čas

Společným jmenovatelem všech zmíněných projevů neprofesionality je snaha o ušetření času a peněz na vývoj. Pokud vyvíjíte obyčejnou webovou nebo mobilní aplikaci, která nepracuje s finančními daty a nezachraňuje lidské životy, možná si řeknete, že je kvalita druhořadá. Obzvlášť v případě, když jde o agenturní vývoj pro externího klienta.

Můžete namítnout, že je taková strategie omluvitelná například u prototypování nebo projektů s krátkou životností a máte samozřejmě pravdu. V ostatních případech je takové smýšlení krátkozraké. Pokud zdědíte takový projekt jako správce kolonie po čistokrevných kolonizátorech, zaveďte standardy kvality co nejdříve.

Technický dluh, který vytvoříte na začátku, bude těžké, ne-li nemožné, odstranit později. Odložíte si splátky, ale úroky vám je několikanásobně prodraží. Jakákoliv údržba a rozšiřování funkcionalit bude noční můrou. Vedení a zákazníci nepochopí, proč i přidání triviálního tlačítka ve formuláři může způsobit problémy a trvat tak dlouho.

Nemluvě o situaci, kdy odejdou klíčoví členové týmu, kteří se v daném projektu jako jediní orientují (protože kód psali pouze pro sebe a počítač). Do týmu bude těžké najít nové vývojáře, protože málokdo chce pracovat se špatným kódem. Nebo si za to nechá patřičně zaplatit.

Závěr

Jako vývojáři máme unikátní pozici a příležitost říkat “ne”. Využívejme ji.

Dodržujme základní standardy kvality. Odmítněme projekty, které nám neumožní vykonávat naši práci profesionálně. Pišme testy, protože investovaný čas se nám několikanásobně vrátí. Zaveďme coding standards hned v začátcích vývoje a hlídejme si je automatizovaně v rámci continuous integration procesu. Pěstujme kulturu code reviews mezi všemi členy týmu.

A zkusme se i jako spotřebitelé více zajímat o to, jakou technickou kvalitu mají produkty, na kterých závisíme.