CZ Dev Radar overview

CZ Dev Radar

Velký průzkum technik používaných v českých softwarových firmách zvaný „CZ Dev Radar“ má za cíl zmapovat, jaké nástroje, metody a technické a manažerské postupy se používají při vývoji software v Česku v roce 2024.

Použité pojmy

V průzkumu se používají pojmenování pro nástroje, techniky, frameworky, zejména z oblasti agilního vývoje, které nemusí být běžně známé. Stručný přehled nejdůležitějších z nich obsahuje slovníček pojmů.

Výsledky průzkumu CZ Dev Radar 2024

Obsah

Sběr dat probíhal v březnu 2024. Průzkumu se zúčastnilo 116 účastníků z nejméně 42 různých firem v různých městech Česka. Pokud vás zajímají podrobné demografické statistiky a diskuse o validitě odpovědí, můžete přeskočit na sekci, která se tomu věnuje. Výsledky se zveřejňují postupně na této stránce. O aktualizaci informuji vždy na sociálních sítích, zejména na svém profilu na LinkedIn.

Nástroje

V této sekci se zaměříme na nástroje, které vývojáři používají při své každodenní práci. V dalším textu budu používat pojem vývojář pro všechny pozice, které dělají individuální práci (tzn. programátor, tester, architekt, UX designer, atd.)

Odpovídali pouze respondenti bez podřízených a více odpovědí z jedné firmy se počítalo zpravidla vícekrát (pokud není uvedeno jinak), jelikož každý vývojář může používat jiné nástroje.

Nástroje pro programování

Mezi verzovacími systémy podle očekávání výrazně vede git, ostatní v podstatě nestojí za řeč.

Zajímavější je použití programovacích jazyků. Nějakou variantu jazyka pro vývoj frontendu používají zhruba 2/3 vývojářů. Backendové jazyky jsou rozložené poměrně rovnoměrně, mezi nejpopulárnější patří C#, Java Python. Do grafu se nevešly jazyky s méně než 3 odpověďmi (např. bash, PowerShell, Perl, AWK, Groovy).

U databázových technologií je ve výrazném vedení PosgreSQL, nicméně používané spektrum je poměrně široké a mnoho firem používá více technologií najednou.

V oblasti vývoje webu výrazně vede react, nicméně tady je pole pronásledovatelů opravdu široké a je poznat, že v oblastí probíhá překotný vývoj. V žádné jiné otázce nepřišlo tolik nápadů navíc v odpovědi „jiné“. Do grafu jsme dali jenom odpovědi, které se objevily aspoň třikrát, ale v odpovědích se objevily také Express, fastify, BitSwan, Dojo, Wicket, Handlebars, fastapi, Svelte i WordPress(?!).

I přesto, že technologie od Microsoftu jednoznačně nedominují v předchozích oblastech, na používaných IDE jednoznačně vidíme dominanci Visual Studia Code.

Když se na předchozí graf podíváme pořádně, všimneme si také, že se často objevují různá IDE od Jetbrains. Tyto odpovědi jsme tedy sloučili a podívali se kolik vývojářů používá aspoň jeden nástroj od Microsoftu a aspoň jeden od Jetbrains. Výsledky jsou vidět na dalším grafu.

Nástroje pro testování a nasazení

U cloudových technologií se při vyplňování dlouho o prvenství přetahovaly Microsoft Azure a AWS. Azure nakonec ukazuje větší použití, ale vzhledem k počtu odpovědí to může být v rámci statistické chyby.

U nástrojů pro automatické testy máme vzácně vyrovnaný stav. Na prvních 4 místech se v rámci statistické chyby umístily Azure DevOps, Jenkins, Github Actions a Gitlab.

U knihoven pro psaní automatických testů stále vede Selenium, i když celosvětově jeho popularita asi klesá. Na vzestupu jsou další frameworky – zejména Cypress a Playwright.

Nástroje pro spolupráci

U nástrojů pro správu požadavků jsme sloučili odpovědi lidí ze stejné firmy. Vidíme, že vládne Jira. (Pozn. autora: můj názor na Jiru je všeobecně znám a soudím, že stav, kdy mnoho firem používá Jiru, může být zároveň symptomem a zdrojem mnoha dysfunkcí v těchto organizacích. O tom ale nejspíš napíšu zvláštní příspěvek.)

Mezi online nástěnkami je jednoznačně nejpopulárnější Miro. Za mě trochu překvapivě skoro nikdo (1 odpověď) nepoužívá Mural, který má téměř stejné funkce jako Miro. Jednu odpověď posbíralo i Excalidraw, které umožňuje malovat nedokonalé obrázky, které vypadají jako ručně malované. A samozřejmě mám radost z toho, že několik lidí používá mé oblíbené draft.io. Bylo by možná zajímavé zjistit, k čemu všemu lidé ve firmách tyto nástěnky používají.

Skoro všichni používají pro psaní interní dokumentace Wiki stránky. Naopak dřívější praxe psaní dokumentů není už dnes příliš rozšířená. Není se čemu divit, v těch verzích se pak nedá vyznat. Zajímavé je, že zhruba polovina firem dokumentuje svůj software přímo v kódu nebo velmi blízko kódu (markdown). K tomuto tématu bych se někdy rád vrátil a prozkoumal, jaké to má důsledky.

Technické praktiky

V této části se zaměříme na to, jaké technické praktiky se používají při vývoji.

Analýza a design

Na tuto oblast směřovaly otázky na dvě techniky. Specification By Example se soustřeďuje na komunikaci vývojářů se zákazníky a pomáhá snížit množství nedorozumění, které vznikají špatným pochopením zadání. Podle odpovědí je poměrně málo rozšířená, což je trochu škoda.

Architecture Decision Records se naproti tomu zaměřují na spoluprácí uvnitř týmu. Umožňují týmu levným způsobem dokumentovat architektonická rozhodnutí.

Do této oblasti patří i udržování interní dokumentace, kterou jsme už uváděli v jiné sekci.

Kódování

Další část otázek se týkala kódování. Jelikož použité technologie a jazyky jsme si odbyli v první části, zde se zaměříme na praktiky, které jsou nezávislé na technologii. Jejich společnými rysy je to, že mají vliv na kvalitu výsledného produktu a také že tvarují spolupráci v týmu.

Zdá se, že drtivá většina vývojářů dnes používá unit testy, což je dobře, protože zvýšené pokrytí automatickými testy jednoznačně zvyšuje kvalitu produktu. Zajímalo by mě, jak funguje těch 14% firem, které unit testy nepíší. Jak zaručí, že jejich kód funguje po každé změně? Nějaké zkušenosti?

Ostatní techniky jsou už rozšířené méně. Pojďme je vzít postupně: pair/mob programming sám o sobě kvalitu nezajistí, ale výrazným způsobem přispívá ke zrychlení učení v týmu, což je důležité zejména, pokud pokud máte v týmu nováčka nebo pracujete s velkou codebase (a jste vlastně nováčci všichni). Bohužel tyto techniky využívá jen velmi málo lidí. Napadá vás, proč to tak může být?

Téměř čtvrtina lidí používá Test-Driven Development, což je pro mě osobně dobrá zpráva – očekával jsem daleko menší číslo. Potenciál ke zlepšení je ale značný – TDD prokazatelně zvyšuje pokrytí kódu testy a tím i kvalitu.

Dále se podívejme na konvence v kódu. Je to jedna ze základních technik, jak vylepšit spolupráci zejména na velkých produktech. Každý programátor má svůj styl psaní kódu a pokud se nesjednotí, vypadá každý kousek jinek (určitě jste to už zažili).

Většina týmů v nějaké formě konvence používá, ovšem vynucovány jsou pouze zhruba v polovině případů.

Revize kódu (code reviews) jsou další technikou, která zvyšuje jak kvalitu kódu, tak spolupráci v týmu. Je potěšující, že velká většina týmu nějaké revize dělá. Už méně potěšující je, že to dělají tou nejméně interaktivní formou – pomocí komentářů v Pull Requestu. Takové revize mají často tendenci sklouzávat k formalismu místo plodné diskuse o zadání designu a kvalitě kódu. Navíc jejich kvalita je nepřímo úměrná velikosti Pull Requestu. Jak říká známá průpovídka – 10 řádku – 10 komentářů, 1000 řádků – vypadá to dobře.

Poslední a nejzajímavější kódovací statistika se týká vlastnictví kódu. Vzhledem ke zkušenostem ze svých zaměstnáních, kde probíhaly velmi vzrušené debaty o tom, jak vůbec nepřichází v úvahu pustit každého blbce do všech částí kódu, jsem očekával, že soukromé vlastnictví kódu bude převažovat. Opak se ukázal být pravdou. Možnosti byly:

  1. Každou část kódu někdo vlastní (jednotlivec nebo tým) a pouze tito lidé ji mohou upravovat.
  2. Existují citlivé komponenty, které mohou měnit jen pověření lidé. Zbytek kódu má volnější pravidla.
  3. Vývojář může upravit i jiné části kódu, než za které je zodpovědný, ale pokud upravuje něco, co není „jeho“, musí požádat o povolení.
  4. Každý vývojář může upravit kteroukoliv část kódu, ale pro některé komponenty potřebuje schválení od určených jiných vývojářů.
  5. Každý vývojář může upravit kteroukoliv část kódu bez omezení (plně sdílené vlastnictví)

Jak vidíme z obrázku – plně nebo skoro plně sdílené vlastnictví kódu významně převažuje. Háček ovšem může být ve formulaci otázky, která byla formlovaná takto: „Který výrok ohledně vlastnictví kódu se nejvíce hodí pro váš produkt?“ Nevíme, co přesně respondenti považují za produkt. Jestli respondenti odpovídali na sdílené vlastnicví kódu v celém produktu nebo jenom v části, za kterou je zodpovědný jejich tým. To by samozřejmě odpovědi zkreslilo.

Testování a nasazení

Nejen kódováním živ je vývojář. Produkty je potřeba taky otestovat a nasadit do produkce. Podívejme se, jaké techniky se k tomu používají.

Automatické testy (myšleno jiné než unit testy) používá většina týmů, pravděpodobně jako tzv. regresní sadu.

Několik dalších otázek se týkalo průběžné integrace. Schváně jsem ovšem nepoužil pojem Continuous Integration (CI), protože je přetížený jiným významem, ale ptal jsem se na konkrétní praktiky, které k tomu patří.

Zhruba dvě třetiny týmů používají feature branches, které se s CI prakticky vylučují. Jedna šestina používá Trunk-Based Development, která je jedním z předpokladů CI. Zajímalo by mě, co dělá ta zbývající šestina.

Dalším předpokladem CI je automatický build ihned po commitu. Opět jsme zhruba na dvou třetinách. Předpokládám, že ostatní pouštějí build méně často. Nebo snad dnes existují firmy, které dělají build manuálně? Pokud máte nějaké takové historky, sem s nimi.

Poslední část otázek se týkala vydávání.

Zdá se, že časté vydávání převažuje. Zřejmě to souvisí s přechodem na model Software-as-a-Service. Tomu by odpovídal i významný podíl použití feature flagů. Zhruba 15% respondentů vydává několikrát denně, což je model, který se blíží continuous delivery.

Je třeba zdůraznit, že časté vydávání není na úkor kvality. Více než dvě třetiny firem vydávají software s malým nebo žádným počtem známých chyb.

Na základě těchto dat bych si dovolit rozdělit české firmy na tři skupiny. Moderní firmy jsou schopny vydávat aspoň jednou týdně a používají několik moderních technických praktik. Firmy typu „aspoň“ něco mají nastavený pravidelný automatický build a používají aspoň nějaké moderní technické praktiky. No a pokud patřite mezi firmy, které nic z toho nědělají, měli byste se nad sebou zamyslet nebo požádat o odbornou pomoc.

Práce v týmech

V další části se zaměříme na to, jak ve firmách fungují týmy. Na všechny otázka odpovídali lidé bez podřízených (individual contributors), jedná se tedy o zhruba 60-70 odpovědí z nejméně 40 firem.

Na úvod mě napadá, že jsem při zadávání otázek automaticky předpokládal, že nějaké týmy existují. Žádný velký odpor proti formulaci otázek se ale nezvedl, takže můj předpoklad byl zřejmě správný. Pokud znáte nějakou firmu, která neorganizuje vývoj software v týmech, svěřte se v komentářích.

První otázka se týkala velikosti týmu.

Kromě několika respondentů, kteří pracují samostatně, všichni pracují v nějakém týmu, přičemž velká většina dodržuje doporučení velikosti sedm plus mínus dva, které pochází už z roku 1956 a kterým se inspiroval i Scrum. (I když já ve své praxi doporučuji spíš ještě menší týmy, něco jako pět až sedm.) Některé týmy jsou ale větší, možná i o hodně větší. Zajímaly by mě vaše zkušenosti s takto velkým týmy. Jak probíhá koordinace uvnitř týmu? Vzniká v takovém týmu nějaká přirozená hierarchie? Dá se tomu pořád říkat tým nebo je to spíš skupina?

Další otázka se týkala toho, jak moc jsou týmy end-to-end. Bylo poměrně obtížné se na to přesně zeptat, takže otázka zněla takto: Které fáze vývojového cyklu pokrývá váš tým? Možnosti byly: Analýza, Design, Kódování, Testování, Nasazení (Deployment), Údržba a bylo samozřejmě možné zatrhnout více fází. Upřímně, tady jsem měl očekávání, že většina týmů bude zodpovědná pouze za kódování a testování, ale dopadlo to jinak:

Polovina týmů (podle jejich vlastního vyjádření) jsou plně end-to-end týmy (pokrývají všech šest fází) a další čtvrtina vynechává pouze jednu fázi (přičemž vynechané fáze byly v odpovědích poměrně rovnoměrně rozloženy). Pokud by to tak opravdu bylo, znamenalo by to, že ve většině českých firem se to hemží týmy, které jsou schopny téměř jakékoliv činnosti od přímé komunikace se zákazníkem až po nasazení na produkci a řešení problémů v produkci. Já mám zkušenosti trochu jiné, týmy jsou většinou nějak omezené, ale možná jsem zatím viděl malý vzorek. Jaké jsou vaše zkušenosti? Dala by se tato otázka položit nějak líp? Kde může být háček? Nebo je to opravdu tak?

Ale pojďme dál. Další otázky se týkaly počtu programovacích jazyků používaných v týmech. Tady nám i při tomto počtuodpovědí vycházejí plynulé grafy, které připomínají nějaké pravděpobnostní rozložení (odborníci doplní které). Dodám, že toto rozložení se ustálilo při mnohem menším počtu odpovědí, než bylo nakonec průzkumu a potom už se moc neměnilo.

Pro vývoj velké většiny aplikací je potřeba více než jeden programovací jazyk, ale zase to není nějak závratně velké číslo. Dobrá, kolik programovacích jazyků tedy aktivně používá každý člen týmu?

Když si odmyslíme 0, kterou vyplnili neprogramátoři (poměrně vysoké procento), ostatní odpovědi opět tvoří plynulé pravděpodobnostní rozložení, které má maximum ve dvojce. Jinými slovy: pro většinu aplikací nám stačí tři jazyky a mně jako členu týmu stačí umět dva, abych mohl dobře fungovat. Je to zajmavý argument do diskusí o nutnosti učení do šířky v agilních týmech. Většina lidí si v první chvíli představí tu nejhorší možnou situaci (všichni musí umět všechno), ale vidíme, že v praxi to tak není.

Jak tedy členové týmu na vývoji spolupracují? Otázka zněla takto: Kolik lidí v týmu typicky ZÁROVEŇ pracuje na jedné nové funkci? (Funkce = requirement, feature, user story). Jelikož jsem v této fázi nemohl předpokládat žádný proces, musel jsem položit otázku hodně obecně i s tím rizikem, že odpovědi budou špatně porovnatelné.

Vidíme, že obvykle na jedné funkci pracují méně než 4 lidé, neméně objevily se i větší čísla. (Jeden respondent dokonce odpověděl 10. Tuto odpověď jsem z grafu vyřadil, aby byl čitelnější. Respondent měl asi na myslí větší celek než ostatní.) Když se tedy soustředíme na většinu, ta nám říká, že spolupráce při vývoji buď vůbec neprobíhá (1 = 34%) nebo probíhá v malé části týmu (2+3 = 54%). To nemusí být nutně špatně, pokud jsou vyvíjené funkce relativně jednoduché a nevyžadují žádnou spolupráci (např. oprava chyb). Může to být ale také symptom toho, že tým nepracuje jako tým, ale spíš jako skupina, například vývojář vyvine, předá testerovi k otestování a mezitím dělá něco jiného. Z jedné otázky se nedá tolik poznat a chtělo by to zeptat se podrobněji. Pokud vás nějaké vhodné otázky do příště napadají, dejte je, prosím, do komentářů.

Další otázka směřovala na stáří týmu neboli na dobu, kterou spolu lidé v týmu tráví. Opět je poměrně obtížné se zeptat tak, aby z toho byla jednoznačná odpověď. Např. když je vymění jeden člen týmu, je to už nový tým nebo ne? Proto otázka nakonec zněla takto: Jak dlouho je váš tým spolu? (Počítejte jako průměrný čas v letech, který spolu v jednom týmu strávila většina členů týmu.)

Z odpovědí je vidět, že většina firem se snaží držet relativně stabilní týmy, které jsou spolu roky. To je souladu s výzkumem týmové práce, který říká, že týmy jsou efektivnější, pokud jsou spolu dlouhou dobu.

Poslední otázka se týkala složení týmu a odpovídali na ni jak llidé bez podřízených, tak manažeři. Výsledky v obou skupinách byly prakticky totožné, takže je ukážu dohromady.

Zhruba o dvou třetinách týmů rozhoduje výhradně manažer. Zhruba čtvrtinu týmů si členové skládají sami. Zbytek jsou nějaké kombinace, při kterých jsou zapojeny obě strany, případně další lidé z firmy (koučové, produkťáci, apod.)

Provedení průzkumu

Výzkumu se zúčastnilo 116 účastníků. Z toho 68 vyplnilo jméno své firmy. Po ručním sloučení duplicit (např. Avast / GenDigital) se ukázalo že máme vyplněné výsledky z nejméně 42 různých firem, spíše mnohem více, protože dalších 48 účastníků firmu nevyplnilo. Zároveň z žádné firmy nemáme více než 7 odpovědí, typická je naopak 1 odpověď z každé firmy, takže odpovědi nejsou výrazně zkreslené ve prospěch jedné firmy.

Města

Většina respondentů působí v Brně a Praze. Mezi dalšími městy se objevily Olomouc, Ostrava, Hradec Králové nebo Plzeň. Někteří respondenti vyplnili více měst.

Zkušenosti

Výzkumu se zúčastnili respondenti s širokým spektrem zkušeností od několika měsíců po téměř 30 let.

Pozice

Téměř 40% respondentů pracuje na manažerských pozicích se zodpovědností za podřízené.

Názvy pozic se výrazně liší firma od firmy a kreativita personalistů je opravdu velká, jak se můžete přesvědčit na přiloženém Word cloudu.

Nicméně, pokud se pokusíme pozice vměstnat do nějakých předpřipravených odpovědí, dostaneme toto rozložení (vybírali jsme pozice, které se objevily více než jednou).

Firmy

Většina respondentů jsou zaměstnanci firem, a to velkých firem. Pokud započítáme i „živnostníky“, kteří pracují pouze pro jednoho zákazníka, jedná se o více než 90%, kteří jsou v zaměstnaneckém nebo podobném poměru.

Zároveň většina odpovědí přišla z velkých firem, ale i malé firmy jsou přiměřeně zastoupeny.

Skoro 80% respondentů vcelku podle očekávání uvedlo, že oborem podnikání jejich firmy je vývoj software. Zajímavé byly ale další odpovědi. Deset nejčastějších je ukázaných na následujícím grafu.

Více než 90% respondentů dělá produktový vývoj, z toho velká většina pro externí platící zákazníky. Jiné formy vývoje (body leasing, projektový vývoj, open source) jsou ve výrazné menšině.

Harmonogram

AktivitaObdobí
Sběr datbřezen 2024 – do 29.3.
Zpracování datbřezen 2024 – duben 2024
Publikace výsledkůduben 2024

Publikace výsledků probíhá postupně na této stránce a v komentované podobě na mém LinkedIn profilu. Pokud vás výsledky zajímají, přihlaste se ke sledování profilu.

Sběr dat

Sběr dat byl ukončen. Nyní probíhá vyhodnocení. Pokud máte stále zájem připět, napište autorovi průzkumu.