Yn it begjin is it altyd lestich om in grut en âld projekt te begripen. Arsjitektuer is ien fan 'e aktiviteiten fan in arsjitektevaluaasje. Meastentiids moatte jo wurkje mei grutte, âlde projekten, en de resultaten moatte yn in wike levere wurde.
Hoe kinne jo in projekt fan 100k of mear rigels koade yn in wike evaluearje, wylst jo noch resultaten leverje dy't wirklik nuttich binne foar de klant.
De measte arsjitekten en technyske leads hawwe ferlykbere projektbeoardielingen tsjinkaam. Dit kin lykje op in semy-formele proses of as in aparte tsjinst sa't wurdt dien yn ús bedriuw, ien of oare wize de measten fan jimme hawwe te krijen mei dit.
It orizjineel yn it Ingelsk foar jo net-Russysktalige freonen is hjir: .
Us bedriuw syn oanpak
Ik sil jo fertelle hoe't it wurket yn ús bedriuw en hoe't ik hannelje yn ferlykbere situaasjes, mar jo kinne dizze oanpak maklik feroarje neffens de behoeften fan jo projekt en bedriuw.
D'r binne twa soarten beoardieling fan arsjitektuer.
Binnenkant - wy dogge it meastentiids foar projekten binnen it bedriuw. Elk projekt kin om ferskate redenen in arsjitektuerevaluaasje oanfreegje:
- It team tinkt dat har projekt perfekt is en dit is fertocht. Wy hawwe sokke gefallen hân, en faak is yn sokke projekten alles fier fan ideaal.
- It team wol har projekt en har oplossingen testen.
- It team wit dat dingen min binne. Se kinne sels de wichtichste problemen en oarsaken opskriuwe, mar wolle in folsleine list fan problemen en oanbefellings foar it ferbetterjen fan it projekt.
Ekstern is in formeler proses dan in ynterne beoardieling. De kliïnt komt altyd mar yn ien gefal, as alles min is - heul min. Gewoanlik begrypt de klant dat d'r wrâldwide problemen binne, mar kin de oarsaken net korrekt identifisearje en se yn komponinten brekke.
Evaluearjen fan in arsjitektuer foar in eksterne klant is in komplekser gefal. It proses moat formeler wêze. De projekten binne altyd grut en âld. Se hawwe in protte problemen, bugs en kromme koade. In rapport oer it dien wurk moat binnen in pear wiken maksimaal klear wêze, dat moat befetsje de wichtichste problemen en oanbefellings foar ferbettering. Dêrom, as wy te meitsjen hawwe mei de eksterne beoardieling fan it projekt, dan sil de ynterne beoardieling in stik koeke wêze. Litte wy it dreechste gefal beskôgje.
Enterprise projekt arsjitektuer beoardieling
In typysk projekt om te evaluearjen is in grut, âld, bedriuwsprojekt mei in protte problemen. In klant komt nei ús en freget ús om syn projekt te reparearjen. It is as mei in iisberch, de kliïnt sjocht allinich de tip fan syn problemen en hat gjin idee wat der ûnder it wetter is (yn 'e djipten fan' e koade).
Problemen dêr't de klant kin kleie oer en kin wêze bewust fan:
- Performance Issues
- Usability problemen
- Lange termyn ynset
- Gebrek oan ienheid en oare tests
Problemen dêr't de klant nei alle gedachten net bewust fan is, mar se kinne oanwêzich wêze yn it projekt:
- Feiligensproblemen
- Design problemen
- Ferkearde arsjitektuer
- Algoritmyske flaters
- Unappropriate technologyen
- Technyske skuld
- Ferkearde ûntwikkelingsproses
Formele arsjitektuer review proses
Dit is in formeel proses dat wy as bedriuw folgje, mar jo kinne it oanpasse ôfhinklik fan jo bedriuw en projekt.
Fersyk fan in klant
De opdrachtjouwer freget om de arsjitektuer fan it hjoeddeiske projekt te evaluearjen. De ferantwurdlike persoan oan ús kant sammelet basisynformaasje oer it projekt en selektearret de nedige saakkundigen. Ofhinklik fan it projekt kinne dit ferskate saakkundigen wêze.
Oplossingsarsjitekt - de haadpersoan ferantwurdlik foar beoardieling en koördinaasje (en faaks de ienige).
Stapel spesifike saakkundigen – .Net, Java, Python, en oare technyske spesjalisten ôfhinklik fan it projekt en technologyen
Wolken saakkundigen - dit kinne Azure, GCP of AWS wolk arsjitekten wêze.
ynfrastruktuer - DevOps, Systeembehearder, ensfh.
Oare saakkundigen - lykas grutte gegevens, masine learen, prestaasjesingenieur, feiligensekspert, QA-lead.
It sammeljen fan ynformaasje oer it projekt
Jo moatte safolle mooglik ynformaasje sammelje oer it projekt. Jo kinne ferskate techniken brûke ôfhinklik fan 'e situaasje:
- Fragelisten en oare metoaden fan kommunikaasje fia post. De meast ineffektive manier.
- Online gearkomsten.
- Spesjale ark foar útwikseling fan ynformaasje lykas: Google doc, Confluence, repositories, ensfh.
- "Live" gearkomsten op side. De meast effektive en djoerste manier.
Wat moatte jo krije fan de klant?
Basis ynformaasje. Wêr giet it projekt oer? Syn doel en wearde. Haaddoelen en plannen foar de takomst. Saaklike doelen en strategyen. Main problemen en winske resultaten.
Projekt ynformaasje. Technologystapel, kaders, programmeartalen. On-premise of cloud-ynset. As it projekt yn 'e wolk is, hokker tsjinsten wurde brûkt. Hokker arsjitektoanyske en ûntwerppatroanen waarden brûkt.
Non-funksjonele easken. Alle easken relatearre oan prestaasjes, beskikberens en it gemak fan gebrûk fan it systeem. Feiligens easken, ensfh.
Basisgebrûk en gegevensstreamen.
Tagong ta boarnekoade. It wichtichste diel! Jo moatte perfoarst tagong krije ta de repositories en dokumintaasje oer hoe't jo it projekt kinne bouwe.
Tagong ta ynfrastruktuer. It soe moai wêze om tagong te hawwen ta it poadium of produksjeynfrastruktuer om te wurkjen mei it live systeem. It is in grut súkses as de klant ark hat foar it kontrolearjen fan ynfrastruktuer en prestaasjes. Wy sille prate oer dizze ark yn 'e folgjende paragraaf.
Dokumintaasje. As de klant dokumintaasje hat, is dit in goed begjin. It kin ferâldere wêze, mar it is noch altyd in goed begjin. Fertrou de dokumintaasje noait - test it mei de klant, op echte ynfrastruktuer en yn 'e boarnekoade.
Arsjitektuer Evaluaasjeproses
Hoe kin men sa'n grutte hoemannichte ynformaasje yn sa'n koarte tiid ferwurkje? Earst fan alles, parallelisearje it wurk.
DevOps moat sjen nei de ynfrastruktuer. Tech lead yn 'e koade. Prestaasje-yngenieur om prestaasjesmetriken te besjen. In databankspesjalist moat djipper yn gegevensstruktueren grave.
Mar dit is in ideaal gefal as jo in protte middels hawwe. Typysk evaluearje ien oant trije minsken in projekt. Jo kinne sels de skatting útfiere, wat faaks it gefal is as jo de juste kennis en ûnderfining hawwe op alle gebieten fan it projekt. Yn dit gefal moatte jo alle prosessen safolle mooglik automatisearje.
Spitigernôch moatte jo de dokumintaasje manuell lêze. Mei de krekte hoemannichte ûnderfining kinne jo de kwaliteit fan 'e dokumintaasje fluch begripe. Wat wier is en wat dúdlik net oerienkomt mei de realiteit. Soms kinne jo arsjitektuer sjen yn dokumintaasje dy't noait yn it echte libben sil wurkje. Dit is in trigger foar jo om nei te tinken oer hoe't it yn 'e realiteit dien is yn it projekt.
Nuttige ark om projektevaluaasje te automatisearjen
Koade evaluaasje is in ienfâldige oefening. Jo kinne statyske koade-analyzers brûke dy't jo problemen mei ûntwerp, prestaasjes en feiligens sille sjen litte. Hjir binne in pear fan harren:
is in geweldich ark foar in arsjitekt. It sil jo it grutte byld sjen litte, ôfhinklikens tusken modules en potinsjele gebieten foar refactoring. Lykas alle goede ark kostet it goed jild, mar jo kinne profitearje fan in proefferzje fan 30 dagen.
- in goed âld ark. In ark foar statyske koade analyze. Hjirmei kinne jo minne koade, bugs en feiligensproblemen identifisearje foar mear dan 20 programmeartalen.
Alle wolkproviders hawwe ark foar tafersjoch fan ynfrastruktuer. Hjirmei kinne jo de effektiviteit fan jo ynfrastruktuer goed evaluearje yn termen fan kosten en prestaasjes. Foar AWS is dit . It is maklik foar Azure .
Oanfoljende prestaasjesmonitoring en logging sil helpe by it finen fan prestaasjesproblemen op alle nivo's. Begjinnend fan in databank mei yneffektive queries, de efterkant en einigje mei de frontend. Sels as de klant dizze ark net earder hat ynstalleare, kinne jo se frij fluch yntegrearje yn it besteande systeem om prestaasjesproblemen te identifisearjen.
Lykas altyd binne goede ark it wurdich wurdich. Ik kin in pear betelle ark oanbefelje. Fansels kinne jo iepen boarne brûke, mar it sil jo mear tiid nimme. En dit moat foarôf dien wurde, net tidens it proses foar arsjitektuerevaluaasje.
- in ark foar it beoardieljen fan prestaasjes fan applikaasjes
- wolksysteemmonitoringstsjinst
D'r binne in protte ark beskikber foar feiligenstesten. Dizze kear sil ik jo in fergese ark foar systeemscannen oanbefelje.
- in ark foar it scannen fan webapplikaasjes foar neilibjen fan feiligensnoarmen.
Litte wy alles byinoar sette yn ien gehiel.
It opstellen fan in rapport
Begjin jo rapport mei de gegevens dy't jo hawwe sammele fan 'e klant. Beskriuw de projektdoelen, beheiningen, net-funksjonele easken. Hjirnei moatte alle ynfiergegevens neamd wurde: boarnekoade, dokumintaasje, ynfrastruktuer.
Folgjende stap. List alle problemen dy't jo hân hawwe fûn of mei help fan automatisearre ark. Plak grutte automatysk oanmakke rapporten oan 'e ein yn' e applikaasje seksje. D'r moatte koart en koart bewiis wêze fan 'e fûne problemen.
Prioritearje de problemen fûn op 'e flater, warskôging, info skaal. Jo kinne jo eigen skaal kieze, mar dit is de algemien akseptearre.
As wirklike arsjitekt is it jo ferantwurdlikens om oanbefellings te jaan om de fûne problemen te korrigearjen. Beskriuw de ferbetteringen en saaklike wearde dy't de klant sil ûntfange. Hoe te sjen saaklike wearde út wy besprutsen earder.
Meitsje in roadmap mei lytse iteraasjes. Elke iteraasje moat tiid befetsje om te foltôgjen, beskriuwing, hoemannichte boarnen nedich foar ferbettering, technyske wearde en saaklike wearde.
Wy foltôgje de arsjitektuerevaluaasje en jouwe de klant in rapport
Nea gewoan in rapport maile. It kin hielendal net lêzen wurde, of miskien net lêzen en begrepen wurde sûnder goede útlis. Koartsein, live kommunikaasje helpt misferstannen tusken minsken te eliminearjen. Jo moatte in gearkomste mei de klant plannen en prate oer de fûne problemen, rjochte op de meast wichtige. It is it wurdich om de oandacht fan 'e kliïnt te tekenjen op problemen dy't hy miskien net iens bewust is. Lykas feiligensproblemen en ferklearje hoe't se ynfloed kinne op it bedriuw. Lit jo roadmap sjen mei ferbetteringen en beprate ferskate opsjes dy't geskikter binne foar de klant. Dit kin tiid, boarnen, hoemannichte wurk wêze.
As gearfetting fan jo gearkomste, stjoer jo rapport nei de klant.
Yn ôfsluting
Arsjitektuer evaluaasje is in kompleks proses. Om de beoardieling goed út te fieren moatte jo genôch ûnderfining en kennis hawwe.
It is mooglik om de klant te foarsjen resultaten nuttich foar him en syn bedriuw yn mar in wike. Sels as jo it allinich dogge.
Op grûn fan myn ûnderfining, in protte ferbetterings waarden ynladen yn 'e midden, en soms nea begûn. Dejingen dy't de gouden middele foar harsels keas en mar in part fan 'e ferbetterings makken dy't it meast nuttich wiene foar it bedriuw mei minimale arbeidskosten, ferbettere de kwaliteit fan har produkt signifikant. Wa't neat die, koe it projekt nei in pear jier hielendal slute.
Jo doel is om de klant maksimale ferbetteringen te sjen foar de minimale priis.
Oare artikels út 'e seksje kinne jo lêze op jo frije tiid.
Ik winskje jo skjinne koade en goede arsjitektoanyske besluten.
Us facebook groep - .
Boarne: www.habr.com