Kā lasīt un salabot 100,000 XNUMX koda rindiņas nedēļā

Kā lasīt un salabot 100,000 XNUMX koda rindiņas nedēļā
Sākumā vienmēr ir grÅ«ti saprast lielu un vecu projektu. ArhitektÅ«ra ir viena no arhitekta vērtÄ“Å”anas aktivitātēm. Parasti jāstrādā ar lieliem, veciem projektiem, un rezultāti jāsniedz nedēļas laikā.

Kā nedēļas laikā novērtēt projektu, kurā ir 100 XNUMX vai vairāk koda rindiņu, vienlaikus nodroÅ”inot klientam patiesi noderÄ«gus rezultātus.

Lielākā daļa arhitektu un tehnisko vadÄ«tāju ir saskāruÅ”ies ar lÄ«dzÄ«giem projektu novērtējumiem. Tas var izskatÄ«ties kā daļēji formāls process vai kā atseviŔķs pakalpojums, kā tas tiek darÄ«ts mÅ«su uzņēmumā, tā vairums no jums ar to ir tikuÅ”i galā.

OriÄ£ināls angļu valodā jÅ«su draugiem, kas nerunā krieviski, ir Å”eit: ArhitektÅ«ras novērtējums pēc nedēļas.

Mūsu uzņēmuma pieeja

Es jums pastāstÄ«Å”u, kā tas darbojas mÅ«su uzņēmumā un kā es rÄ«kojos lÄ«dzÄ«gās situācijās, taču jÅ«s varat viegli mainÄ«t Å”o pieeju atbilstoÅ”i jÅ«su projekta un uzņēmuma vajadzÄ«bām.

Ir divu veidu arhitektūras novērtējums.

IekŔējs ā€“ parasti to darām projektiem uzņēmuma iekÅ”ienē. JebkurÅ” projekts var pieprasÄ«t arhitektÅ«ras novērtējumu vairāku iemeslu dēļ:

  1. Komanda uzskata, ka viņu projekts ir ideāls, un tas ir aizdomÄ«gi. Mums ir bijuÅ”i tādi gadÄ«jumi, un bieži Ŕādos projektos viss ir tālu no ideāla.
  2. Komanda vēlas pārbaudīt savu projektu un to risinājumus.
  3. Komanda zina, ka viss ir slikti. Viņi pat var uzskaitÄ«t galvenās problēmas un cēloņus, bet vēlas pilnÄ«gu problēmu sarakstu un ieteikumus projekta uzlaboÅ”anai.

Ārējais ir formālāks process nekā iekŔējais novērtējums. Klients vienmēr atnāk tikai vienā gadÄ«jumā, kad viss ir slikti ā€“ ļoti slikti. Parasti klients saprot, ka pastāv globālas problēmas, bet nevar pareizi noteikt cēloņus un sadalÄ«t tos komponentos.

Ārēja klienta arhitektÅ«ras novērtÄ“Å”ana ir sarežģītāks gadÄ«jums. Procesam vajadzētu bÅ«t formālākam. Projekti vienmēr ir lieli un veci. Viņiem ir daudz problēmu, kļūdu un greizs kods. Maksimāli dažu nedēļu laikā jāsagatavo atskaite par paveikto, kurā jāiekļauj galvenās problēmas un ieteikumi uzlabojumiem. LÄ«dz ar to, ja nodarbosimies ar projekta ārējo izvērtÄ“Å”anu, tad iekŔējais novērtējums bÅ«s kÅ«kas gabals. ApskatÄ«sim visgrÅ«tāko gadÄ«jumu.

Uzņēmuma projektu arhitektūras novērtējums

Tipisks vērtējams projekts ir liels, vecs, uzņēmuma projekts ar daudzām problēmām. Pie mums nāk klients un lūdz, lai mēs salabotu viņa projektu. Tas ir tāpat kā ar aisbergu, klients redz tikai savu problēmu galu un viņam nav ne jausmas, kas atrodas zem ūdens (koda dzīlēs).

Problēmas, par kurām klients var sūdzēties un kuras var zināt:

  • Veiktspējas problēmas
  • LietojamÄ«bas problēmas
  • Ilgtermiņa izvietoÅ”ana
  • VienÄ«bas un citu testu trÅ«kums

Problēmas, par kurām klients, visticamāk, nav zināms, bet tās var būt projektā:

  • DroŔības problēmas
  • Dizaina problēmas
  • Nepareiza arhitektÅ«ra
  • Algoritmiskās kļūdas
  • Nepiemērotas tehnoloÄ£ijas
  • Tehniskais parāds
  • Nepareizs izstrādes process

Formālais arhitektūras pārskatīŔanas process

Šis ir formāls process, ko mēs ievērojam kā uzņēmums, taču jūs varat to pielāgot atkarībā no jūsu uzņēmuma un projekta.

Pieprasījums no klienta

PasÅ«tÄ«tājs lÅ«dz izvērtēt esoŔā projekta arhitektÅ«ru. MÅ«su puses atbildÄ«gā persona apkopo pamatinformāciju par projektu un atlasa nepiecieÅ”amos ekspertus. AtkarÄ«bā no projekta tie var bÅ«t dažādi eksperti.

Risinājumu arhitekts ā€“ galvenā persona, kas atbild par novērtÄ“Å”anu un koordināciju (un bieži vien vienÄ«gā).
Stack konkrētus ekspertus ā€“ .Net, Java, Python un citi tehniskie speciālisti atkarÄ«bā no projekta un tehnoloÄ£ijām
Mākoņu eksperti ā€“ tie var bÅ«t Azure, GCP vai AWS mākoņa arhitekti.
Infrastruktūras - DevOps, sistēmas administrators utt.
Citi eksperti ā€“ piemēram, lielie dati, maŔīnmācÄ«Å”anās, veiktspējas inženieris, droŔības eksperts, kvalitātes nodroÅ”ināŔanas vadÄ«tājs.

Informācijas vākŔana par projektu

Jums vajadzētu savākt pēc iespējas vairāk informācijas par projektu. Atkarībā no situācijas varat izmantot dažādas metodes:

  • Anketas un citas saziņas metodes pa pastu. VisneefektÄ«vākais veids.
  • TieÅ”saistes tikÅ”anās.
  • Speciālie informācijas apmaiņas rÄ«ki, piemēram: Google doc, Confluence, krātuves utt.
  • ā€œTieÅ”raidesā€ tikÅ”anās uz vietas. VisefektÄ«vākais un dārgākais veids.

Kas jums jāsaņem no klienta?

Pamatinformācija. Par ko ir projekts? Tās mērķis un vērtība. Galvenie mērķi un nākotnes plāni. Biznesa mērķi un stratēģijas. Galvenās problēmas un vēlamie rezultāti.

Informācija par projektu. TehnoloÄ£iju kaudze, ietvari, programmÄ“Å”anas valodas. Vietējā vai mākoņa izvietoÅ”ana. Ja projekts ir mākonÄ«, kādi pakalpojumi tiek izmantoti. Kādi arhitektÅ«ras un dizaina modeļi tika izmantoti.

Nefunkcionālas prasÄ«bas. Visas prasÄ«bas, kas saistÄ«tas ar sistēmas veiktspēju, pieejamÄ«bu un lietoÅ”anas ērtumu. DroŔības prasÄ«bas utt.

Pamata lietoŔanas gadījumi un datu plūsmas.

Piekļuve avota kodam. Vissvarīgākā daļa! Jums noteikti vajadzētu piekļūt krātuvēm un dokumentācijai par to, kā izveidot projektu.

Piekļuve infrastruktÅ«rai. BÅ«tu jauki, ja bÅ«tu pieejama skatuve vai ražoÅ”anas infrastruktÅ«ra, lai strādātu ar tieÅ”raides sistēmu. Tas ir liels panākums, ja klienta rÄ«cÄ«bā ir rÄ«ki infrastruktÅ«ras un veiktspējas uzraudzÄ«bai. Par Å”iem rÄ«kiem mēs runāsim nākamajā sadaļā.

Š”Š¾ŠŗуŠ¼ŠµŠ½Ń‚Š°Ń†Šøя. Ja klientam ir dokumentācija, tas ir labs sākums. Tas var bÅ«t novecojis, taču tas joprojām ir labs sākums. Nekad neuzticieties dokumentācijai ā€” pārbaudiet to ar klientu, reālā infrastruktÅ«rā un pirmkodā.

ArhitektÅ«ras vērtÄ“Å”anas process

Kā var apstrādāt tik lielu informācijas apjomu tik īsā laikā? Pirmkārt, paralēli darbu.

DevOps vajadzētu apskatīt infrastruktūru. Tehniskais ievads kodā. Veiktspējas inženieris, lai skatītu veiktspējas rādītājus. Datu bāzes speciālistam vajadzētu iedziļināties datu struktūrās.

Bet tas ir ideāls gadÄ«jums, kad jums ir daudz lÄ«dzekļu. Parasti projektu novērtē viens lÄ«dz trÄ«s cilvēki. JÅ«s pat varat veikt tāmi pats, kas bieži vien notiek, ja jums ir atbilstoÅ”as ā€‹ā€‹zināŔanas un pieredze visās projekta jomās. Å ajā gadÄ«jumā jums ir pēc iespējas vairāk jāautomatizē visi procesi.

Diemžēl dokumentācija būs jāizlasa manuāli. Ar pietiekamu pieredzi jūs varat ātri saprast dokumentācijas kvalitāti. Kas ir patiesība un kas nepārprotami nesakrīt ar realitāti. Dažreiz jūs varat redzēt arhitektūru dokumentācijā, kas nekad nedarbosies reālajā dzīvē. Tas liek jums pārdomāt, kā tas tika paveikts patiesībā projektā.

NoderÄ«gi rÄ«ki projektu novērtÄ“Å”anas automatizÄ“Å”anai

Koda novērtÄ“Å”ana ir vienkārÅ”s uzdevums. Varat izmantot statisko kodu analizatorus, kas parādÄ«s dizaina, veiktspējas un droŔības problēmas. Å eit ir daži no tiem:

101. struktÅ«ra ir lielisks instruments arhitektam. Tas parādÄ«s kopainu, atkarÄ«bas starp moduļiem un potenciālās jomas pārstrukturÄ“Å”anai. Tāpat kā visi labie rÄ«ki, tas maksā labu naudu, taču varat izmantot 30 dienu izmēģinājuma versiju.

soundQube - vecs labais rÄ«ks. RÄ«ks statiskā koda analÄ«zei. Ä»auj identificēt sliktu kodu, kļūdas un droŔības problēmas vairāk nekā 20 programmÄ“Å”anas valodās.

Visiem mākoņa pakalpojumu sniedzējiem ir infrastruktūras uzraudzības rīki. Tas ļaus pareizi novērtēt savas infrastruktūras efektivitāti izmaksu un veiktspējas ziņā. Attiecībā uz AWS tas ir uzticams padomdevējs. Azure tas ir viegli Azure padomnieks.

Papildu veiktspējas uzraudzÄ«ba un reÄ£istrÄ“Å”ana palÄ«dzēs atrast veiktspējas problēmas visos lÄ«meņos. Sākot no datu bāzes ar neefektÄ«viem vaicājumiem, aizmugursistēmu un beidzot ar priekÅ”galu. Pat ja klients Å”os rÄ«kus iepriekÅ” nav instalējis, varat tos diezgan ātri integrēt esoÅ”ajā sistēmā, lai noteiktu veiktspējas problēmas.

Kā vienmēr, labi instrumenti ir tā vērti. Varu ieteikt pāris maksas rÄ«kus. Protams, jÅ«s varat izmantot atvērtā koda, bet tas prasÄ«s vairāk laika. Un tas jādara iepriekÅ”, nevis arhitektÅ«ras novērtÄ“Å”anas procesa laikā.

Jauns relikts ā€“ rÄ«ks lietojumprogrammu veiktspējas novērtÄ“Å”anai
Datadogs ā€“ mākoņsistēmu uzraudzÄ«bas pakalpojums

DroŔības pārbaudei ir pieejami daudzi rÄ«ki. Å oreiz es jums ieteikÅ”u bezmaksas sistēmas skenÄ“Å”anas rÄ«ku.

OWASP ZAP ā€“ rÄ«ks tÄ«mekļa lietojumprogrammu skenÄ“Å”anai, lai nodroÅ”inātu atbilstÄ«bu droŔības standartiem.

Saliksim visu vienā veselumā.

Ziņojuma sagatavoÅ”ana

Sāciet savu pārskatu ar datiem, ko savācāt no klienta. Aprakstiet projekta mērķus, ierobežojumus, nefunkcionālās prasības. Pēc tam jānorāda visi ievades dati: pirmkods, dokumentācija, infrastruktūra.

Nākamais solis. Uzskaitiet visas problēmas, kuras atradāt manuāli vai izmantojot automatizētus rīkus. Lietojumprogrammu sadaļas beigās ievietojiet lielus automātiski ģenerētus pārskatus. Jābūt īsiem un kodolīgiem pierādījumiem par konstatētajām problēmām.
Nosakiet prioritāti kļūdas, brÄ«dinājuma, informācijas skalā atrastajām problēmām. JÅ«s varat izvēlēties savu skalu, taču Ŕī ir vispārpieņemtā.

JÅ«s kā Ä«sts arhitekts esat atbildÄ«gs par ieteikumu sniegÅ”anu konstatēto problēmu novērÅ”anai. Aprakstiet uzlabojumus un biznesa vērtÄ«bu, ko klients saņems. Kā parādÄ«t biznesa vērtÄ«bu no arhitektÅ«ras pārstrukturÄ“Å”ana mēs apspriedām iepriekÅ”.

Sagatavojiet ceļvedi ar nelielām iterācijām. Katrai iterācijai jāietver pabeigÅ”anas laiks, apraksts, uzlaboÅ”anai nepiecieÅ”amo resursu apjoms, tehniskā vērtÄ«ba un biznesa vērtÄ«ba.

Pabeidzam arhitektūras novērtējumu un sniedzam klientam atskaiti

Nekad vienkārÅ”i nesÅ«tiet ziņojumu. To var neizlasÄ«t vispār vai arÄ« to var neizlasÄ«t un saprast bez pienācÄ«ga paskaidrojuma. ÄŖsāk sakot, dzÄ«vā saziņa palÄ«dz novērst pārpratumus starp cilvēkiem. Jums vajadzētu ieplānot tikÅ”anos ar klientu un runāt par konstatētajām problēmām, koncentrējoties uz bÅ«tiskākajām. Ir vērts pievērst klienta uzmanÄ«bu problēmām, par kurām viņŔ, iespējams, pat nenojauÅ”. Piemēram, droŔības problēmas un paskaidrojiet, kā tās varētu ietekmēt uzņēmējdarbÄ«bu. Parādiet savu ceļvedi ar uzlabojumiem un apspriediet dažādas klientam piemērotākas iespējas. Tas varētu bÅ«t laiks, resursi, darba apjoms.

Kā sanāksmes kopsavilkumu nosūtiet ziņojumu klientam.

Noslēgumā

ArhitektÅ«ras novērtÄ“Å”ana ir sarežģīts process. Lai pareizi veiktu novērtējumu, jums ir jābÅ«t pietiekamai pieredzei un zināŔanām.

Jau nedēļas laikā ir iespējams nodroÅ”ināt klientam viņam un viņa biznesam noderÄ«gus rezultātus. Pat ja jÅ«s to darāt vienatnē.

Pamatojoties uz manu pieredzi, daudzi uzlabojumi tika lejupielādēti pa vidu, un dažreiz tie netika sākti. Tie, kas izvēlējās sev zelta vidusceļu un ar minimālām darbaspēka izmaksām veica tikai daļu no biznesam noderīgākajiem uzlabojumiem, būtiski uzlaboja sava produkta kvalitāti. Tie, kas pēc pāris gadiem neko nedarīja, varēja projektu vispār slēgt.

Jūsu mērķis ir parādīt klientam maksimālus uzlabojumus par minimālo cenu.

Citi raksti no sadaļas arhitektūra varat lasīt brīvajā laikā.

Es novēlu jums tīru kodu un labus arhitektūras lēmumus.

Mūsu facebook grupa - Programmatūras arhitektūra un izstrāde.

Avots: www.habr.com

Pievieno komentāru