Kezdetben mindig nehéz eligazodni egy nagy és régi projektben. Az architecture assessment az egyik tevékenység, amit az építész végez. Általában nagy, régi projektekkel kell dolgozni, és az eredményeket egy héten belül be kell mutatni.
Hogyan lehet 100 ezer és annál több soros kódú projektet egy hét alatt értékelni, miközben valóban hasznos eredményeket kell biztosítani az ügyfél számára?
A legtöbb építész és technikai vezető hasonló projektértékelésekkel találkozott. Ez félformális folyamatnak tűnhet, vagy külön szolgáltatásként, ahogy azt a mi cégünkben tesszük; így vagy úgy, a legtöbben már foglalkoztak ezzel.
Az angol nyelvű eredeti itt található a nem orosz ajkú barátainak: .
Megközelítés a mi cégünknél
Elmondom, hogyan működik ez nálunk, és hogyan járok el az ilyen helyzetekben, de könnyedén módosíthatod ezt a megközelítést a projekted és céged igényei szerint.
Kétféle architecture assessment létezik.
Belső – ezt általában a cégen belüli projektek számára végezzük. Bármelyik projekt kérheti az architektúra értékelését különböző okok miatt:
- A csapat azt hiszi, hogy a projektjük tökéletes, és ez gyanús. Volt már ilyen eset, és gyakran az ilyen projektekben messze nem minden tökéletes.
- A csapat szeretné ellenőrizni a projektet és saját megoldásaikat.
- A csapat tudja, hogy minden rossz. Lehet, hogy még fel is tudják sorolni a főbb problémákat és okokat, de szeretnék megkapni a problémák teljes listáját és a projekt javítására tett ajánlásokat.
Külső – ez formálisabb folyamat, mint a belső értékelés. Az ügyfél mindig egyetlen esetben érkezik, amikor minden rosszul van – nagyon rosszul. Az ügyfél általában érti, hogy globális problémák vannak, de nem tudja pontosan meghatározni az okokat és részekre bontani őket.
A külső ügyfél számára végzett architektúra értékelése bonyolultabb eset. A folyamatnak formálisabbnak kell lennie. A projektek mindig nagyok és régiek. Sok probléma, hiba és rossz kód található bennük. A elvégzett munka jelentését néhány héten belül el kell készíteni, amelyben a főbb problémák és javítási ajánlások szerepelnek. Ezért, ha megbirkózunk a projekt külső értékelésével, akkor a belső folyamat csak apróság lesz. Vegyünk egy bonyolultabb esetet.
Az architektúra értékelése egy enterprise projektnél
A típikus projektértékelés egy nagy, régi, vállalati projekt, sok problémával. Az ügyfél hozzánk fordul és kéri, hogy javítsuk meg a projektjét. Olyan ez, mint egy jéghegy, az ügyfél csak a problémáinak a csúcsát látja, és nem sejt arról, ami a víz alatt (a kód mélyén) van.
Problémák, amelyekre az ügyfél panaszkodhat és tudhat róluk:
- Teljesítményproblémák
- Alkalmazás használhatóságával kapcsolatos problémák
- Hosszú telepítési időszakok
- Egység- és egyéb tesztek hiánya
Problémák, amelyekről az ügyfél valószínűleg nem tud, de jelen lehetnek a projektben:
- Biztonsági problémák
- Tervezési problémák
- Hibás architektúra
- Algoritmikai hibák
- Megfelelő technológiák hiánya
- Technikai adósság
- Helytelen fejlesztési folyamat
Formális architektúraellenőrzési folyamat
Ez egy formális folyamat, amelyhez ragaszkodunk a vállalatunkban, de alakítható az önök cégére és projektjére szabva.
Kérés az ügyféltől
Az ügyfél kéri az aktuális projekt architektúrájának értékelését. A felelős személy tőlünk összegyűjti a projekt alapinformációit és kiválasztja a szükséges szakértőket. A projekt függvényében ezek különböző szakértők lehetnek.
Megoldásarchitektúra – a fő személy, aki felelős az értékelésért és a koordinálásért (és sokszor az egyetlen).
Stack-specifikus szakértők – .Net, Java, Python és más technikai szakértők, a projekt és technológiák alapján.
Felhőszakértők – ide tartozhatnak Azure, GCP vagy AWS felhőarchitektek.
Infrastruktúra – DevOps, rendszergazda stb.
Egyéb szakértők – mint például big data, gépi tanulás, teljesítménymérnök, biztonsági szakértő, QA vezető.
Információgyűjtés a projektről
Minél több információt kell gyűjtenie a projektről. Különböző technikákat használhat a helyzet függvényében:
- Kérdőívek és más levelezési módszerek. A legkevésbé hatékony módszer.
- Online találkozók.
- Speciális információcserélő eszközök, mint például: Google doc, Confluence, repozitóriumok stb.
- "Élő" találkozók a helyszínen. A legkevésbé hatékony és legdrágább módszer.
Mit kellene kérni az ügyféltől?
Alapinformáció. Miről szól a projekt. Célja és értéke. Fő célok és jövőbeli tervek. Üzleti célok és stratégiák. Fő problémák és kívánt eredmény.
Információ a projektről. Technológiai stack, keretrendszerek, programozási nyelvek. On-premise vagy felhőalapú telepítés. Ha a projekt felhőben van, mely szolgáltatásokat használják? Milyen architektúra és dizájnminták alkalmazása történt?
Nem funkcionális követelmények. Minden követelmény, amely a rendszer teljesítményével, elérhetőségével és felhasználói élményével kapcsolatos. A biztonsági követelmények stb.
Alapvető use case-ek és adatfolyamok.
Hozzáférés a forráskódhoz. Ez a legfontosabb rész! Feltétlenül hozzá kell férni a tárolókhoz és a dokumentációhoz, hogy összegyűjtsük a projektet.
Hozzáférés az infrastruktúrához. Jó lenne hozzáférni a staging vagy production infrastruktúrához, hogy dolgozhassunk egy „éles” rendszeren. Nagy szerencse, ha az ügyfél rendelkezik infrastruktúra- és teljesítménymonitorozó eszközökkel. Ezekről az eszközökről a következő szakaszban beszélünk.
kódkönyvtárra lépésével érheti el.. Ha az ügyfélnek van dokumentációja, az jó kezdet. Lehet, hogy elavult, de akkor is jó kezdet. Soha ne bízz a dokumentációban – ellenőrizd az ügyféllel, a valós infrastruktúrával és a forráskóddal.
Az architektúra értékelési folyamata
Hogyan dolgozhatunk fel ennyi információt ilyen rövid idő alatt? Először is párhuzamosítsd a munkát.
A DevOps-nak érdemes megnéznie az infrastruktúrát. A technikai vezető a kódba. A teljesítménymérnök megtekinti a teljesítménymutatókat. Az adatbázis-specialistának érdemes mélyebben felfedeznie az adatszerkezeteket.
De ez az ideális állapot, amikor sok erőforrásunk van. Általában a projekt értékelését 1-3 fő végzi. Meg is végezheted az értékelést magad is, ami gyakran előfordul, ha megfelelő tudásod és tapasztalatod van a projekt minden területén. Ilyen esetben az összes folyamatot automatizálnod kell, amennyire csak lehetséges.
Sajnos a dokumentációt manuálisan kell elolvasnod. A megfelelő tapasztalattal viszonylag gyorsan megértheted a dokumentáció minőségét. Mi az igaz, és mi az, ami nyilvánvalóan nem felel meg a valóságnak. Néha előfordulhat, hogy a dokumentációban olyan architektúrát találsz, ami soha nem fog működni a valós életben. Ez arra késztet, hogy elgondolkodj, hogyan van ez valóságbeli megvalósítás a projektben.
Hasznos eszközök a projekt értékelésének automatizálásához
A kód értékelése egy egyszerű gyakorlat. Használhat statikus kódelemző eszközöket, amelyek felfedik a tervezési, teljesítményi és biztonsági problémákat. Íme néhány közülük:
– nagyszerű eszköz az architektek számára. Megmutatja az egész képet, a modulok közötti függőségeket és a potenciális refaktorálási területeket. Mint minden jó szerszám, ennek is van ára, de 30 napos próbaidőszakot is igénybe vehet.
– a régi jó eszköz. Statikus kódelemző eszköz, amely lehetővé teszi a rossz kód, hibák és biztonsági problémák azonosítását több mint 20 programozási nyelven.
Minden felhőszolgáltató rendelkezik infrastruktúra megfigyelő eszközökkel. Ez segít helyesen értékelni az infrastruktúra hatékonyságát költség és teljesítmény szempontjából. Az AWS esetében ez a . Az Azure esetén egyszerűen ez a .
További teljesítményellenőrzés és naplózás segíthet a teljesítményproblémák azonosításában minden szinten. Kezdve az adatbázisoktól, amelyek nem hatékony lekérdezéseket használnak, a háttérszolgáltatásokig és a frontendig. Még ha az ügyfél ezeket az eszközöket nem telepítette korábban, viszonylag gyorsan integrálni tudja őket a meglévő rendszerbe a teljesítményproblémák azonosítása érdekében.
Mint mindig, a jó eszközöknek megvan az áruk. Javasolhatok néhány fizetős eszközt. Persze használhat nyílt forráskódú szoftvereket, de ezekhez több időt kell áldoznia. Ezért ezt előre kell elvégezni, nem az architektúra értékelése közben.
– alkalmazás teljesítményének értékelése
– rendszerfigyelő felhőszolgáltatás
A biztonsági teszteléshez számos eszköz áll rendelkezésre. Ezúttal egy ingyenes rendszerszkennert ajánlok.
– a webalkalmazások biztonsági szabványoknak való megfelelésének ellenőrzésére szolgáló eszköz.
Összeállítjuk az egészet.
Elkészítjük a jelentést
Kezdje a jelentését az ügyféltől beszerzett adatokkal. Írja le a projekt céljait, a korlátozásokat és a nem funkcionális követelményeket. Ezt követően említse meg az összes bemeneti adatot: forráskód, dokumentáció, infrastruktúra.
Következő lépés. Jelölje meg az összes problémát, amelyet manuálisan vagy automatizált eszközökkel talált. A nagy, automatikusan generált jelentéseket helyezze a végére az alkalmazások szekcióban. Itt kell lennie rövid és tömör bizonyítékoknak a talált problémákról.
Prioritizálja a talált problémákat error, warning, info skála szerint. Kiválaszthatja a saját skáláját, de ez az általánosan elfogadott.
Igazi építészként kötelezettsége, hogy ajánlásokat adjon a talált problémák megoldására. Ismertesse a javasolt fejlesztéseket és azokat az üzleti értékeket, amelyeket az ügyfél kap. Hogyan lehet bemutatni az üzleti értéket a korábban már megbeszéltük.
Készítsen egy ütemtervet kis iterációkkal. Minden iterációnak tartalmaznia kell a végrehajtási időt, a leírást, a szükséges erőforrások mennyiségét a fejlesztéshez, a műszaki értéket és az üzleti értéket.
Befejezzük az architektúra értékelését, és elküldjük az ügyfélnek a jelentést.
Soha ne küldje el csak úgy e-mailben a jelentést. Lehet, hogy el sem olvassák, vagy elolvassák, de nem értik meg megfelelő magyarázat nélkül. Röviden – a személyes kommunikáció segít eloszlatni a félreértéseket az emberek között. Időpontot kell egyeztetnie az ügyféllel, és beszélnie kell a talált problémákról, a legfontosabbakra fókuszálva. Érdemes felhívni az ügyfél figyelmét olyan problémákra, amelyekről talán nem is tudott, mint például a biztonsági problémák, és megmagyarázni, hogyan befolyásolhatják a vállalkozását. Mutassa be az ütemtervét a fejlesztésekkel, és beszélje meg a különböző, az ügyfél számára megfelelő lehetőségeket. Ez lehet idő, erőforrások, a munkamennyiség.
A találkozója összegzéseként küldje el az ügyfélnek a jelentését.
Végül
Az architektúra értékelése összetett folyamat. Ahhoz, hogy megfelelően elvégezze az értékelést, elegendő tapasztalattal és tudással kell rendelkeznie.
Ez valóban lehetséges – az ügyfélnek hasznos eredményeket nyújtani már egy hét alatt. Még akkor is, ha ezt egyedül teszi.
Tapasztalatom szerint sok fejlesztés a közepén leállt, vagy néha soha nem is kezdődött el. Akik a középutat választották, és csak a legmagasabb üzleti hasznot biztosító fejlesztéseket hajtották végre minimális munkaigénnyel, jelentősen javították termékük minőségét. Akik viszont semmit nem tettek, pár év múlva akár be is zárhatták a projektet.
Célja, hogy a lehető legtöbb fejlődést mutassa be az ügyfélnek a lehető legkisebb áron.
Egyéb cikkek a szekcióból elolvasható szabadidőben.
Tiszta kódot és jó architekturális megoldásokat kívánok Önnek.
Facebook csoportunk — .
Forrás: habr.com
