Kuidas lugeda ja parandada 100 000 rida koodi nädalaga

Algselt on alati raske mõista suurt ja vana projekti. Arhitektuuri hindamine on üks arhitekti tegevustest. Tavaliselt tuleb töötada suurte, vanade projektidega ning tulemused tuleb esitada nädalaga.

Kuidas hinnata 100 000 ja rohkem rida koodi nädalaga, pakkudes samas klientidele tõeliselt kasulikke tulemusi.

Enamik arhitekte ja tehnilisi juhte on kokku puutunud sarnaste projekti hindamistega. See võib tunduda poolformaalse protsessina või eraldi teenusena, nagu meie firmas, aga nii või teisiti on enamik teist sellega kokku puutunud.

Originaal inglise keeles teie mitte venekeelsetele sõpradele on siin: Architecture Assessment in a week.

Meie ettevõtte lähenemine

Ma räägin teiega, kuidas see meie ettevõttes töötab ja kuidas ma sellistes olukordades tegutsen, kuid saate seda lähenemist kergesti kohandada vastavalt oma projekti ja ettevõtte vajadustele.

On kaks tüüpi arhitektuuri hindamist.

Sise- – me teeme seda tavaliselt ettevõtte siseseks projektiks. Iga projekt võib taotleda arhitektuuri hindamist mitmel põhjusel:

1. Meeskond arvab, et nende projekt on ideaalne ja see on kahtlane. Oleme selliseid juhtumeid kogenud, ja tihti ei ole sellistes projektides kõik kaugel ideaalist.
2. Meeskond soovib oma projekti ja lahendusi kontrollida.
3. Meeskond teab, et asjad on halvad. Nad võivad isegi loetleda peamised probleemid ja põhjused, kuid soovivad saada täielikku probleemide loetelu ja soovitusi projekti parendamiseks.

Väline – see on formaalsem protsess kui sisehindamine. Klient tuleb alati ainult juhul, kui kõik on halvasti – väga halvasti. Tavaliselt mõistab klient, et on globaalprobleemid, kuid ei oska õigeid põhjuseid kindlaks teha ja neid lihtsustada.

Välise kliendi arhitektuuri hindamine on keerulisem juhtum. Protsess peab olema ametlikum. Projektid on alati suured ja vanad. Neis on palju probleeme, vigu ja katkis koodi. Tehtud töö raport peaks olema valmis paar nädalat hiljem maksimaalselt, kus peab olema esitatud peamised probleemid ja parandusettepanekud. Seetõttu, kui me saame välise projekti hindamisega hakkama, siis sisemine on vaid paar tühikut. Vaatame kõige keerulisemat juhtumit.

Ettevõtte projekti arhitektuuri hindamine

Tüüpiline projekt, mida hinnata, on suur, vana, ettevõtte projekt, millel on palju probleeme. Klient tuleb meie juurde ja palub oma projekti parandada. See on nagu jäämägi; klient näeb vaid oma probleemide tippe ja ei aimagi, mis on vee all (koodi sügavustes).

Probleemid, mille üle klient võib kaebada ja millest ta võib teadlik olla:

• Tõhususe probleemid
• Rakenduse kasutusmugavuse (usability) probleemid
• Pikad juurutamised
• Üksuse ja teiste testide puudumine

Probleemid, millest klient tõenäoliselt ei tea, kuid mis võivad projektis esineda:

• Turvaprobleemid
• Disainiprobleemid
• Vale arhitektuur
• Algoritmivead
• Sobimatud tehnoloogiad
• Tehniline võlg
• Vale arendusprotsess

Ajalooline arhitektuuri hindamise protsess

See on ametlik protsess, mida järgime ettevõttes, kuid saate seda kohandada vastavalt oma ettevõtte ja projekti vajadustele.

Kliendi päring

Klient palub hinnata praeguse projekti arhitektuuri. Meie poolt vastutav isik kogub projekti kohta põhiteavet ja otsib vajalikud eksperdid. Sõltuvalt projektist võivad need olla erinevad eksperdid.

Lahenduste arhitekt – peamine isik, kes on vastutav hindamise ja koordineerimise eest (ja sageli ainus).
Tehnoloogia-spetsiifilised eksperdid – .Net, Java, Python ja muud tehnilised spetsialistid sõltuvalt projektist ja tehnoloogiatest.
Pilveeksperdid – need võivad olla Azure, GCP või AWS pilvearhitektid.
Infrastruktuur – DevOps, süsteemiadministraator jne.
Muud eksperdid – näiteks suurandmete, masinõppe, jõudluse insenerid, turbeeksperdid, QA juhid.

Projekti teabe kogumine

Te peate koguma võimalikult palju teavet projekti kohta. Saate kasutada erinevaid tehnikaid sõltuvalt olukorrast:

• Küsimustikud ja muud suhtlusviisid e-posti kaudu. Kõige vähem efektiivne meetod.
• Veebikohtumid.
• Spetsiaalsed tööriistad teabe vahetamiseks, nagu: Google doc, Confluence, hoidlad jne.
• Füüsilised kohtumised. Kõige efektiivsem ja kallim meetod.

Mida tuleb kliendilt saada?

Põhiinfo. Millest projekt räägib. Selle eesmärk ja väärtus. Põhieesmärgid ja tulevikuplaanid. Ärieesmärgid ja strateegiad. Peamised probleemid ja soovitud tulemus.

Projektiteave. Tehnoloogiline tugi, raamistikud, programmeerimiskeeled. On-premise või pilve juurutamine. Kui projekt on pilves, siis milliseid teenuseid kasutatakse. Milliseid arhitektuuri ja disaini mustreid on rakendatud.

Mittefunktsionaalsed nõuded. Kõik nõuded, mis on seotud süsteemi jõudluse, kättesaadavuse, kasutusmugavuse. Turvanõuded jne.

Põhikasutuse juhtumid ja andmevood.

Ligipääs lähtekoodile. Peamine osa! Teil on kindlasti vajalik pääseda tagavarade ja dokumentatsiooni juurde, kuidas projekti koostada.

Pääs infrastruktuurile. Hea oleks saada ligipääs stage või production infrastruktuurile, et töötada "elava" süsteemiga. See on suur õnn, kui kliendil on infrastruktuuri ja jõudluse jälgimise tööriistu. Nendest tööriistadest räägime järgmises osas.

Dokumentatsioon. Kui kliendil on dokumentatsioon, siis on see hea algus. See võib olla aegunud, kuid siiski hea algus. Ärge uskuge kunagi dokumentatsioonile – kontrollige seda kliendi, reaalse infrastruktuuri ja lähtekoodi põhjal.

Arhitektuuri hindamise protsess

Kuidas töödelda nii suurt hulka teavet nii lühikese aja jooksul? Esiteks jagage töö paralleelselt.

DevOps peab vaatama infrastruktuuri. Tehniline juht vaatab koodi. Jõudluse insener peab vaatama jõudluse mõõdikuid. Andmebaasi spetsialist peaks sügavamalt uurima andmestruktuure.

Kuid see on ideaalne olukord, kui teil on palju ressursse. Tüüpiliselt teevad projekti hindamise üks kuni kolm inimest. Te saate isegi ise hindamise läbi viia, mis on sageli nii, kui teil on piisavalt teadmisi ja kogemusi kõigis projekti valdkondades. Sellisel juhul peate automatiseerima kõik protsessid nii palju, kui võimalik.

Kahjuks peate dokumentatsiooni lugema käsitsi. Kui teil on piisav kogemus, suudate üsna kiiresti mõista dokumentatsiooni kvaliteeti. Mis seal on tõsi ja mis selgelt ei vasta reaalsusele. Mõnikord võite dokumentatsioonis kohata arhitektuuri, mis ei toimi kunagi reaalses elus. See on teie jaoks signaal mõelda, kuidas see tegelikult projektis realiseeritud on.

Kasulikud tööriistad projekti hindamise automatiseerimiseks

Koodi hindamine on lihtne ülesanne. Te saate kasutada staatilisi koodi analüsaatoreid, mis näitavad disaini, jõudluse ja turvalisuse probleeme. Siin on mõned neist:

Structure 101 – see on suurepärane tööriist arhitektile. See näitab teile üldpilti, sõltuvust moodulite vahel ja potentsiaalseid ümberkujundamise kohti. Nagu kõik head tööriistad, maksab see ka korralikult, kuid samas saate kasutada 30-päevast prooviversiooni.

SonarQube – vana hea tööriist. Statistilise koodianalüüsi tööriist. See aitab tuvastada halba koodi, vigu ja turvaprogresse rohkem kui 20 programmeerimiskeele jaoks.

Kõigil pilveteenuse pakkujatel on infrastruktuuri jälgimise tööriistad. Need aitavad õigesti hinnata infrastruktuuri efektiivsust kulude ja jõudluse vaatenurgast. AWS-i puhul on see trusted advisor. Azure'i puhul on see lihtsalt Azure Advisor.

Lisajälgimise ja logimise abil saate leida jõudlusprobleeme kõikidel tasanditel. Alustades andmebaasist, kus on ebaefektiivsed päringud, tagumisest lõpust ja lõpetades esiosa. Isegi kui klient ei ole neid tööriistu varem installinud, saate neid olemasolevasse süsteemi üsna kiiresti integreerida, et tuvastada jõudlusprobleemid.

Nagu alati, head tööriistad maksavad hästi. Soovitan paar tasulist tööriista. Muidugi võite kasutada avatud lähtekoodi lahendusi, kuid nende kasutamiseks läheb rohkem aega. Ja see tuleb teha eelnevalt, mitte arhitektuuri hindamise protsessi käigus.

New Relic – rakenduste jõudluse hindamise tööriist
Datadog – pilvepõhine süsteemide monitooringuteenuse

Turvakatsete jaoks on palju tööriistu. Seekord soovitan teile tasuta süsteemi skannimistööriista.

OWASP ZAP – veebirakenduste skannimise tööriist turvastandardite mõistes.

Kogume kõik üheks.

Valmistame aruande

Alustage oma aruannet kogutud kliendiandmetest. Kirjeldage projekti eesmärke, piiranguid, mittefunktsionaalnõudeid. Seejärel tuleks mainida kõiki sisendeid, sealhulgas lähtekoodi, dokumentatsiooni ja infrastruktuuri.

Järgmine samm. Loetlege kõik probleemid, mille leidsite käsitsi või automaatsete tööriistade abil. Suured automaatselt genereeritud aruanded paigutage lõppu lisaossa. Siin peaksid olema lühikesed ja selged tõendid leitud probleemide kohta.
Prioriseerige leitud probleemid kategooriate järgi: viga, hoiatus, teave. Võite valida oma skaalal, kuid see on üldiselt aktsepteeritud.

Nagu ehtne arhitekt, olete kohustatud andma soovitusi leitud probleemide lahendamiseks. Kirjeldage parandusi ja väärtust, mida klient saab. Kuidas näidata äärmiselt väärtust arhitektuuri refaktooring millest me varem rääkisime.

Valmistage ette teekaart väikeetappidega. Iga etapp peaks sisaldama täitmiseks kuluvat aega, kirjeldust, vajalike ressursside hulka parandamiseks, tehnilist väärtust ja äriteenuse väärtust.

Kätkeme arhitektuuri hindamist ja esitame kliendile aruande.

Ärge saatke raportit lihtsalt e-postiga. Seda võidakse mitte lugeda või lugeda, kuid mitte õigesti mõista, ilma piisava selgituseta. Lühidalt – otsekontakt aitab vältida inimestega arusaamatusi. Te peaksite kliendiga kohtumise määrama ja rääkima avastatud probleemidest, pöörates tähelepanu kõige olulisematele. Tasub juhtida kliendi tähelepanu probleemidele, mille olemasolust ta võis isegi mitte aimata, näiteks turvaprobleemid ning selgitada, kuidas need võivad mõjutada tema ettevõtet. Näidake oma arengukaarti parendustest ja arutage erinevaid võimalusi, mis sobivad paremini kliendile. See võib olla seotud ajaga, ressurssidega, töö mahuga.

Kohtumise tulemuste kokkuvõtte tegemisel saatke kliendile oma raport.

Kokkuvõtteks

Arhitektuuri hindamine on keeruline protsess. Hindamise nõuetekohaseks teostamiseks on teil vaja piisavalt kogemusi ja teadmisi.

See on tõepoolest võimalik – pakkuda kliendile tema jaoks ja tema äri jaoks kasulikke tulemusi vaid nädalaga. Isegi kui teete seda üksi.

Minu kogemuse põhjal on paljusid täiustusi laaditud keset protsessi ja mõnikord isegi mitte alustades. Need, kes valisid kuldse kesktee ja tegid ainult neid täiustusi, mis olid äri jaoks maksimaalselt kasulikud minimaalse töökoormusega, parandasid oma toote kvaliteeti märkimisväärselt. Need, kes ei teinud midagi, võisid paar aastat hiljem projekti üldse sulgeda.

Teie eesmärk on näidata kliendile maksimaalseid täiustusi minimaalse hinna eest.

Muud artiklid jaotisest arhitektuur võib lugeda vabalt aega viites.

Soovin teile puhtaid koodiridade ja häid arhitektuurilisi lahendusi.

Meie Facebooki grupp — Tarkvara arhitektuur ja arendus.

Allikas: habr.com