Alustades on alati raske mĂ”ista suurt ja vanamat projekti. Architecture assessment on ĂŒks arhitekti tegevustest. Tavaliselt tuleb töötada suurte, vanade projektidega ja tulemused tuleb esitada nĂ€dala jooksul.
Kuidas hinnata projekti, mille koodiridade arv on 100 000 vÔi rohkem, nÀdala jooksul ning anda klientidele tÔeliselt kasulikud tulemused.
Enamik arhitekte ja tehnilisi juhte on sarnaste projektihinnangutega kokku puutunud. See vÔib tunduda poolt formaalse protsessina vÔi kui eraldi teenus, nagu meie ettevÔttes, kuid igal juhul on enamik teist sellega kokku puutunud.
Originaal inglise keeles teie mitte venekeelsetele sÔpradele on siin: .
Meie ettevÔtte lÀhenemine
RÀÀgin teile, kuidas see meie ettevÔttes töötab ja kuidas ma sellistes olukordades toimin, kuid saate seda lÀhenemist kergesti kohandada vastavalt oma projekti ja ettevÔtte vajadustele.
Architecture assessment on kahte liiki.
Sisemine â me tavaliselt teeme selle ettevĂ”tte siseselt. Igal projektil vĂ”ib olla mitu pĂ”hjust arhitektuuri hindamiseks:
- Meeskond arvab, et nende projekt on ideaalne ja see on kahtlane. Meil on olnud selliseid juhtumeid ja sageli pole sellistes projektides kÔik kaugeltki ideaalne.
- Meeskond soovib oma projekti ja lahenduste ĂŒle kontrolli teha.
- Meeskond teab, et kÔik on halvasti. Nad vÔivad isegi loetleda peamised probleemid ja pÔhjused, kuid soovivad saada tÀielikku probleemide loetelu ja soovitusi projekti parandamiseks.
VĂ€line â see on formaalsem protsess kui sisemine hindamine. Klient tuleb tavaliselt ainult siis, kui kĂ”ik on halvasti - vĂ€ga halvasti. Tavaliselt mĂ”istab klient, et on suuremad probleemid, kuid ei suuda Ă”igesti mÀÀratleda pĂ”hjuseid ja neid komponentideks jagada.
Arhitektuuri hindamine vĂ€listelt klientidelt on keerulisem juhtum. Protsess peab olema formaalsem. Projektid on alati suured ja vanad. Neis on palju probleeme, vigu ja vale koodi. Tehtud töö aruanne peaks olema valmis mĂ”ne nĂ€dala jooksul, kus peaksid olema peamised probleemid ja soovitused parandamiseks. Seega, kui saame vĂ€lise projekti hindamisega hakkama, siis seesmine on vaid paar tĂŒhja asja. Vaatame kĂ”ige keerulisemat juhtumit.
Enterprise projekti arhitektuuri hindamine
TĂŒĂŒpiline projekti hindamine on suur, vana, ettevĂ”tte projekt, millel on palju probleeme. Klient tuleb meie juurde ja palub oma projekti parandada. See on nagu jÀÀberg, klient nĂ€eb ainult oma probleemide tippu ja ei aimagi, mis on vee all (koodi sĂŒgavuses).
Probleemid, mille ĂŒle klient vĂ”ib kaevata ja millest ta vĂ”ib teadlik olla:
- SooritusvÔimeprobleemid
- Rakenduse kasutatavuse probleemid
- Pikaajaline juurutamine
- Ăksuse ja teiste testide puudumine
Probleemid, millest klient tÔenÀoliselt ei tea, kuid mis vÔivad projektis esineda:
- Turbeprobleemid
- Projekteerimise probleemid
- Vale arhitektuur
- Algoritmilised vead
- Sobimatud tehnoloogiad
- Tehniline vÔlg
- Vale arendusprotsess
Ainult formaalne arhitektuuri hindamise protsess
See on ametlik protsess, millest meie ettevÔttes kinni peame, kuid vÔite seda vastavalt oma ettevÔtte ja projekti vajadustele kohandada.
Kliendi pÀring
Klient palub hinnata kÀesoleva projekti arhitektuuri. Meie poolt vastutav isik kogub projekti kohta pÔhiinfot ja otsib vajalikud eksperdid. SÔltuvalt projektist vÔivad need olla erinevad eksperdid.
Lahenduse arhitekt â peamine isik, kes vastutab hindamise ja koordineerimise eest (ja sageli ainus).
Spetsiifilised eksperdid â .Net, Java, Python ja muud tehnilised spetsialistid sĂ”ltuvalt projektist ja tehnoloogiatest
Pilve eksperdid â need vĂ”ivad olla Azure, GCP vĂ”i AWS pilvearhitektid.
Infrastuktuur â DevOps, sĂŒsteemiadministraator jne.
Teised eksperdid â nagu suurandmed, masinĂ”pe, sooritusinsener, turvaekspert, QA juht.
Projekti info kogumine
Te peaksite koguma vÔimalikult palju info projekti kohta. VÔite kasutada erinevaid tehnikaid sÔltuvalt olukorrast:
- KĂŒsimustikud ja muud suhtlemisviisid e-posti kaudu. KĂ”ige ebaefektiivsem viis.
- Veebikohtumid.
- Eri tööriistad info jagamiseks, nagu: Google doc, Confluence, reposiit jne.
- "Elavad" kohtumised kohapeal. KÔige efektiivsem ja samas kÔige kallim viis.
Mida tuleb kliendilt saada?
PĂ”hiinfo. Millest projekt rÀÀgib. Selle eesmĂ€rk ja vÀÀrtus. PĂ”hi eesmĂ€rgid ja tuleviku plaanid. Ări eesmĂ€rgid ja strateegiad. Peamised probleemid ja soovitud tulemus.
Teave projekti kohta. Tehnoloogia virn, raamistikud, programmeerimiskeeled. On-premise vÔi pilvel pÔhine paigaldamine. Kui projekt asub pilves, milliseid teenuseid kasutatakse. Milliseid arhitektuuri- ja disainimustreid on rakendatud.
Mittefunktsionaalsed nĂ”uded. KĂ”ik nĂ”uded, mis on seotud sĂŒsteemi jĂ”udluse, kĂ€ttesaadavuse, kasutusmugavuse jne. TurvanĂ”uded jms.
PÔhijuhud ja andmevood.
JuurdepÀÀs lÀhtekoodile. KÔige olulisem osa! Teil on kindlasti vaja juurdepÀÀsu repositooriumidele ja dokumentatsioonile, kuidas projekt kokku panna.
JuurdepÀÀs infrastruktuurile. Oleks hea saada juurdepÀÀs lavastus- vĂ”i tootmisinfrastruktuurile, et töötada "elava" sĂŒsteemiga. Suur Ă”nn, kui kliendil on infrastruktuuri ja jĂ”udluse jĂ€lgimise tööriistad. Nendest tööriistadest rÀÀgime jĂ€rgmises osas.
Dokumentatsioon. Kui kliendil on dokumentatsioon, on see hea algus. See vĂ”ib olla aegunud, kuid see on ikkagi hea algus. Ăra kunagi usu dokumentatsiooni â kontrolli seda kliendi, tegeliku infrastruktuuri ja lĂ€htekoodiga.
Arhitektuuri hindamise protsess
Kuidas siiski töödelda nii suurt hulka teavet nii lĂŒhikese ajaga? Esiteks paralleelige tööd.
DevOps vaatab infrastruktuuri. Tehniline juht vaatab koodi. JĂ”udluse insener vaatab jĂ”udlusnĂ€itajaid. Andmebaasi spetsialist peaks sĂŒgavamale laskuma andmestruktuuridesse.
Kuid see on ideaalne juhtum, kui teil on palju ressursse. Tavaliselt teostab projekti hindamist ĂŒks kuni kolm inimest. Te vĂ”ite isegi ise hindamise lĂ€bi viia, mis sageli juhtub, kui teil on vajalikud teadmised ja kogemused kĂ”igis projekti valdkondades. Sel juhul peate automatiseerima kĂ”ik protsessid, kuivĂ”rd see on vĂ”imalik.
Kahjuks peate dokumentatsiooni lugema kÀsitsi. Olles piisavalt kogenud, suudate piisavalt kiiresti mÔista dokumentatsiooni kvaliteeti. Mis on tÔsi ja mis selgelt ei vasta tegelikkusele. MÔnikord vÔite dokumendis kohata sellist arhitektuuri, mis ei toimi kunagi reaalses elus. See on tÔuge, et mÔelda, kuidas see tegelikult projektis tehtud on.
Kasulikud tööriistad projekti hindamise automatiseerimiseks
Koodi hindamine on lihtne praktika. Saate kasutada staatilisi koodi analĂŒsaatorite, mis nĂ€itavad disaini, jĂ”udluse ja turvalisuse probleeme. Siin on mĂ”ned neist:
on suurepĂ€rane tööriist arhitektidele. See nĂ€itab teile ĂŒldpilti, sĂ”ltuvust moodulite vahel ja potentsiaalseid refaktooringu kohti. Nagu kĂ”ik head tööriistad, maksab see palju, kuid samal ajal vĂ”ite kasutada tasuta 30-pĂ€evast versiooni.
on vana hea tööriist. See on staatilise koodi analĂŒĂŒsi tööriist. See vĂ”imaldab tuvastada halba koodi, vigu ja turvalisuse probleeme enam kui 20 programmeerimiskeeles.
KÔigil pilveteenuse pakkujatel on infrastruktuuri jÀlgimise tööriistad. Need aitavad hinnata infrastruktuuri efektiivsust kulude ja jÔudluse vaatenurgast. AWS-i puhul on see . Azure puhul on see lihtsalt .
TĂ€iendav jĂ”udluse jĂ€lgimine ja logimine aitab leida jĂ”udlusprobleeme kĂ”igil tasanditel. Alates andmebaasist, kus on ebaefektiivsed pĂ€ringud, tagaplaanist kuni esiplaanini. Isegi kui klient ei ole neid tööriistu varem installinud, saate need olemasolevasse sĂŒsteemi ĂŒsna kiiresti integreerida, et tuvastada jĂ”udlusprobleeme.
Kuidas alati, head tööriistad maksavad hÀsti. Soovitan paar tasulist tööriista. Loomulikult saate kasutada avatud lÀhtekoodiga lahendusi, kuid see nÔuab rohkem aega. Ja see tuleks teha ette, mitte arhitektuuri hindamise kÀigus.
on rakenduste jÔudluse hindamise tööriist
on pilveteenuse sĂŒsteemide jĂ€lgimise teenus
Turvalisuse testimiseks on palju tööriistu. Sel korral soovitan teile tasuta sĂŒsteemi skaneerimise tööriista.
on veebirakenduste skaneerimise tööriist vastavuse tagamiseks turvastandarditele.
Kogume kÔik kokku.
Valmistame aruande
Alustage oma aruannet kliendilt kogutud andmetega. Kirjeldage projekti eesmÀrke, piiranguid ja mittefunktsionaalseid nÔudeid. SeejÀrel tuleks mainida kÔiki sisenevaid andmeid, lÀhtekoodi, dokumentatsiooni, infrastruktuuri.
JĂ€rgmine samm. MÀÀrake kĂ”ik kĂ€sitsi vĂ”i automatiseeritud tööriistadega leitud probleemid. Suured automaatselt genereeritud raportid paigutage lĂ”ppu lisadetekti sektsiooni. Siin peaksid olema lĂŒhikesed ja sisukad tĂ”endid leitud probleemide kohta.
Prioriseerige leitud probleemid error, warning, info skaalas. Saate valida oma skaalat, kuid see on ĂŒldiselt aktsepteeritud.
TÔelise arhitektina olete kohustatud andma soovitusi leitud probleemide lahendamiseks. Kirjeldage parendusi ja ÀÀrmiselt vÀÀrtust, mida klient saab. Kuidas nÀidata ÀÀrmist vÀÀrtust ettevÔttele mida arutasime varem.
Valmistage ette tegevuskava vÀikeste iteratsioonidega. Iga iteratsioon peaks sisaldama tÀitmise aega, kirjeldust, vajalikku resurssi parendamiseks, tehnilist vÀÀrtust ja ÀÀrmist vÀÀrtust.
LÔpetame arhitektuuri hindamise ja esitame kliendile aruande.
Ărge kunagi saatke raportit lihtsalt e-posti teel. Seda vĂ”ib kas mitte lugeda vĂ”i lugeda ja mitte mĂ”ista ilma piisava selgituseta. LĂŒhidalt â elav suhtlemine aitab vĂ€ltida arusaamatusi inimeste vahel. Peaksite mÀÀrama koosoleku kliendiga ja rÀÀkima leitud probleemidest, rĂ”hutades kĂ”ige olulisemaid. Tuleks pöörata kliendi tĂ€helepanu probleemidele, millest ta vĂ”ib isegi mitte teadlik olla. NĂ€iteks turvaprobleemid ja selgitada, kuidas need vĂ”ivad Ă€ri mĂ”jutada. NĂ€idake oma tegevuskava parendustega ja arutage erinevaid variatsioone, mis sobivad kliendile. See vĂ”ib hĂ”lmata aega, ressursse, töömahtu.
Muutke oma koosoleku kokkuvÔttena kliendile oma raport.
KokkuvÔtteks
Arhitektuuri hindamine on keeruline protsess. Et hinnata seda Ôigesti, peate olema piisavalt kogenud ja teadlik.
See on tĂ”eliselt vĂ”imalik â anda kliendile kasulikke tulemusi ainult ĂŒhe nĂ€dalaga. Isegi kui teete seda ĂŒksi.
Minu kogemuste pÔhjal peatusid paljud parendused keset teed, mÔne puhul ei alustatud kunagi. Need, kes valisid enda jaoks kuldse kesktee ja tegid vaid osalisi parendusi, mis olid Àri jaoks maksimaalselt kasulikud minimaalsete tööjÔududega, parandasid oma toodete kvaliteeti oluliselt. Need, kes ei teinud midagi, vÔisid paari aasta pÀrast projekti lÔpetada.
Teie eesmÀrk on nÀidata kliendile maksimaalseid parandusi minimaalse hinna eest.
Teised artiklid jaotises vÔib lugeda vabast ajast.
Soovin teile puhtaid koode ja hÀid arhitektuurilisi lahendusi.
Meie Facebooki grupp â .
Allikas: habr.com
