Přejít k navigační liště

Zdroják » Různé » Neprofesionální kód: Když chybí testy a standardy

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

Články Různé

Je v roce 2019 akceptovatelné, pokud není kód pokrytý testy? Pro velkou část vývojářů jsou testy pořád nutným zlem a pro manažery ztrátou času. Programátoři mají ale v rukou unikátní moc takovou praxi změnit a vyžadovat elementární standardy kvality.

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.

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.

Komentáře

Subscribe
Upozornit na
guest
20 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Vít Heřman

Pod skutečně vše bych se podepsal, až na jedno: Pokrytí kódu testy. Nejsem si jist, zda jste psal o užitečností testů v některých případech nebo jste měl na mysli snahu o maximalizaci počtu testů obecně. Soudě podle literatury a různých školení jsem zcela systematicky došel k názoru, že se až na výjimečné případy smysl testů jakožto jediného řešení kvality nadhodnocuje. Silně typové jazyky, programování odolné nekontrolaným null hodnotám, využívání typovaných struktur a jejich bezpečných transformací, vhodná architektura, vhodné teoretické výpočetní modely jsou nástroje daleko užitečnější, než většina tzv. učebnicových testů. Klasické automatizované testy jsou vhodné až jako řešení, pokud předchozí nástroje nelze použít. Tedy z principu nechci počet takových testů maximalizovat, ale spíše minimalizovat. Přesto v řídících systémech letadel nebo v medicíně nepopírám nutnost maximalizace testů jako nutnou redundanci vzhledem k riziku. V běžném zakázkové software typu administrace nebo webové stránky nikoli.

Vladimir Kloz

Je třeba najít určitý balanc – primární výhodu testů vidím osobně v několika oblastech:

  • Pohodlnost budoucích změn – pokud mám testy a rozšiřuji funkcionalitu pak vím, že předchozí záměr zůstal zachován (nebo byl modifikován záměrně)
  • Občas píšeme testy, které developera vedou v rozšiřování funkcionality stylem – fail – zkontroloval jsi tohle a tamto?
  • Lepši struktura kódu – k tomu, aby bylo možné snadno testovat je většinou třeba SRP – psaní unit testů toto enforcuje – samozřejmě používání základních paternů to řeší samo o sobě, ale kolik lidí toto skutečně umí a dělá? S rozmachem IoC kontejnerů se to lepší, ale…
    • Samozřejmě 90% code coverage znamená jen jediné – všechny bugy programátor zamýšlel jako feature a z pohledu uživatele to nic neznamená
Vít Heřman

Pokud k tomuto účelu používáte testy, je možné, že:

  • Zatím vývojář nedokáže zadání dobře vyjádřit samotným kódem napřímo. Aneb nějak začne psát kód, až dokonverguje k tomu, aby to dělalo, co chce. Kód pak nereprezentuje přesně to, co je zadáním, ale obsahuje vnitřní konstrukce, které navenek pravděpodobně plní původní záměr, avšak s velkou mírou nejistoty, že správně a s jistotou, že se jedná o zbytečný balast, který by se měk tak jako tak odstranit. A pokud jsou k tomu testy, jsou změny nakonec pohodlné ještě méně
  • Pokud píše testy jiný programátor, tak testy už smysl mohou dávat. Ale nepůjde nejspíš o unit testy.
  • Psaní unit testů skutečně nutí kód k rozkladu. Bohužel často daleko více, než je vhodné. Jak poznám, kdy je rozkladu moc? Podle toho, že pro názvy funkcí/metod potřebuju až příliš velké, podivné a jednoúčelové abstrakce (abstraktní názvy), které nejsou obsaženy v původním zadání. Krom toho snadno degraduje k situaci, kdy jsou napsané špatně testy i kód

Nic z toho nemusí být Váš případ. Ale už jsem byl nesčetněkrát svědkem toho, co popisuji. Proto mívám v aplikaci testů skutečně málo (řádově jednotky), a to zejména pro složitější knihovní funkce jako např. formátovací funkce, parsery, apod. Ale implementace business procesů a zpracování business dat obvykle testy nepotřebuje. Prostě se rovnou zapisují a když se správně zapíší a jdou zkompilovat, unit test už je pro daný případ nesmyslnou redundancí. Už jen proto, že i zákazník si funkčnost ujasňuje až hotovou implementací a přepisovat k tomu dokola testy je čirý nesmysl.

Proto tvrzení v článku, že pokrytí testy je znakem profesionality považuji za nesmyslné. Opak je pravdou. Profesionál ví, kdy testy použít a kdy existují lepší způsoby pro zajištění kvality a udržitelnosti.

ivan

Souhlasím. Působí to tak, že z testování, užitečného nástroje zodpovědných programátorů, se stává rigidní náboženství kněží. Místo promyšlení nejvhodnějšího postupu pro danou situaci, je tu dogma, které musí být následováno. Kdo nenásleduje, je neprofesionál.

Stano

Priznám sa, že patrím k tej skupine čo zatiaľ nemá vžité hneď písať testy. Práve tu pod článkom som čakal nejakú diskusiu, prípadne veselé príhody z praxe ktoré by ma presvedčili začať sa tomu venovať :-) No škoda…

jaan

Lepsi zadny test, nez spatny test.

Sprostý dělník

Teorie je hezká věc, ale v praxi u nízkorozpočtových aplikací bez nějakého fatálního dopadu při selhání zákazník ty testy prostě nezaplatí. Musíte to napsat dokonale na první dobrou. Chyby vám snižují výdělek.

Daniel Rusnok

Dle mého názoru zákazník nemusí ani vědět o způsobu, jakým přistupujete k vývoji softwaru. Automatizované testy nezdržují vývoj. To už bylo několikrát dokázané. Ano, pokud nejste zvyklý je psát, tak ze začátku to je zdržení, protože to neumíte. Ale tak je to na začátku s každou technikou.

Vít Heřman

To dokázané nejen že nebylo, ale navíc je to obecně nedokazatelné. Maximálně lze prokázat, že v některých případech skutečně ke zlepšení kvality došlo. Klíčové je to slovo některých. A zcela určitě také není pravda, že testování zpomaluje jen toho, kdo to neumí. Také zpomaluje toho, jehož dovednosti jsou na takové úrovni kvality a disciplíny, že přidané testování již kvalitu nezvyšuje. Senior vývojář obvykle umí kód psát s minimální chybovostí, kde nějaká maximalizace pokrytí testy by byla totálně non-sense, je to skutečně dáno dlouhou praxí. Juniora testy mohou lecčemus naučit, ale nemusí to být konečná na cestě k efektivitě…

Vít Heřman

Dal jsem si vaše jméno do Googlu a přečetl pár vašich příspěvků na Dotnetportal. Začal jste testovat teprve před cca rokem a půl. Bojoval jste s tím, že Vás to moc nebavilo. Patrně procházíte klasickým vývojem, kterým jsem prošel také. Dokonce jste uznal, že ne vše stojí za unit testy. Přistoupil jste k rozumnějšímu rozsahu unit testů. Asi jste také začal nově přemýšlet o kvalitě kódu. Pokud v tomto budete pokračovat, dostanete se podle mne dříve nebo později k poznání, které popisuji. Aby bylo jasno, píšu z pozice toho, který se TDD naučil, provozoval a začal postupně opouštět ve prospěch zajímavějších způsobů. Nejde o žádný odpor k neznámému…

Vít Heřman

Taky myslím, že to je správná cesta. A hlavně, dnes jsou už nástroje natolik vyspělé, že mohou maximálně pomáhat napsat to na tu první dobrou. Zbytečné chyby odchytí lint, kompilátor, apod… A před těmi ostatními testy samotné neochrání…

Pavel Kříž

Ahoj Vítku,
já jsem testy vždycky chápal jako něco, co dělám pro někoho jiného. Pro kolegy nebo svoje budoucí já, které za pár měsíců nebude znát detaily dané funkcionality a nějakým zásahem ji naruší. Řekl bych, že správně napsané testy, v těchto případech, snižují pravděpodobnost, že přidáním nějaké funkcionality rozbiji jinou. Proti tomu se zase asi dá argumentovat schopnostmi vývojáře, který do cizího kódu zasahuje a čitelností/návrhem samotného kódu. To asi ano. Máš s tímto jinou zkušenost?

Stará škola

No líbí se mi věta: Lepsi zadny test, nez spatny test.
Protože špatný test jsou vyhozené peníze. A zobecňování, kdo nedělá testy, je špatný, se mi nelibí. Uvedu 2 klasické příklady. Práce pro zákazníka na zakázku, kdy zákazník přímo specifikuje, co chce vidět, co chce aby kód dělal a pro davy. Pro davy, zde není moc odezva, pokud je odezva, tak v případě negativní odezvy je po produktu. Tedy dovolit si vypustit kód bez testování je sebevražda.
Pro zákazníka – považuji za nutné minimální testování a stačí testování programátorem. Ten musí spustit a najít chyby. Ale skutečně minimální. Protože:
– Zákazník myslí A, říká B a programátor rozumí C, pokud do toho vložíte konzultanta, který informaci předává, dostaneme se až k písmenu F … tedy testovat musí zákazník, zda mu to splňuje ono A
– Při práci se složitějšími aplikacemi (dělám ERP), existuje několik cest, jak nějakou věc udělat. Testeři nikdy nejdou stejnou cestou jak uživatelé.
– Viděl jste někdo uživatele co testovali? Já znám jednoho, kdo si ten čas najde a udělá to. Většina to nechá na ostrý provoz a pak se diví.
Byl jsem ve firmě, kde testy byly modlou. Velká spolupráce s auditorkými společnostmi. A jsem statistik. Takže rád věci měřím a analizuji. Výsledek několika let statistik: Pokud na testování věnuji stejný čas jako na programování, eliminuji cca 5% chyb. Nebo lépe řečeno ušetřím 5% z výsledného času oprav. Neboť poměr oprav po testech a oprava bez testů byl ve firmě s rozsáhlým testováním a dokumentací skutečně jen o cca 5% nižší, než následně u nás, kde testy minimalizujeme co to jde. Jen u riskantních věcí. Čas uspořený testováním je ale obrovský.
A tvorba dokumentace – vždy mě to štvalo, a protože jsem měl možnost změnit kód nástroje na tvorbu dokumentace, zapnul jsem sledování jejího využití. Rok jsem nechal běžet a pak se těšil na výsledky. A lidi jsem do výkazů donutil rozlišovat čas trávený programováním, testováním a tvorbou dokumentace (nebavím se o komentářích v kódu, ale popis funkcionality bokem, help chcete-li). Všem doporučuji sledovat a pak argumentovat. Výsledek. Nad tvorbou dokumentace se strávilo cca 5% z celkového času programátorů. Několik stovek hodin celkem. Počet čtení a vyhledávání – 7. Já z toho 5 (testování mé funkcionality). Vedení okamžitě tvorbu dokumentace zakázalo. Já sám u sebe ji dnes také nepraktikuji. Tak asi tak …

shemale01

nemám statistiku rád (podle mě je to pavěda s neúplnými daty), ale to je jedno ;-)

Jsem rád, že konečně někdo zmínil jak to je. Jsem programátor přes 25 let a ještě jsem nikdy neviděl případ, že by testy byly 100%. Takový test vlastně ani napsat nejde. Možná na nějaké jednoduché funkcionality, ale komplexní testy už budou tak složité, že to opravdu nepokreje přínos psaní testů. Prošel jsem asi klasickým vývojem jako většina programátorů, když jsem je neuměl psát, nesnášel jsem je, pak se to zlepšovalo a dnes od nich opouštím z důvodů, který tu už někdo psal – typování, refaktoring na malé jednoduché části. Testy mám jen opravdu na kritické věci.

V hodně firmách jsem viděl testy typu assert(true), takže výsledek byl sice „PASSED“, ale test je k ničemu. Nebo se otestuje jen jeden případ.

Rozhodně se nemohu ztotožnit s názorem „Ten, kdo nepíše testy, není profesionál“. Za mě mi to přijde fakt směšné a spíše opovrhuji člověkem, který si toto myslí… :-D To je jako bych řekl, neprogramátoři jsou looseři… Nebo, že Ti co používají odsazování pomocí tabu, že jsou amatéři… Profesionalita se rozlišuje podle jiných kritérií a testy nebo jejich kvalita či počet nemá na to vliv.

L.

Jak už napsali předřečníci teorie je jedna věc a praxe druhá.

Psát kód pro kolegy a ne pro počítač je jistě dobrá myšlenka. Jenže coding standards jí nijak zvlášť nepomáhají. Protože „přehlednost a pochopitelnost“ se těžko nějak definují. Takže to většinou skončí u formalit typu „Za IF a ELSE nesmí být jednotlivý statement, ale musí tam vždy být blok“. Pro zajištění takových standardů se většinou použije nějaký automatický formáter a často se dokonce v CI kontroluje, že jím máte kód opravdu zformátovaný.

Jenže pak nastane situace, kdy v kódu máte pole strukturovaných položek (typicky objektů) a pro přehlednost samozřejmě chcete, aby byly všechny naformátovány jednotně. Jenže jejich obsah má různou délku, takže automatický formátter některé z nich naformátuje na jeden řádek a jiné na několik řádků. A přehlednost jde do p**, coding standards tak přehlednosti kódu naopak škodí. To není žádný umělý příklad, to se mi několikrát stalo v praxi.

Ohledně testování tu už bylo pár příspěvků napsáno a jen je potvrzuji. Automatické testy mohou pomoci, ale nedá se z nich dělat modla. Samotná coverage a úspěšné testy nic reálně nezaručují. Jsou věci, které se automaticky testují lépe a ty, kde automatické testy moc smysl nemají. Snad jediný poznatek co ještě nezazněl: Dobře se testují čisté (pure) funkce a programátor by se měl snažit je psát, kde to dává smysl. Pak budou i automatické testy efektivnější.

Na konec jsem si nechal bonbónek největší: code review. Teoreticky dobrá myšlenka. Reálně ale programátoři tráví hodiny a hodiny debatami o formalitách, které mají naprosto minimální reálný dopad. A i přes spoustu času stráveného na code reviews do programu klidně projde prasárna, pokud není vidět na první pohled. Není to zkušenost z jedné firmy, ale z několika různých, lidi jsou prostě lidi. Plus code reviews znamenají nutnost přehazování kontextů (autor než čeká na PR nesedí se založenýma rukama, ale dělá něco jiného, hodnotitel buď přeruší práci, nebo dílčí úkol dokončí, ale to zase znamená velké zpomalení vývoje). Tahle nutnost přepínání má také negativní vliv na výkon.

Co s tím, přiznám se, moc nevím. V některých případech jsou PR dobré, typicky u nováčků nebo když někdo hrabe (i) do něčeho, čemu úplně nerozumí a někdo jiný ano – tak mu dá kód na review. Ale cena za ně je opravdu hodně vysoká.

Peter Humaj

Zdravim vsetkych,
nie som cisty IT, ale robim v oblasti automatizacie. Uz 16 rokov vyvijame SCADA/MES system, ktory zacal v 1993 v jazyku Modula-2 na OS/2, neskor (1998?) premigrovany do jazyka Ada na Windows NT. Momentalne platformy Win32/Win64/Linux/Raspberry.

Pisem novy kod (prevazne komunikacne ovladace) a udrzujem kod po kolegoch (niektori uz nie su vo firme). K udrzovatelnosti podla mojho skromneho nazoru (popri kulture programovania) znacne prispieva prave pouzitie jazyka Ada. Predtym som bol C-ckar, co je jazyk umoznujuci v porovnani s Adou neskutocne kompaktny zapis, ktory vie byt neskutocne chybovy, neprenositelny a necitatelny.

V Ade sa clovek viac napise, ale zase sa to ovela lepsie cita ako C-cko. Navyse Ada chrani pred roznymi blbostami typu pristup za hranice pola, typova kontrola a podobne.

Co sa tyka testovania – zase, v oblasti komunikacii sa daju robit „nejake“ unit testy, ale tie najzaujimavejsie chyby su spojene s realtimom a najlepsie sa odladia na produkcii. Bohuzial. Takze aj kod, ktory vo firme alebo u jedneho zakaznika funguje, moze mat problemy a skryte vady, ked sa bavi s niecim inym. To je zivot. Snazit sa vsetko 100% otestovat pri vyvoji by bolo jednak nemozne, jednak prilis drahe. Dolezitejsie je, ze vieme pri nabehu komunikacii chyby rychlo najst a opravit (rychlo sa mysli, ze spravim patch do hodiny/dvoch, v horsich pripadoch do niekolkych dni).

Niektore chyby su potvory – sam som opravoval chyby (po sebe), ktore boli v 10-rokov starom kode a prejavili sa v specifickej konfiguracii. Najst toto pomocou testovania – sorry, bez sance.

jakub

Obávám se, že článek nedělá testům příliš velkou službu, protože stejně jako software je nástrojem na zvýšení efektivity lidské činnosti, tak testy jsou kontrétním softwarovým nástrojem na zvýšení efektivity lidské činnosti programátora. A stejně jako není efektivní používat software při sázení stromů do země, není potřeba mít test na každý vývoj softwaru.

I ta úvodní metafora v tomto pokulhává, protože právě medicína je dobrým příkladem, kde se spíše s testy výrazně cílí a šetří. Když stejně jako dalších X milionů lidí v ČR letos chytíte rhinovirus (nachlazení), tak vás nepošlou na testy všech nemocí, které mají podobné příznaky, ale domů, ať pijete teplý čaj. A i když jsou testy na kdeco, tak test na (doplňte si vlastní nemoc počátečními symptomy podobnými nachlazení) se plošně neprovádí, protože je nákladný a má nějaké procento false positives (a to si myslím, že zdaleka ne tak velké jako testy softwaru).

Ten problém vidím ve větě „…považuje v roce 2019 psaní byť jenom unit testů za zdržování a otravný úkol…“. Já se naopak snažím prosadit směr opačný – první a nejdůležitější je akceptační test zákazníka, aneb „jak poznám, že je výsledný software užitečný“. Tento test je vlastně větší kus zadání. Je-li některá úroveň testování ta kritická, tak je tato úroveň.

A jako další věc teprve řeším automatizaci tohoto testu. Nepokouším se ohnout co se testuje, jenom proto, abych mohl test automatizovat.

Až mám toto, řeším další úrovně testování. Testy UI bývají důležité v mém zaměření (webové aplikace), kde je sice krásné, že funkce spočítá DPH správně, ale celá ta věc je trochu nanic, když uživateli chybí pole pro zadání sazby DPH (klasická stižnost „to mělo přece programátora napadnout!“). Užitečné se mi v praxi ukázaly automatizované integrační testy na webové služby – nepříjemně často někdo mírně rozbije rozhraní na druhé straně, což se špatně poznává.

Jednotkové testy se sice dobře ukazují v tutoriálech, ale pokud zrovna není programátor součástí technologického startupu, tak bez zajištění těch výše zmíněných vyšších úrovní si obsah jednotkových testů cucá z prstu.

To se naneštěstí někdy děje, i když ty akceptační testy napsány jsou. Což je jedna z těch tragičtějších věcí, co jsem viděl v praxi – nový kus kódu, u kterého projdou všechny jednotkové testy, ale zkusil jsem provést první krok z akceptačních kritérií, a zobrazuje se jiný než očekávaný výsledek.

Navrhuji tedy alternativní část neprofesionality k řešení v roce 2020 – pokrýt kód akceptačními kritérii.

Dan

Kodex programátora je určitě skvělá věc do růžového světa věčné blaženosti, kde jsou všichni lidé hodní, mají se rádi, kde je tvrdá práce vždy odměněna, kde lidé drží slovo a kde manažeři upřednostňují štěstí lidí se zásluhami před (svými) penězi.

Ovšem do normálního světa, jaký znám já, se absolutně nehodí a je to jako jít kázat lásku ozbrojeným gangům do no-go zóny.

Pokud pracujete na tom, abyste byli snadno nahraditelní, zadavatel (nebo zaměstnavatel) vám pěkně poděkuje a snadno vás nahradí – nejlépe někým levnějším.

Pro projekt je to určitě cool, ale pro vaši peněženku už méně. Stejně jako pro vaše manželství, až budete manželce vysvětlovat, že sice zůstanete bydlet v paneláku a na vilku na předměstí může zapomenout, ale až ji zase bude vadit noční randál od sousedů, může ji u srdce hřát, že její muž je hrdým kodexářem!

Jediným důvodem proč jsou platy vývojářů vyšší než je běžné, je právě jejich nesnadná nahraditelnost.

Vzpomínám si, že v „devadesátkách“ nebyl problém, aby měl běžný vývojář odměnu ve výši zhruba 13 násobku mediánové čisté mzdy. V dnešní době už je to jen několikanásobek.

Nejsou výjimkou ani firmy nebo nabídky práce, kde firma platí vývojářům stejně nebo dokonce méně než platí Lidl zaměstnancům v prodejnách, kteří musí umět udělat jen „píp“, doplnit zboží do regálu, vytřít podlahu a při všem se usmívat jako kdyby dostali mrtvici.

VendorLock je určitě zcela „neprofesionální“, ale znám člověka, který dostává od nadnárodní firmy stovky tisíc korun jen za drobnou úpravu aplikace. Za přidání větší funkcionality, která mu zabere tak týden, si účtuje 2 – 6 milionů. Může, protože je tam nepřekonatelný VendorLock.
Ano, je to „parchant nedodržující kodex“. Multimilionářský, nechutně prachatý, parchant.

Pak znám i člověka, který bydlí na vesnici, poctivě pracuje jako programátor v menší firmě, dodržuje zmíněný kodex – především pracuje na přehlednosti a svojí snadné nahraditelnosti, je rád, když dostane výplatu včas a bere podprůměrnou mzdu. Nedávno se s ním rozešla partnerka, protože ji už nebavilo vydělávat víc než on a živořit.

Kodex je super věc pro firmy a pro zadavatele a majitele projektů. Ovšem pamatujte na to, že Bill Gates by nebyl nejbohatším člověkem na světě, kdyby dodržoval kodexy.

Tomas

Taky je tu opacny problem. Treba nekdo je ve vetsi firme, kde se obcas stava, ze nekdo odejde a vy musite prevzit praci po jinych. A ac jste ve firme spokojeni, tak vam pristane na hlave takovy binec, ze radeji taky odejdete a jdete hledat dal. Jen bohuzel nebydlite v praze ani brne, delat na dalku a mit pernamentni homeoffice vas vubec nelaka. Najednou problem co dal a jen proto ze ostatni kolegove jsou prasata…

Kamil Voves

Váš komentář mi zlepšil den!

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.

Pocta C64

Za prvopočátek své programátorské kariéry vděčím počítači Commodore 64. Tehdy jsem genialitu návrhu nemohl docenit. Dnes dokážu lehce nahlédnout pod pokličku. Chtěl bych se o to s vámi podělit a vzdát mu hold.