Na začátku je vždy těžké zorientovat se ve velkém a starém projektu. Architecture assessment je jedna z činností architekta. Obvykle je potřeba pracovat s velkými, starými projekty a výsledky je nutné poskytnout během týdne.
Jak ohodnotit projekt o velikosti 100k a více řádků kódu během týdne a zároveň poskytnout opravdu užitečné výsledky pro klienta?
Většina architektů a technických vedoucích se setkala s takovými hodnoceními projektů. Může to vypadat jako poloformální proces, nebo jako samostatná služba, jak to děláme v naší společnosti, ať tak nebo onak, většina z vás s tímto měla co do činění.
Originál v angličtině pro vaše ne rusky mluvící přátele je zde: .
Přístup v naší společnosti
Povím vám, jak to funguje v naší společnosti a jak postupují v takových situacích, ale můžete tento přístup snadno měnit podle potřeb vašeho projektu a vaší společnosti.
Existují dva typy architecture assessment.
Interní – obvykle ho provádíme pro projekty uvnitř společnosti. Jakýkoli projekt může požádat o hodnocení architektury z několika důvodů:
- Tým si myslí, že jejich projekt je dokonalý, což je podezřelé. Měli jsme takové případy a často v těchto projektech není vše dokonalé.
- Tým chce zkontrolovat svůj projekt a svá řešení.
- Tým ví, že je vše špatně. Mohou dokonce vyjmenovat hlavní problémy a příčiny, ale chtějí získat kompletní seznam problémů a doporučení na zlepšení projektu.
Externí – je to 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ě. Obvykle klient chápe, že existují globální problémy, ale nedokáže správně určit příčiny a rozdělit je na jednotlivé části.
Hodnocení architektury pro externího klienta je komplikovanější případ. Proces musí být formálnější. Projekty jsou vždy velké a staré. Obsahují mnoho problémů, bugů a ošklivého kódu. Zpráva o provedené práci musí být připravena během několika týdnů maximálně, kde by měly být uvedeny hlavní problémy a doporučení k zlepšení. Proto, pokud se vypořádáme s externím hodnocením projektu, pak interní bude jen pár drobností. Zvážíme ten nejtěžší případ.
Hodnocení architektury enterprise projektu
Typický projekt pro hodnocení je velký, starý enterprise projekt s mnoha problémy. Klient k nám přichází a žádá nás, abychom opravili jeho projekt. Je to jako s ledovcem; klient vidí jen vrchol svých problémů a netuší, co je pod vodou (v hloubce kódu).
Problémy, na které si může klient stěžovat a o kterých může vědět:
- Problémy s výkonem
- Problémy s použitelností aplikace (Usability)
- Dlouhá doba nasazení
- Nedostatek unit a dalších testů
Problémy, o kterých klient pravděpodobně nemá tušení, ale mohou být přítomny v projektu:
- Problémy se zabezpečením
- Problémy návrhu
- Nesprávná architektura
- Algoritmické chyby
- Nevhodné technologie
- Technický dluh
- Nesprávný proces vývoje
Formální proces hodnocení architektury
To je formální proces, kterého se držíme ve firmě, ale můžete si ho přizpůsobit podle své firmy a projektu.
Žádost od klienta
Klient žádá o zhodnocení architektury současného projektu. Odpovědná osoba z naší strany shromažďuje základní informace o projektu a vybírá potřebné experty. V závislosti na projektu to mohou být různí experti.
Solution Architect – hlavní osoba zodpovědná za hodnocení a koordinaci (a často jediná).
Stack specific experts – .Net, Java, Python a další technické specialisté v závislosti na projektu a technologiích.
Cloud experts – mohou to být architekti pro Azure, GCP nebo AWS.
Infrastructure – DevOps, systémový administrátor atd.
Další experti – jako jsou big data, machine learning, performance engineer, security expert, QA lead.
Sběr informací o projektu
Měli byste shromáždit co nejvíce informací o projektu. Můžete použít různé techniky v závislosti na situaci:
- Dotazníky a další způsoby komunikace přes e-mail. Nejnižší efektivita.
- Online setkání.
- Speciální nástroje pro výměnu informací, jako jsou: Google doc, Confluence, repozitáře atd.
- „Živá“ setkání na místě. Nejefektivnější a nejdražší způsob.
Co všechno je třeba od klienta získat?
Základní informace. O čem projekt je. Jeho cíl a hodnota. Hlavní cíle a plány do budoucna. Obchodní cíle a strategie. Hlavní problémy a požadovaný výsledek.
Informace o projektu. Technologický stack, 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 aplikovány.
Nefunkční požadavky. Všechny požadavky spojené s výkonem, dostupností, použitelností systému. Požadavky na bezpečnost atd.
Základní use case a toky dat.
Přístup ke zdrojovému kódu. Nejdůležitější část! Určitě byste měli získat přístup k repozitářům a dokumentaci, jak sestavit projekt.
Přístup k infrastruktuře. Bylo by dobré získat přístup k stage nebo produkční infrastruktuře, abyste mohli pracovat se „živým“ systémem. Je to velké štěstí, pokud má klient nástroje pro monitorování infrastruktury a výkonu. O těchto nástrojích budeme mluvit v následující sekci.
Dokumentace. Pokud má klient nějakou dokumentaci, je to dobrý začátek. Může být zastaralá, ale to je stále dobrý začátek. Nikdy nevěřte dokumentaci – ověřte ji s klientem, na skutečné infrastruktuře a v zdrojovém kódu.
Proces hodnocení architektury
Jak se vypořádat s tak velkým množstvím informací za tak krátkou dobu? Především paralelizujte práci.
DevOps by měl pohlédnout do infrastruktury. Tech lead do kódu. Výkonový inženýr se podívá na metriky výkonnosti. Datový specialisté by měli hlouběji prozkoumat datové struktury.
Ale to je ideální případ, kdy máte hodně zdrojů. Obvykle hodnocení projektu provádí od jednoho do tří lidí. Můžete si dokonce hodnocení provést sami, což se často stává, pokud máte potřebné znalosti a zkušenosti ve všech oblastech projektu. V takovém případě musíte automatizovat všechny procesy, jak jen to je možné.
Bohužel, číst dokumentaci budete muset ručně. S adekvátními zkušenostmi jste schopni docela rychle pochopit kvalitu dokumentace. Co je pravda a co očividně neodpovídá skutečnosti. Někdy můžete v dokumentaci narazit na architekturu, která v reálném životě nikdy nebude fungovat. To je pro vás signál zamyslet se, jak to bylo ve skutečnosti provedeno v projektu.
Užitečné nástroje pro automatizaci hodnocení projektu
Hodnocení kódu je jednoduché cvičení. Můžete použít statické analyzátory kódu, které ukážou problémy s designem, výkonem a bezpečností. 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, je dobře ceněný, ale můžete vyzkoušet 30denní zkušební verzi.
je osvědčený a oblíbený nástroj. Nástroj pro statickou analýzu kódu. Umožňuje identifikovat špatný kód, chyby a bezpečnostní problémy pro více než 20 programovacích jazyků.
Všichni cloudoví poskytovatelé mají nástroje pro monitorování infrastruktury. To vám umožní správně vyhodnotit efektivitu infrastruktury z hlediska nákladů a výkonu. Pro AWS je to . Pro Azure je to jednoduše .
Další monitorování výkonu a logování pomůže odhalit problémy s výkonem na všech úrovních. Od databáze s neefektivními dotazy po backend až po frontend. I když klient tyto nástroje dříve nenainstaloval, můžete je poměrně rychle integrovat do stávajícího systému, abyste zjistili problémy s výkonem.
Jak už to bývá, kvalitní nástroje mají svou cenu. Mohu doporučit několik placených nástrojů. Samozřejmě, že můžete použít open-source, ale to vám zabere více času. A to by se mělo udělat předem, nikoli v průběhu hodnocení architektury.
nástroj pro hodnocení výkonu aplikací
cloudová služba pro monitorování systémů
Pro testování bezpečnosti existuje mnoho nástrojů. Tentokrát doporučím zdarma nástroj pro skenování systému.
nástroj pro skenování webových aplikací na dodržování bezpečnostních standardů.
Sbíráme vše do jednoho celku.
Připravujeme zprávu
Začněte svou zprávu se shromážděnými daty od klienta. Popište cíle projektu, omezení, nefunkční požadavky. Poté byste měli zmínit všechny vstupní data, zdrojový kód, dokumentaci a infrastrukturu.
Další krok. Uveďte všechny problémy, které jste našli ručně nebo pomocí automatizovaných nástrojů. Velké automaticky generované zprávy umístěte na konec do sekce příloh. Zde by měly být krátké a výstižné důkazy o nalezených problémech.
Prioritizujte nalezené problémy podle stupnice error, warning, info. Můžete si zvolit svou škálu, ale tato je obecně uznávaná.
Jako skutečný architekt máte povinnost poskytnout doporučení k odstranění nalezených problémů. Popište vylepšení a hodnotu pro podnikání, kterou získá klient. Jak ukázat hodnotu pro podnikání od o kterém jsme hovořili dříve.
Připravte roadmapu s malými iteracemi. Každá iterace by měla obsahovat čas na provedení, popis, potřebný počet zdrojů pro zlepšení, technickou hodnotu a hodnotu pro podnikání.
Dokončujeme hodnocení architektury a předáváme klientovi zprávu.
Nikdy zprávu pouze neodesílejte e-mailem. Mohou ji buď vůbec nečíst, nebo číst a nepochopit bez příslušného vysvětlení. Stručně řečeno - osobní komunikace pomáhá eliminovat nedorozumění mezi lidmi. Měli byste si domluvit schůzku s klientem a informovat jej o nalezených problémech se zaměřením na ty nejvýznamnější. Stojí za to upozornit klienta na problémy, o kterých mohl ani nevědět. Jako jsou problémy s bezpečností a vysvětlit, jak mohou ovlivnit podnikání. Ukažte svou roadmapu s vylepšeními a projednejte různé alternativy, které více vyhovují klientovi. Může to být čas, zdroje, objem prací.
Jak vyhodnocení vaší schůzky pošlete klientovi svou zprávu.
Na závěr
Hodnocení architektury je složitý proces. Abyste mohli provést hodnocení správně, musíte mít dostatečné zkušenosti a znalosti.
Je to reálné - poskytnout klientovi užitečné výsledky pro něj a jeho podnik za pouhý týden. I když to děláte sami.
Na základě mých zkušeností mnoho vylepšení bylo přerušeno v polovině, nebo se někdy vůbec nezačalo. Ti, kdo si zvolili zlatou střední cestu a provedli pouze část vylepšení, která byla maximalizovaně užitečná pro podnikání s minimálním pracovním úsilím, podstatně zlepšili kvalitu svého produktu. Ti, kdo nic nedělali, mohli za pár let projekt zcela uzavřít.
Vaším cílem je ukázat klientovi maximální zlepšení za minimální cenu.
Další články v sekci si můžete přečíst ve volném čase.
Přeji vám čistý kód a dobrá architektonická řešení.
Naše facebooková skupina — .
Zdroj: habr.com
