Kezdetben mindig nehéz megérteni egy nagy és régi projektet. Az építészet az építész értékelés egyik tevékenysége. Általában nagy, régi projektekkel kell dolgozni, és az eredményeket egy héten belül meg kell adni.
Hogyan lehet értékelni egy hét alatt 100 XNUMX vagy több sornyi kódot tartalmazó projektet, miközben az ügyfél számára valóban hasznos eredményeket biztosít.
A legtöbb építész és műszaki vezető találkozott már hasonló projektértékeléssel. Ez félig formális folyamatnak vagy külön szolgáltatásnak tűnhet, ahogyan cégünknél is történik, így vagy úgy a legtöbben foglalkoztak ezzel.
Az eredeti angol nyelvű nem oroszul beszélő barátaid számára itt található: .
Cégünk megközelítése
Elmondom, hogyan működik ez a cégünkben, és én hogyan járok el hasonló helyzetekben, de ezt a megközelítést könnyedén megváltoztathatja projektje és cége igényei szerint.
Kétféle építészeti értékelés létezik.
belső – általában cégen belüli projekteknél csináljuk. Bármely projekt több okból is kérhet architektúra értékelést:
- A csapat szerint a projekt tökéletes, és ez gyanús. Voltak ilyen eseteink, és gyakran az ilyen projektekben minden messze van az ideálistól.
- A csapat szeretné tesztelni projektjét és megoldásait.
- A csapat tudja, hogy a dolgok rosszak. Még a főbb problémákat és okokat is felsorolhatják, de teljes listát szeretnének a problémákról és a projekt javítására vonatkozó javaslatokról.
Külső formálisabb folyamat, mint egy belső értékelés. Az ügyfél mindig csak egy esetben jön, amikor minden rossz - nagyon rossz. Általában az ügyfél megérti, hogy globális problémákról van szó, de nem tudja helyesen azonosítani az okokat és részekre bontani.
Egy külső kliens architektúrájának kiértékelése bonyolultabb eset. A folyamatnak formálisabbnak kell lennie. A projektek mindig nagyok és régiek. Rengeteg probléma, hiba és ferde kód van bennük. Az elvégzett munkáról szóló jelentésnek maximum néhány héten belül el kell készülnie, amely tartalmazza a főbb problémákat és a javítási javaslatokat. Ezért, ha a projekt külső értékelésével foglalkozunk, akkor a belső értékelés egy szelet torta lesz. Nézzük a legnehezebb esetet.
Vállalati projekt architektúra értékelése
Egy tipikus értékelendő projekt egy nagy, régi, nagyvállalati projekt, sok problémával. Egy ügyfél odajön hozzánk, és megkér minket, hogy javítsuk ki a projektjét. Olyan ez, mint egy jéghegynél, az ügyfél csak a problémáinak csúcsát látja, és fogalma sincs, mi van a víz alatt (a kód mélyén).
Problémák, amelyekre az ügyfél panaszkodhat, és amelyekről tudatában lehet:
- Teljesítménybeli problémák
- Használhatósági problémák
- Hosszú távú telepítés
- Az egység és egyéb vizsgálatok 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
- Rossz architektúra
- Algoritmikus hibák
- Nem megfelelő technológiák
- Technikai tartozás
- Rossz fejlesztési folyamat
Formális architektúra felülvizsgálati folyamat
Ez egy formális folyamat, amelyet cégként követünk, de cégétől és projektjétől függően személyre szabhatja.
Ügyfél kérése
Az ügyfél kéri, hogy értékelje az aktuális projekt architektúráját. Oldalunkon a felelős személy összegyűjti a projekttel kapcsolatos alapvető információkat és kiválasztja a szükséges szakértőket. A projekttől függően ezek különböző szakértők lehetnek.
Megoldás építész – az értékelésért és koordinációért felelős fő személy (és gyakran az egyetlen).
Verem konkrét szakértők – .Net, Java, Python és egyéb műszaki szakemberek a projekttől és a technológiáktól függően
Felhőszakértők – ezek lehetnek Azure, GCP vagy AWS felhő építészek.
Infrastruktúra – DevOps, rendszergazda stb.
Más szakértők – például big data, gépi tanulás, teljesítménymérnök, biztonsági szakértő, minőségbiztosítási vezető.
Információgyűjtés a projektről
A lehető legtöbb információt össze kell gyűjtenie a projektről. A helyzettől függően különböző technikákat használhat:
- Kérdőívek és egyéb kommunikációs módok levélben. A leghatékonyabb módszer.
- Online találkozók.
- Speciális eszközök az információcseréhez, mint például: Google doc, Confluence, adattárak stb.
- „Élő” találkozók a helyszínen. A leghatékonyabb és legdrágább módszer.
Mit kell kapnia az ügyféltől?
Alapinformációk. Miről szól a projekt? Célja és értéke. Főbb célok és tervek a jövőre nézve. Üzleti célok és stratégiák. Fő problémák és a kívánt eredmények.
Projekt információk. Technológiai verem, keretrendszerek, programozási nyelvek. Helyszíni vagy felhőalapú telepítés. Ha a projekt a felhőben van, milyen szolgáltatásokat használnak. Milyen építészeti és tervezési mintákat használtak.
Nem funkcionális követelmények. A rendszer teljesítményével, elérhetőségével és egyszerű használatával kapcsolatos összes követelmény. Biztonsági követelmények stb.
Alapvető használati esetek és adatfolyamok.
Hozzáférés a forráskódhoz. A legfontosabb rész! Mindenképpen hozzá kell férnie a tárolókhoz és a projekt felépítésének dokumentációjához.
Hozzáférés az infrastruktúrához. Jó lenne hozzáférni a színpadhoz vagy a produkciós infrastruktúrához az élő rendszerrel való együttműködéshez. Nagy siker, ha az ügyfél rendelkezik eszközökkel az infrastruktúra és a teljesítmény monitorozására. Ezekről az eszközökről a következő részben fogunk beszélni.
dokumentáció. Ha az ügyfél rendelkezik dokumentációval, ez egy jó kezdet. Lehet, hogy elavult, de még mindig jó kezdet. Soha ne bízzon a dokumentációban – tesztelje az ügyféllel, valós infrastruktúrán és a forráskódban.
Az építészet értékelési folyamata
Hogyan lehet ilyen nagy mennyiségű információt feldolgozni ilyen rövid idő alatt? Mindenekelőtt párhuzamosítsa a munkát.
A DevOpsnak meg kell vizsgálnia az infrastruktúrát. Tech vezet a kódba. Teljesítménymérnök a teljesítménymutatók megtekintéséhez. Az adatbázis-szakértőnek mélyebbre kell ásnia az adatstruktúrákat.
De ez egy ideális eset, ha sok erőforrással rendelkezik. Általában egy-három ember értékel egy projektet. Akár maga is elkészítheti a becslést, ami gyakran megtörténik, ha rendelkezik megfelelő tudással és tapasztalattal a projekt minden területén. Ebben az esetben minden folyamatot a lehető legnagyobb mértékben automatizálnia kell.
Sajnos manuálisan kell elolvasnia a dokumentációt. A megfelelő mennyiségű tapasztalat birtokában gyorsan megértheti a dokumentáció minőségét. Mi igaz és mi egyértelműen nem esik egybe a valósággal. Néha olyan építészetet láthat a dokumentációban, amely soha nem fog működni a való életben. Ez arra készteti, hogy elgondolkozzon azon, hogyan valósult meg a valóságban a projektben.
Hasznos eszközök a projektértékelés automatizálásához
A kód kiértékelése egy egyszerű gyakorlat. Használhat statikus kódelemzőket, amelyek megmutatják a tervezési, teljesítménybeli és biztonsági problémákat. Íme néhány közülük:
nagyszerű eszköz egy építész számára. Megmutatja az átfogó képet, a modulok közötti függőséget és az átalakítás lehetséges területeit. Mint minden jó eszköz, ez is jó pénzbe kerül, de kihasználhatja a 30 napos próbaverziót.
- egy jó öreg szerszám. Statikus kódelemzés eszköze. Lehetővé teszi a hibás kódok, hibák és biztonsági problémák azonosítását több mint 20 programozási nyelv esetében.
Minden felhőszolgáltató rendelkezik infrastruktúra-figyelő eszközökkel. Ez lehetővé teszi, hogy megfelelően értékelje infrastruktúrája hatékonyságát a költségek és a teljesítmény tekintetében. Az AWS esetében ez . Az Azure számára egyszerű .
A további teljesítményfigyelés és naplózás minden szinten segít megtalálni a teljesítményproblémákat. Kezdve egy nem hatékony lekérdezésekkel rendelkező adatbázistól a háttérrendszerig és a frontend-ig. Még akkor is, ha az ügyfél korábban nem telepítette ezeket az eszközöket, meglehetősen gyorsan integrálhatja őket a meglévő rendszerbe a teljesítménybeli problémák azonosítása érdekében.
Mint mindig, a jó eszközök megérik az árát. Tudok ajánlani pár fizetős eszközt. Természetesen használhat nyílt forráskódot is, de ez több időt vesz igénybe. Ezt pedig előre kell megtenni, nem pedig az építészeti értékelési folyamat során.
– az alkalmazás teljesítményének értékelésére szolgáló eszköz
– felhőrendszer-felügyeleti szolgáltatás
Számos eszköz áll rendelkezésre a biztonsági teszteléshez. Ezúttal egy ingyenes rendszerellenőrző eszközt ajánlok Önnek.
– webes alkalmazások szkennelésére szolgáló eszköz a biztonsági szabványoknak való megfelelés érdekében.
Tegyünk mindent egy egésszé.
Jelentés készítése
Kezdje jelentését az ügyféltől gyűjtött adatokkal. Ismertesse a projekt céljait, korlátait, nem funkcionális követelményeit. Ezek után minden bemeneti adatot meg kell említeni: forráskód, dokumentáció, infrastruktúra.
Következő lépés. Sorolja fel a kézzel vagy automatizált eszközökkel talált problémákat. Helyezzen el nagy, automatikusan generált jelentéseket az alkalmazások rész végén. A talált problémákról rövid és tömör bizonyítékot kell adni.
A hiba, figyelmeztetés, információs skálán talált problémákat rangsorolja. Kiválaszthatja saját skáláját, de ez az általánosan elfogadott.
Igazi építészként az Ön felelőssége, hogy ajánlásokat adjon a talált problémák megoldására. Ismertesse a fejlesztéseket és az üzleti értéket, amelyet az ügyfél kap. Hogyan mutatjuk meg az üzleti értéket korábban megbeszéltük.
Készítsen ütemtervet kis iterációkkal. Minden iterációnak tartalmaznia kell a befejezéshez szükséges időt, leírást, a fejlesztéshez szükséges erőforrások mennyiségét, a műszaki értéket és az üzleti értéket.
Elvégezzük az építészeti felmérést, és jelentést készítünk az ügyfélnek
Soha ne csak postán küldjön jelentést. Előfordulhat, hogy egyáltalán nem olvasható, vagy megfelelő magyarázat nélkül nem olvasható és érthető. Röviden, az élő kommunikáció segít kiküszöbölni az emberek közötti félreértéseket. Egyeztessen egy találkozót az ügyféllel, és beszéljen a talált problémákról, a legjelentősebbekre összpontosítva. Érdemes felhívni a kliens figyelmét olyan problémákra, amelyekről esetleg nem is tud. Ilyen például a biztonsági kérdések, és magyarázza el, hogyan befolyásolhatják az üzletet. Mutassa be az ütemtervet a fejlesztésekkel, és beszéljen meg különböző lehetőségeket, amelyek jobban megfelelnek az ügyfélnek. Ez lehet idő, erőforrás, munka mennyisége.
A találkozó összefoglalójaként küldje el jelentését az ügyfélnek.
Összefoglalva
Az építészet értékelése összetett folyamat. Az értékelés megfelelő elvégzéséhez elegendő tapasztalattal és tudással kell rendelkeznie.
Lehetőség van arra, hogy az ügyfél számára és vállalkozása számára hasznos eredményeket nyújtson egy hét alatt. Még akkor is, ha egyedül csinálod.
Tapasztalataim alapján sok fejlesztést a közepén töltöttek le, és néha el sem indultak. Azok, akik az arany középutat választották maguknak, és a vállalkozás számára leghasznosabb fejlesztéseknek csak egy részét hajtották végre minimális munkaerőköltséggel, jelentősen javították termékük minőségét. Azok, akik nem csináltak semmit, néhány év után teljesen bezárhatják a projektet.
Az Ön célja, hogy minimális áron maximális fejlesztéseket mutasson az ügyfélnek.
További cikkek a rovatból szabadidődben olvashatsz.
Tiszta kódot és jó építészeti döntéseket kívánok.
Facebook csoportunk - .
Forrás: will.com