Na začátku je vždy těžké porozumět velkému a starému projektu. Architektura je jednou z činností posudku architekta. Obvykle musíte pracovat s velkými, starými projekty a výsledky musí být doručeny do týdne.
Jak vyhodnotit projekt o 100 XNUMX nebo více řádcích kódu za týden a přitom stále poskytovat výsledky, které jsou pro klienta skutečně užitečné.
S podobným hodnocením projektů se setkala většina architektů a technických vedoucích. Může to vypadat jako semi-formální proces nebo jako samostatná služba, jak se to dělá v naší společnosti, tak či onak to většina z vás řešila.
Originál v angličtině pro vaše nerusky mluvící přátele je zde: .
Přístup naší společnosti
Řeknu vám, jak to u nás ve firmě funguje a jak v podobných situacích postupuji já, ale tento přístup můžete snadno změnit podle potřeb vašeho projektu a firmy.
Existují dva typy hodnocení architektury.
Vnitřní – většinou to děláme u projektů v rámci firmy. Každý projekt může požádat o posouzení architektury z několika důvodů:
- Tým si myslí, že jejich projekt je dokonalý, a to je podezřelé. Měli jsme takové případy a často v takových projektech není vše zdaleka ideální.
- Tým chce otestovat svůj projekt a jejich řešení.
- Tým ví, že věci jsou špatné. Mohou dokonce uvést hlavní problémy a příčiny, ale chtějí úplný seznam problémů a doporučení pro zlepšení projektu.
Externí je formálnější proces než interní hodnocení. Klient přichází vždy jen v jednom případě, kdy je vše špatně – velmi špatně. Klient obvykle chápe, že existují globální problémy, ale nedokáže správně identifikovat příčiny a rozdělit je na komponenty.
Posouzení architektury pro externího klienta je složitější případ. Proces by měl být formálnější. Projekty jsou vždy velké a staré. Mají spoustu problémů, chyb a křivého kódu. Maximálně do několika týdnů by měla být hotová zpráva o provedené práci, která by měla obsahovat hlavní problémy a doporučení ke zlepšení. Pokud se tedy budeme zabývat externím posouzením projektu, pak bude interní posouzení hračkou. Podívejme se na nejtěžší případ.
Hodnocení architektury podnikového projektu
Typický projekt k hodnocení je velký, starý, podnikový projekt se spoustou problémů. Klient k nám přijde a požádá nás, abychom jeho projekt opravili. Je to jako s ledovcem, klient vidí jen špičku svých problémů a netuší, co je pod vodou (v hlubinách kódu).
Problémy, na které si zákazník může stěžovat a o kterých si může být vědom:
- Problémy s výkonem
- Problémy s použitelností
- Dlouhodobé nasazení
- Nedostatek jednotkových a jiných testů
Problémy, které si klient s největší pravděpodobností neuvědomuje, ale mohou se v projektu vyskytovat:
- Bezpečnostní problémy
- Problémy s designem
- Špatná architektura
- Algoritmické chyby
- Nevhodné technologie
- Technický dluh
- Špatný proces vývoje
Formální proces revize architektury
Jedná se o formální proces, který jako společnost dodržujeme, ale můžete si jej přizpůsobit v závislosti na vaší společnosti a projektu.
Žádost od klienta
Klient požaduje zhodnocení architektury aktuálního projektu. Odpovědná osoba na naší straně shromažďuje základní informace o projektu a vybírá potřebné odborníky. V závislosti na projektu se může jednat o různé odborníky.
Architekt řešení – hlavní osoba odpovědná za hodnocení a koordinaci (a často jediná).
Naskládejte konkrétní odborníky – .Net, Java, Python a další techničtí specialisté v závislosti na projektu a technologiích
Odborníci na cloud – může jít o cloudové architekty Azure, GCP nebo AWS.
Infrastruktura – DevOps, správce systému atd.
Ostatní odborníci – jako jsou velká data, strojové učení, výkonnostní inženýr, bezpečnostní expert, vedoucí QA.
Sběr informací o projektu
O projektu byste měli shromáždit co nejvíce informací. V závislosti na situaci můžete použít různé techniky:
- Dotazníky a další způsoby komunikace prostřednictvím pošty. Nejneefektivnější způsob.
- Online schůzky.
- Speciální nástroje pro výměnu informací jako: Google doc, Confluence, repozitáře atd.
- Setkání „naživo“ na místě. Nejúčinnější a nejdražší způsob.
Co byste měli od klienta dostat?
Základní informace. O co v projektu jde? Jeho účel a hodnota. Hlavní cíle a plány do budoucna. Obchodní cíle a strategie. Hlavní problémy a požadované výsledky.
Informace o projektu. Technologický zásobník, frameworky, programovací jazyky. On-premise nebo cloudové nasazení. Pokud je projekt v cloudu, jaké služby se používají. Jaké architektonické a designové vzory byly použity.
Nefunkční požadavky. Všechny požadavky týkající se výkonu, dostupnosti a snadného použití systému. Bezpečnostní požadavky atd.
Základní případy užití a datové toky.
Přístup ke zdrojovému kódu. Nejdůležitější část! Určitě byste měli získat přístup k úložištím a dokumentaci, jak projekt postavit.
Přístup k infrastruktuře. Bylo by hezké mít přístup k jevišti nebo produkční infrastruktuře pro práci s živým systémem. Je velkým úspěchem, pokud má klient nástroje pro monitorování infrastruktury a výkonu. O těchto nástrojích si povíme v další části.
Документация. Pokud má klient dokumentaci, je to dobrý začátek. Možná je to zastaralé, ale pořád je to dobrý začátek. Nikdy nevěřte dokumentaci – otestujte ji s klientem, na skutečné infrastruktuře a ve zdrojovém kódu.
Proces hodnocení architektury
Jak lze zpracovat tak velké množství informací za tak krátkou dobu? Nejprve paralelizujte práci.
DevOps by se měl podívat na infrastrukturu. Technický vstup do kódu. Výkonový inženýr pro zobrazení metrik výkonu. Databázový specialista by se měl ponořit hlouběji do datových struktur.
Ale to je ideální případ, kdy máte hodně prostředků. Projekt obvykle hodnotí jeden až tři lidé. Odhad můžete dokonce provést sami, což se často stává, pokud máte patřičné znalosti a zkušenosti ve všech oblastech projektu. V tomto případě musíte všechny procesy co nejvíce zautomatizovat.
Bohužel budete muset dokumentaci číst ručně. Se správným množstvím zkušeností můžete rychle pochopit kvalitu dokumentace. Co je pravda a co se zjevně neshoduje s realitou. Někdy můžete vidět architekturu v dokumentaci, která nikdy nebude fungovat v reálném životě. To je spouštěč k zamyšlení nad tím, jak se to v projektu ve skutečnosti dělalo.
Užitečné nástroje pro automatizaci hodnocení projektů
Vyhodnocení kódu je jednoduché cvičení. Můžete použít statické analyzátory kódu, které vám ukážou problémy s designem, výkonem a zabezpečením. Zde je několik z nich:
je skvělý nástroj pro architekta. Ukáže vám celkový obraz, závislosti mezi moduly a potenciální oblasti pro refaktoring. Jako všechny dobré nástroje to stojí slušné peníze, ale můžete využít 30denní zkušební verzi.
- starý dobrý nástroj. Nástroj pro analýzu statického kódu. Umožňuje identifikovat špatný kód, chyby a bezpečnostní problémy pro více než 20 programovacích jazyků.
Všichni poskytovatelé cloudu mají nástroje pro monitorování infrastruktury. To vám umožní správně vyhodnotit efektivitu vaší infrastruktury z hlediska nákladů a výkonu. Pro AWS je to tak . Pro Azure je to snadné .
Další sledování výkonu a protokolování pomůže najít problémy s výkonem na všech úrovních. Počínaje databází s neefektivními dotazy, backendem a konče frontendem. I když klient tyto nástroje dříve nenainstaloval, můžete je poměrně rychle integrovat do stávajícího systému a identifikovat problémy s výkonem.
Jako vždy, dobré nástroje stojí za to. Mohu doporučit několik placených nástrojů. Samozřejmě můžete použít open-source, ale zabere vám to více času. A to by mělo být provedeno předem, nikoli během procesu architektonického posouzení.
– nástroj pro hodnocení výkonu aplikace
– služba monitorování cloudového systému
Pro testování bezpečnosti je k dispozici mnoho nástrojů. Tentokrát vám doporučím bezplatný nástroj pro skenování systému.
– nástroj pro skenování webových aplikací z hlediska shody s bezpečnostními standardy.
Pojďme vše spojit v jeden celek.
Příprava zprávy
Začněte svůj přehled s údaji, které jste shromáždili od klienta. Popište cíle projektu, omezení, nefunkční požadavky. Poté by měla být uvedena všechna vstupní data: zdrojový kód, dokumentace, infrastruktura.
Další krok. Uveďte všechny problémy, které jste našli ručně nebo pomocí automatických nástrojů. Velké automaticky generované sestavy umístěte na konec v sekci aplikací. Měly by existovat krátké a výstižné důkazy o nalezených problémech.
Upřednostněte nalezené problémy na stupnici chyby, varování, info. Můžete si vybrat vlastní měřítko, ale toto je obecně přijímané měřítko.
Jako správný architekt je vaší povinností poskytnout doporučení k nápravě nalezených problémů. Popište vylepšení a obchodní hodnotu, kterou zákazník obdrží. Jak ukázat obchodní hodnotu z jsme diskutovali dříve.
Připravte si plán s malými iteracemi. Každá iterace by měla obsahovat čas na dokončení, popis, množství zdrojů potřebných ke zlepšení, technickou hodnotu a obchodní hodnotu.
Dokončíme posouzení architektury a poskytneme klientovi zprávu
Nikdy neposílejte jen hlášení. Nemusí být přečten vůbec nebo nemusí být přečten a pochopen bez náležitého vysvětlení. Živá komunikace zkrátka pomáhá eliminovat nedorozumění mezi lidmi. Měli byste si naplánovat schůzku s klientem a promluvit si o nalezených problémech a zaměřit se na ty nejvýznamnější. Stojí za to upozornit klienta na problémy, které si možná ani neuvědomuje. Například bezpečnostní problémy a vysvětlit, jak by mohly ovlivnit podnikání. Ukažte svůj plán s vylepšeními a diskutujte o různých možnostech, které jsou pro klienta vhodnější. Může to být čas, zdroje, množství práce.
Jako shrnutí schůzky zašlete klientovi svou zprávu.
Konečně,
Hodnocení architektury je složitý proces. Pro správné provedení hodnocení potřebujete dostatek zkušeností a znalostí.
Již za týden je možné klientovi poskytnout výsledky užitečné pro něj a jeho podnikání. I když to děláš sám.
Na základě mých zkušeností bylo mnoho vylepšení staženo uprostřed a někdy se nikdy nespustilo. Ti, kteří si pro sebe zvolili zlatou střední cestu a provedli pouze část vylepšení, která byla pro podnik nejužitečnější, s minimálními mzdovými náklady, výrazně zlepšili kvalitu svého produktu. Kdo nic neudělal, mohl projekt po několika letech úplně uzavřít.
Vaším cílem je ukázat klientovi maximální vylepšení za minimální cenu.
Další články ze sekce můžete číst ve svém volném čase.
Přeji vám čistý kód a dobrá architektonická rozhodnutí.
Naše facebooková skupina - .
Zdroj: www.habr.com