Na začiatku sa vždy ťažko zorientovať vo veľkom a starom projekte. Hodnotenie architektúry je jedna z aktivít architekta. Zvyčajne sa musí pracovať s veľkými, starými projektmi a výsledky je potrebné poskytnúť do týždňa.
Ako ohodnotiť projekt s viac ako 100 000 riadkami kódu za týždeň a pritom poskytnúť naozaj užitočné výsledky pre klienta.
Väčšina architektov a technických lídrov sa stretla s podobnými požiadavkami na hodnotenie projektu. Môže to vyzerať ako poloformálny proces alebo ako samostatná služba, ako sa to robí v našej spoločnosti, tak či onak, väčšina z vás s tým už mala dočinenia.
Originál v anglickom jazyku pre vašich nehovoriacich ruský priateľov nájdete tu: .
Prístup v našej spoločnosti
Poviem vám, ako to funguje u nás a ako sa správať v podobných situáciách, ale môžete si tento prístup ľahko prispôsobiť potrebám vášho projektu a spoločnosti.
Existujú dva typy hodnotenia architektúry.
Interné – zvyčajne ho robíme pre projekty v rámci spoločnosti. Akýkoľvek projekt môže požiadať o hodnotenie architektúry z niekoľkých dôvodov:
- Tím si myslí, že ich projekt je dokonalý, čo je podozrivé. Mali sme také prípady a často je v takých projektoch situácia veľmi neuspokojivá.
- Tím chce skontrolovať svoj projekt a svoje rozhodnutia.
- Tím vie, že je všetko zlé. Môžu dokonca vymenovať základné problémy a príčiny, ale chcú získať úplný zoznam problémov a odporúčaní na zlepšenie projektu.
Externé – je to formálnejší proces než interné hodnotenie. Klient prichádza vždy len v jednom prípade, keď je všetko zlé – veľmi zlé. Zvyčajne si klient uvedomuje, že existujú globálne problémy, ale nemôže správne určiť príčiny a rozdeliť ich na jednotlivé časti.
Hodnotenie architektúry pre externého klienta je komplikovanejší prípad. Proces musí byť formálnejší. Projekty sú vždy veľké a staré. Obsahujú veľa problémov, chýb a neprehľadného kódu. Správa o vykonanej práci by mala byť pripravená do niekoľkých týždňov maximálne, kde by mali byť uvedené hlavné problémy a odporúčania na zlepšenie. Preto, ak sa dostaneme k externému hodnoteniu projektu, potom interné bude pár maličkostí. Pozrime sa na najkomplikovanejší prípad.
Hodnotenie architektúry enterprise projektu
Typický projekt na hodnotenie je veľký, starý enterprise projekt s množstvom problémov. Klient k nám prichádza s požiadavkou opraviť jeho projekt. Je to ako s ľadovým vrchom, klient vidí len vrchol svojich problémov a netuší, čo je pod vodou (v hĺbke kódu).
Problémy, na ktoré sa klient môže sťažovať a o ktorých môže vedieť:
- Problémy s výkonom
- Problémy s použiteľnosťou aplikácie (Usability)
- Dlhé nasadzovanie
- Nedostatok unit a iných testov
Problémy, o ktorých klient pravdepodobne netuší, ale môžu sa v projekte nachádzať:
- Problémy s bezpečnosťou
- Problémy s dizajnom
- Nesprávna architektúra
- Algoritmické chyby
- Nevhodné technológie
- Technický dlh
- Nesprávny proces vývoja
Formálny proces hodnotenia architektúry
Je to formálny proces, ktorého sa držíme v našej spoločnosti, ale môžete ho prispôsobiť podľa svojich potrieb v závislosti od vašej spoločnosti a projektu.
Žiadosť od klienta
Klient žiada o hodnotenie architektúry súčasného projektu. Zodpovedná osoba z našej strany zhromažďuje základné informácie o projekte a vyberá potrebných expertov. V závislosti od projektu to môžu byť rôzni experti.
Architekt riešenia – hlavnú osobu zodpovednú za hodnotenie a koordináciu (a často aj jedinú).
Odborníci v rámci stacku – .Net, Java, Python a ďalší technickí odborníci v závislosti od projektu a technológií.
Cloud odborníci – to môžu byť architekti cloudu Azure, GCP alebo AWS.
Infrastruktúra – DevOps, systémový administrátor atď.
Ďalší odborníci – ako napríklad big data, machine learning, performance engineer, security expert, QA lead.
Zhromažďovanie informácií o projekte
Mali by ste zhromaždiť čo najviac informácií o projekte. Môžete použiť rôzne techniky v závislosti od situácie:
- Dotazníky a iné spôsoby komunikácie prostredníctvom e-mailu. Najmenej efektívny spôsob.
- Online stretnutia.
- Špeciálne nástroje na výmenu informácií ako: Google doc, Confluence, repozitáre atď.
- „Živé“ stretnutia na mieste. Najefektívnejší a najdrahší spôsob.
Čo je potrebné získať od klienta?
Základné informácie. O čom projekt je. Jeho cieľ a hodnota. Hlavné ciele a plány do budúcnosti. Obchodné ciele a stratégie. Hlavné problémy a želaný výsledok.
Informácie o projekte. Technologický stack, rámce, programovací jazyky. On-premise alebo cloudový deployment. Ak je projekt v cloude, aké služby sa používajú. Aké architektonické a dizajnové vzory sa použili.
Nefunkčné požiadavky. Všetky požiadavky súvisiace s výkonnosťou, dostupnosťou, použiteľnosťou systému. Požiadavky na bezpečnosť atď.
Základné use case a toky údajov.
Prístup k zdrojovému kódu. Najdôležitejšia časť! Určite by ste mali získať prístup k repozitárom a dokumentácii, ako zostaviť projekt.
Prístup k infraštruktúre. Bolo by dobré získať prístup k stage alebo produkčnej infraštruktúre, aby ste pracovali s „živým“ systémom. Je to veľká výhra, ak má klient nástroje na sledovanie infraštruktúry a výkonnosti. O týchto nástrojoch si povieme v nasledujúcej sekcii.
Dokumentácia. Ak má klient dokumentáciu, je to dobrý začiatok. Môže byť zastaraná, ale stále je to dobrý začiatok. Nikdy neverte dokumentácii – overte ju s klientom, na reálnej infraštruktúre a v zdrojovom kóde.
Proces hodnotenia architektúry
Ako spracovať také obrovské množstvo informácií za tak krátky čas? Predovšetkým paralelizujte prácu.
DevOps by sa mal pozrieť na infraštruktúru. Tech lead do kódu. Výkonový inžinier by mal skontrolovať metriky výkonnosti. Špecialista na databázy by mal hlbšie preskúmať štruktúru údajov.
Ale to je ideálny prípad, keď máte veľa zdrojov. Zvyčajne hodnotenie projektu vykonáva od jedného do troch ľudí. Môžete dokonca vykonať hodnotenie sami, čo sa často stáva, ak máte potrebné znalosti a skúsenosti vo všetkých oblastiach projektu. V takom prípade by ste mali automatizovať všetky procesy, ako len to je možné.
Žiaľ, prečítať dokumentáciu si budete musieť manuálne. Pri dostatočnej skúsenosti môžete pomerne rýchlo pochopiť kvalitu dokumentácie. Čo tam je pravda a čo jasne nezodpovedá realite. Niekedy sa môžete stretnúť s architektúrou v dokumentácii, ktorá nikdy nebude fungovať v reálnom živote. To je spúšť, aby ste sa zamysleli, ako to vlastne funguje v projekte.
Užitočné nástroje na automatizáciu hodnotenia projektu
Hodnotenie kódu je jednoduché cvičenie. Môžete použiť statické analyzátory kódu, ktoré odhalia problémy s dizajnom, výkonom a bezpečnosťou. Tu je niekoľko z nich:
je skvelý nástroj pre architektov. Ukáže vám celkový obraz, závislosti medzi modulmi a potenciálne oblasti na refaktoring. Ako všetky dobré nástroje, aj on stojí veľa peňazí, ale môžete využiť 30-dňovú skúšobnú verziu.
je starý dobrý nástroj. Nástroj na statickú analýzu kódu. Umožňuje identifikovať zlý kód, chyby a problémy so zabezpečením pre viac ako 20 programovacích jazykov.
Všetci poskytovatelia cloudových služieb majú nástroje na monitorovanie infraštruktúry. To vám umožní správne posúdiť účinnosť infraštruktúry z hľadiska nákladov a výkonu. Pre AWS je to . Pre Azure je to jednoducho .
Ďalšie monitorovanie výkonu a logovanie pomôže nájsť problémy s výkonom na všetkých úrovniach. Od databázy s neefektívnymi dotazmi, backendu, až po frontend. Aj keď si klient tieto nástroje predtým nenainštaloval, môžete ich pomerne rýchlo integrovať do existujúceho systému, aby ste identifikovali problémy s výkonom.
Ako vždy, dobré nástroje majú svoju cenu. Môžem odporučiť niekoľko platených nástrojov. Samozrejme, môžete použiť open-source, ale potrvá to viac času. A to by sa malo urobiť vopred, a nie počas hodnotenia architektúry.
nástroj na hodnotenie výkonu aplikácií
je cloudová služba na monitorovanie systémov
Na testovanie bezpečnosti existuje množstvo nástrojov. Tentoraz odporúčam bezplatný nástroj na skenovanie systému.
je nástroj na skenovanie webových aplikácií na súlad so štandardmi zabezpečenia.
Zbierame všetko do jedného celku.
Pripravujeme správu
Začnite svoju správu so zozbieranými údajmi od klienta. Opíšte ciele projektu, obmedzenia, nefunkčné požiadavky. Potom by ste mali spomenúť všetky vstupné dáta - zdrojový kód, dokumentáciu, infraštruktúru.
Nasledujúci krok. Uveďte všetky problémy, ktoré ste našli manuálne alebo pomocou automatizovaných nástrojov. Veľké automaticky generované správy umiestnite na koniec do sekcie príloh. Tu by mali byť krátke a výstižné dôkazy o nájdených problémoch.
Prioritizujte nájdené problémy podľa hodnotenia: error, warning, info. Môžete zvoliť svoju škálu, ale táto je vo všeobecnosti akceptovaná.
Ako skutočný architekt ste povinný poskytnúť odporúčania na odstránenie nájdených problémov. Opíšte vylepšenia a hodnotu pre podnik, ktorú získa klient. Ako ukázať hodnotu pre podnik od o ktorých sme diskutovali skôr.
Pripravte roadmapu s malými iteráciami. Každá iterácia by mala obsahovať čas na vykonanie, popis, množstvo zdrojov potrebných na vylepšenie, technickú hodnotu a hodnotu pre podnik.
Ukončujeme hodnotenie architektúry a poskytujeme klientovi správu.
Nikdy len tak nezasielajte správu e-mailom. Môžu ju buď vôbec neprečítať, alebo ju prečítať a nepochopiť bez riadneho vysvetlenia. Skrátka – osobná komunikácia pomáha eliminovať nedorozumenia medzi ľuďmi. Mali by ste si dohodnúť stretnutie s klientom a povedať mu o nájdených problémoch, pričom zdôraznite najdôležitejšie. Je potrebné upozorniť klienta na problémy, o ktorých mohol ani len netušiť. Napríklad problémy so zabezpečením a vysvetliť, ako môžu ovplyvniť podnik. Ukážte svoju roadmapu s vylepšeniami a prediskutujte rôzne možnosti, ktoré sú pre klienta vhodnejšie. Môže ísť o čas, zdroje, objem práce.
Na konci vášho stretnutia pošlite klientovi vašu správu.
Na záver
Hodnotenie architektúry je zložitý proces. Aby ste vykonali hodnotenie riadne, potrebujete mať dostatok skúseností a znalostí.
Je reálne poskytnúť klientovi výsledky, ktoré sú pre neho a jeho podnik užitočné, už za týždeň. Aj keď to robíte sami.
Na základe mojich skúseností sa mnohé vylepšenia zastavovali v polovici, a niekedy ani nezačali. Tí, ktorí si vybrali zlatú strednú cestu a robili len časť vylepšení maximálne prospešných pre podnik s minimálnymi pracovnými nákladmi, výrazne zlepšili kvalitu svojho produktu. Tí, ktorí nič nerobili, mohli po pár rokoch úplne uzavrieť projekt.
Vaším cieľom je ukázať zákazníkovi maximálne zlepšenia za minimálnu cenu.
Iné články v sekcii môžete si prečítať vo voľnom čase.
Prajem vám čistý kód a dobré architektonické riešenia.
Naša facebooková skupina — .
Zdroj: habr.com
