Úvod do technického dluhu
Technický dluh je termín, který popisuje budoucí náklady, které vzniknou výběrem jednoduchého řešení dnes místo použití lepších postupů, protože jejich dokončení by trvalo delší dobu.
Pro porovnání s finančním dluhem byl zvolen dlouhodobý technický dluh. Je běžné, že lidé, kteří mají finanční dluh, dělají rozhodnutí, která se zdají být vhodnou nebo jedinou možností v době, ale tím se zvyšuje úrok.
Čím větší zájem se hromadí, tím těžší je pro ně v budoucnu a čím menší možnosti jsou jim k dispozici později. S finančním dluhem se brzy zvyšuje úrok na úroky, což vytváří sněhový efekt. Podobně technický dluh může vzbudit až do bodu, kdy vývojáři tráví téměř celý svůj čas tříděním problémů a prováděním přepracování, ať už plánovaných nebo neplánovaných, a nedají se přidat hodnotu.
Tak jak se to stane?
Nejčastější omluva je těsné termíny. Když jsou vývojáři nuceni rychle vytvořit kód, budou často používat klávesové zkratky. Například místo refaktoringu metody tak, aby zahrnovala nové funkce, můžeme zkopírovat a vytvořit novou verzi. Pak pouze testuji nový kód a mohu se vyhnout úrovni testování požadované, pokud změním původní metodu, protože jiné části kódu ho používají.
Teď mám dvě kopie stejného kódu, který potřebuji upravit v budoucnu místo jednoho, a riskuji rozbíhající se logiku. Existuje mnoho příčin. Mezi vývojáři může být například nedostatek technických dovedností a vyspělosti nebo bez jasného vlastnictví nebo směru produktu.
Organizace nemusí mít vůbec kódovací standardy. Vývojáři tedy ani nevěděli, co by měli vyrábět. Vývojáři nemusí mít přesné požadavky na cílení. Může se jednat o změny požadavků na poslední minutu.
Je možné, že se zpozdí potřebná práce refaktoringu. Nemusí existovat žádné testování kvality kódu, ruční nebo automatizované. Na konci to jen znesnadňuje a znesnadňuje poskytování hodnoty zákazníkům v přiměřeném časovém rámci a za rozumné náklady.
Technický dluh je jedním z hlavníchdůvodůch
V průběhu času se zvyšuje mnohem stejným způsobem jako peněžní dluh. Mezi běžné zdroje technického dluhu patří:
- Chybí styl kódování a standardy.
- Nedostatek nebo špatná konstrukce testovacích případů jednotek.
- Principy návrhu orientace objektů se ignorují nebo nerozumějí.
- Monolitické třídy a knihovny kódu.
- Špatně si představovalo použití technologií, architektury a přístupu. (Zapomeňte na to, že je potřeba zvážit všechny atributy systému, které ovlivňují údržbu, uživatelské prostředí, škálovatelnost a další).
- Over-engineering code (přidání nebo vytvoření kódu, který není nutný, přidání vlastního kódu, pokud jsou dostatečné existující knihovny nebo vytváření vrstev nebo komponent, které nejsou potřeba).
- Nedostatečné komentáře a dokumentace
- Nezapisuje kód pro samodokumentování (včetně názvů tříd, metod a proměnných, které jsou popisné nebo označují záměr).
- Pořizování zástupců pro splnění konečných termínů
- Ponechání mrtvého kódu na místě.
Poznámka:
V průběhu času musí být technický dluh zaplacen zpět. Jinak bude schopnost týmu řešit problémy a implementovat nové funkce a vylepšení trvat déle a nakonec se stát nákladným zákazem.
Viděli jsme, že technický dluh přidává sadu problémů během vývoje a výrazně ztěžuje přidání další hodnoty zákazníka.
Díky technickému dluhu v projektu je produktivita, frustruje vývojové týmy, znesnadňuje pochopení kódu i křehkost, zvyšuje dobu provádění změn a ověřování těchto změn. Neplánovaná práce se často dostává do cesty plánované práce.
Dlouhodobě také vysadí sílu organizace. Technický dluh se obvykle vyděsí na organizaci. Začíná malá a postupně roste. Pokaždé, když se rychle hack provede nebo testování obchází, protože změny je třeba projít, problém se zhorší a horší. Náklady na podporu se získají vyšší a vyšší a v případě, že dojde k závažnému problému.
Organizace nakonec nemůže reagovat na potřeby svých zákazníků včas a nákladově efektivním způsobem.
Automatizované měření pro monitorování
Jedním z klíčových způsobů minimalizace neustálého získání technického dluhu je použití automatizovaného testování a hodnocení.
V ukázkách, které následují, se podíváme na jeden z běžných nástrojů používaných k vyhodnocení dluhu: SonarCloud. (Původní místní verze byla SonarQube).
K dispozici jsou další nástroje a probereme několik z nich.
Později v dalším praktickém cvičení se dozvíte, jak nakonfigurovat Službu Azure Pipelines tak, aby používala SonarCloud, porozumět výsledkům analýzy a nakonec nakonfigurovat profily kvality pro řízení sad pravidel používaných SonarCloudem při analýze vašich projektů.
Další informace najdete v tématu SonarCloud.
Shrnutí:
Azure DevOps je možné integrovat s širokou škálou existujících nástrojů, které se používají ke kontrole kvality kódu během sestavování.
Jaké nástroje pro kvalitu kódu aktuálně používáte (pokud nějaké)?
Co se vám líbí nebo se vám nelíbí nástroje?