Paano Magbasa at Magtama ng 100,000 Linya ng Code sa Isang Linggo

Paano Magbasa at Magtama ng 100,000 Linya ng Code sa Isang Linggo
Sa simula ay palaging mahirap na maunawaan ang isang malaki at lumang proyekto. Ang arkitektura ay isa sa mga aktibidad ng pagtatasa ng arkitekto. Kadalasan kailangan mong magtrabaho sa malalaking, lumang mga proyekto, at ang mga resulta ay dapat maihatid sa isang linggo.

Paano suriin ang isang proyekto ng 100k o higit pang mga linya ng code sa isang linggo habang nagbibigay pa rin ng mga resulta na talagang kapaki-pakinabang sa kliyente.

Karamihan sa mga arkitekto at teknikal na lead ay nakatagpo ng mga katulad na pagtatasa ng proyekto. Ito ay maaaring magmukhang isang semi-pormal na proseso o bilang isang hiwalay na serbisyo tulad ng ginagawa sa aming kumpanya, sa isang paraan o iba pang karamihan sa inyo ay nakipag-ugnayan dito.

Ang orihinal sa Ingles para sa iyong mga kaibigan na hindi nagsasalita ng Ruso ay narito: Architecture Assessment sa isang linggo.

Ang diskarte ng aming kumpanya

Sasabihin ko sa iyo kung paano ito gumagana sa aming kumpanya at kung paano ako kumikilos sa mga katulad na sitwasyon, ngunit madali mong mababago ang diskarteng ito ayon sa mga pangangailangan ng iyong proyekto at kumpanya.

Mayroong dalawang uri ng pagtatasa ng arkitektura.

Panloob – karaniwan naming ginagawa ito para sa mga proyekto sa loob ng kumpanya. Anumang proyekto ay maaaring humiling ng pagtatasa ng arkitektura para sa ilang kadahilanan:

  1. Sa tingin ng team ay perpekto ang kanilang proyekto at ito ay kahina-hinala. Nagkaroon kami ng mga ganitong kaso, at madalas sa mga ganitong proyekto ang lahat ay malayo sa perpekto.
  2. Nais ng koponan na subukan ang kanilang proyekto at ang kanilang mga solusyon.
  3. Alam ng koponan ang mga bagay na masama. Maaari pa nga nilang ilista ang mga pangunahing problema at sanhi, ngunit gusto ng kumpletong listahan ng mga problema at rekomendasyon para sa pagpapabuti ng proyekto.

Panlabas ay isang mas pormal na proseso kaysa sa panloob na pagtatasa. Ang kliyente ay palaging dumarating lamang sa isang kaso, kapag ang lahat ay masama - napakasama. Karaniwang nauunawaan ng kliyente na may mga pandaigdigang problema, ngunit hindi matukoy nang tama ang mga sanhi at hatiin ang mga ito sa mga bahagi.

Ang pagsusuri ng isang arkitektura para sa isang panlabas na kliyente ay isang mas kumplikadong kaso. Ang proseso ay dapat na mas pormal. Ang mga proyekto ay palaging malaki at luma. Marami silang problema, bug at baluktot na code. Ang isang ulat sa gawaing ginawa ay dapat na handa sa loob ng ilang linggo maximum, na dapat isama ang mga pangunahing problema at mga rekomendasyon para sa pagpapabuti. Samakatuwid, kung haharapin natin ang panlabas na pagtatasa ng proyekto, kung gayon ang panloob na pagtatasa ay magiging isang piraso ng cake. Isaalang-alang natin ang pinakamahirap na kaso.

Pagtatasa ng arkitektura ng proyekto ng negosyo

Ang isang tipikal na proyektong susuriin ay isang malaki, luma, proyekto ng negosyo na may maraming problema. Isang kliyente ang lumapit sa amin at hinihiling sa amin na ayusin ang kanyang proyekto. Ito ay tulad ng isang malaking bato ng yelo, ang kliyente ay nakikita lamang ang dulo ng kanyang mga problema at walang ideya kung ano ang nasa ilalim ng tubig (sa lalim ng code).

Mga problema na maaaring ireklamo ng customer at maaaring malaman ng:

  • Mga Isyu sa Pagganap
  • Mga isyu sa kakayahang magamit
  • Pangmatagalang deployment
  • Kakulangan ng yunit at iba pang mga pagsubok

Mga problema na malamang na hindi alam ng kliyente, ngunit maaaring naroroon sila sa proyekto:

  • Mga problema sa kaligtasan
  • Mga problema sa disenyo
  • Maling arkitektura
  • Mga error sa algorithm
  • Mga hindi naaangkop na teknolohiya
  • Teknikal na utang
  • Maling proseso ng pag-unlad

Proseso ng pagsusuri ng pormal na arkitektura

Ito ay isang pormal na proseso na sinusunod namin bilang isang kumpanya, ngunit maaari mo itong i-customize depende sa iyong kumpanya at proyekto.

Kahilingan mula sa isang kliyente

Hinihiling ng kliyente na suriin ang arkitektura ng kasalukuyang proyekto. Kinokolekta ng responsableng tao sa aming panig ang pangunahing impormasyon tungkol sa proyekto at pinipili ang mga kinakailangang eksperto. Depende sa proyekto, maaaring iba ang mga eksperto.

Solusyon Arkitekto – ang pangunahing taong responsable para sa pagtatasa at koordinasyon (at madalas ang isa lamang).
Mag-stack ng mga partikular na eksperto – .Net, Java, Python, at iba pang mga teknikal na espesyalista depende sa proyekto at mga teknolohiya
Mga eksperto sa cloud – ang mga ito ay maaaring Azure, GCP o AWS cloud architect.
Imprastraktura – DevOps, System administrator, atbp.
Iba pang mga eksperto – tulad ng malaking data, machine learning, performance engineer, security expert, QA lead.

Pagkolekta ng impormasyon tungkol sa proyekto

Dapat kang mangolekta ng maraming impormasyon hangga't maaari tungkol sa proyekto. Maaari kang gumamit ng iba't ibang mga diskarte depende sa sitwasyon:

  • Mga talatanungan at iba pang paraan ng komunikasyon sa pamamagitan ng koreo. Ang pinaka-hindi epektibong paraan.
  • Mga online na pagpupulong.
  • Mga espesyal na tool para sa pagpapalitan ng impormasyon gaya ng: Google doc, Confluence, repository, atbp.
  • Mga β€œLive” na pagpupulong sa site. Ang pinaka-epektibo at pinakamahal na paraan.

Ano ang dapat mong makuha mula sa kliyente?

Pangunahing impormasyon. Tungkol saan ang proyekto? Ang layunin at halaga nito. Mga pangunahing layunin at plano para sa hinaharap. Mga layunin at estratehiya sa negosyo. Mga pangunahing problema at nais na resulta.

Impormasyon ng proyekto. Technology stack, frameworks, programming language. On-premise o cloud deployment. Kung ang proyekto ay nasa cloud, anong mga serbisyo ang ginagamit. Anong mga pattern ng arkitektura at disenyo ang ginamit.

Non-functional na mga kinakailangan. Lahat ng mga kinakailangan na nauugnay sa pagganap, kakayahang magamit, at kadalian ng paggamit ng system. Mga kinakailangan sa kaligtasan, atbp.

Mga pangunahing kaso ng paggamit at daloy ng data.

Access sa source code. Ang pinakamahalagang bahagi! Talagang dapat kang makakuha ng access sa mga repositoryo at dokumentasyon kung paano buuin ang proyekto.

Access sa imprastraktura. Masarap magkaroon ng access sa entablado o imprastraktura ng produksyon upang gumana sa live na sistema. Ito ay isang mahusay na tagumpay kung ang kliyente ay may mga tool para sa pagsubaybay sa imprastraktura at pagganap. Pag-uusapan natin ang tungkol sa mga tool na ito sa susunod na seksyon.

Records. Kung ang kliyente ay may dokumentasyon ito ay isang magandang simula. Maaaring luma na ito, ngunit ito ay isang magandang simula pa rin. Huwag kailanman magtiwala sa dokumentasyon - subukan ito sa kliyente, sa totoong imprastraktura at sa source code.

Proseso ng Pagsusuri sa Arkitektura

Paano mapoproseso ng isang tao ang napakaraming impormasyon sa napakaikling panahon? Una sa lahat, parallelize ang trabaho.

Dapat tingnan ng DevOps ang imprastraktura. Tech lead sa code. Performance engineer upang tingnan ang mga sukatan ng pagganap. Ang isang database specialist ay dapat maghukay ng mas malalim sa mga istruktura ng data.

Ngunit ito ay isang perpektong kaso kapag mayroon kang maraming mga mapagkukunan. Karaniwan, isa hanggang tatlong tao ang nagsusuri ng isang proyekto. Maaari mo ring isagawa ang pagtatantya sa iyong sarili, na kadalasang nangyayari kung mayroon kang tamang kaalaman at karanasan sa lahat ng mga lugar ng proyekto. Sa kasong ito, kailangan mong i-automate ang lahat ng mga proseso hangga't maaari.

Sa kasamaang palad, kailangan mong basahin nang manu-mano ang dokumentasyon. Sa tamang dami ng karanasan, mabilis mong mauunawaan ang kalidad ng dokumentasyon. Ano ang totoo at kung ano ang malinaw na hindi tumutugma sa katotohanan. Minsan maaari mong makita ang arkitektura sa dokumentasyon na hindi gagana sa totoong buhay. Ito ay isang trigger para sa iyo na isipin kung paano ito ginawa sa katotohanan sa proyekto.

Mga kapaki-pakinabang na tool para i-automate ang pagsusuri ng proyekto

Ang pagsusuri ng code ay isang simpleng ehersisyo. Maaari kang gumamit ng mga static na code analyzer na magpapakita sa iyo ng mga isyu sa disenyo, pagganap, at seguridad. Narito ang ilan sa kanila:

Istraktura 101 ay isang mahusay na tool para sa isang arkitekto. Ipapakita nito sa iyo ang malaking larawan, mga dependency sa pagitan ng mga module at mga potensyal na lugar para sa refactoring. Tulad ng lahat ng mahusay na tool, nagkakahalaga ito ng magandang pera, ngunit maaari mong samantalahin ang isang 30-araw na bersyon ng pagsubok.

soundQube - isang magandang lumang tool. Isang tool para sa static code analysis. Binibigyang-daan kang tumukoy ng masamang code, mga bug, at mga problema sa seguridad para sa higit sa 20 programming language.

Ang lahat ng cloud provider ay may mga tool sa pagsubaybay sa imprastraktura. Ito ay magbibigay-daan sa iyong maayos na suriin ang pagiging epektibo ng iyong imprastraktura sa mga tuntunin ng gastos at pagganap. Para sa AWS ito ay pinagkakatiwalaang tagapayo. Madali lang para kay Azure Azure Advisor.

Ang karagdagang pagsubaybay sa pagganap at pag-log ay makakatulong sa paghahanap ng mga isyu sa pagganap sa lahat ng antas. Simula sa isang database na may hindi epektibong mga query, ang backend at nagtatapos sa frontend. Kahit na hindi pa na-install ng kliyente ang mga tool na ito dati, maaari mong isama ang mga ito sa umiiral nang system nang medyo mabilis upang matukoy ang mga isyu sa pagganap.

Gaya ng nakasanayan, sulit na sulit ang magagandang kasangkapan. Maaari akong magrekomenda ng ilang mga bayad na tool. Siyempre maaari kang gumamit ng open-source ngunit magdadala sa iyo ng mas maraming oras. At dapat itong gawin nang maaga, hindi sa panahon ng proseso ng pagtatasa ng arkitektura.

New Relic – isang kasangkapan para sa pagtatasa ng pagganap ng aplikasyon
datadog – serbisyo sa pagsubaybay sa cloud system

Mayroong maraming mga tool na magagamit para sa pagsubok sa seguridad. Sa pagkakataong ito, irerekomenda ko sa iyo ang isang libreng tool sa pag-scan ng system.

OWASP ZAP – isang tool para sa pag-scan ng mga web application para sa pagsunod sa mga pamantayan ng seguridad.

Pagsamahin natin ang lahat sa isang buo.

Paghahanda ng ulat

Simulan ang iyong ulat gamit ang data na iyong nakolekta mula sa kliyente. Ilarawan ang mga layunin ng proyekto, mga hadlang, mga kinakailangan na hindi gumagana. Pagkatapos nito, dapat na banggitin ang lahat ng data ng input: source code, dokumentasyon, imprastraktura.

Susunod na hakbang. Ilista ang anumang mga isyung nakita mo nang manu-mano o gamit ang mga automated na tool. Maglagay ng malalaking auto-generated na ulat sa dulo sa seksyon ng mga application. Dapat mayroong maikli at maikli na katibayan ng mga problemang natagpuan.
Unahin ang mga problemang makikita sa error, babala, sukat ng impormasyon. Maaari kang pumili ng iyong sariling sukat, ngunit ito ang karaniwang tinatanggap.

Bilang isang tunay na arkitekto, responsibilidad mong magbigay ng mga rekomendasyon para itama ang mga problemang natagpuan. Ilarawan ang mga pagpapahusay at halaga ng negosyo na matatanggap ng customer. Paano ipakita ang halaga ng negosyo mula sa refactoring ng arkitektura napag-usapan namin kanina.

Maghanda ng roadmap na may maliliit na pag-ulit. Ang bawat pag-ulit ay dapat maglaman ng oras upang makumpleto, paglalarawan, dami ng mga mapagkukunang kailangan para sa pagpapabuti, teknikal na halaga at halaga ng negosyo.

Kinukumpleto namin ang pagtatasa ng arkitektura at binibigyan namin ang kliyente ng isang ulat

Huwag na lang magpadala ng ulat. Maaaring hindi ito binabasa, o maaaring hindi basahin at maunawaan nang walang tamang paliwanag. Sa madaling salita, nakakatulong ang live na komunikasyon na maalis ang hindi pagkakaunawaan sa pagitan ng mga tao. Dapat kang mag-iskedyul ng isang pulong sa kliyente at pag-usapan ang mga problemang natagpuan, na tumutuon sa mga pinakamahalaga. Ito ay nagkakahalaga ng pagguhit ng atensyon ng kliyente sa mga problema na maaaring hindi niya alam. Gaya ng mga isyu sa seguridad at ipaliwanag kung paano sila makakaapekto sa negosyo. Ipakita ang iyong roadmap na may mga pagpapabuti at talakayin ang iba't ibang opsyon na mas angkop para sa kliyente. Ito ay maaaring oras, mapagkukunan, dami ng trabaho.

Bilang buod ng iyong pagpupulong, ipadala ang iyong ulat sa kliyente.

Sa pagtatapos

Ang pagsusuri sa arkitektura ay isang kumplikadong proseso. Upang maisagawa nang maayos ang pagtatasa kailangan mong magkaroon ng sapat na karanasan at kaalaman.

Posibleng bigyan ang kliyente ng mga resultang kapaki-pakinabang para sa kanya at sa kanyang negosyo sa loob lamang ng isang linggo. Kahit gawin mo mag-isa.

Batay sa aking karanasan, maraming mga pagpapabuti ang na-download sa gitna, at kung minsan ay hindi na nagsimula. Ang mga pumili ng ginintuang halaga para sa kanilang sarili at gumawa lamang ng bahagi ng mga pagpapahusay na pinakakapaki-pakinabang para sa negosyong may kaunting gastos sa paggawa ay makabuluhang nagpabuti sa kalidad ng kanilang produkto. Ang mga walang ginawa ay maaaring ganap na isara ang proyekto pagkatapos ng ilang taon.

Ang iyong layunin ay ipakita sa kliyente ang maximum na mga pagpapabuti para sa pinakamababang presyo.

Iba pang mga artikulo mula sa seksyon arkitektura maaari kang magbasa sa iyong paglilibang.

Nais kong malinis ang code at mahusay na mga desisyon sa arkitektura.

Ang aming facebook group - Arkitektura at Pag-unlad ng Software.

Pinagmulan: www.habr.com

Magdagdag ng komento