Pamantayan para sa mahusay na arkitektura ng software

Kahusayan

Ang mga nakaranasang programmer ay madaling makapagsasabi ng isang magandang arkitektura mula sa isang masama, ngunit kung hihilingin na ilarawan ito sa ilang salita, malamang na hindi nila ito magagawa. Walang iisang pamantayan para sa mahusay na arkitektura at walang iisang kahulugan.

Gayunpaman, kung iisipin mo ito, maaari kang magsulat ng ilang pamantayan na dapat matugunan ng isang mahusay na arkitektura. Ang isang mahusay na arkitektura ay, una sa lahat, isang lohikal na arkitektura na ginagawang mas simple at mas mahusay ang proseso ng pagbuo at pagpapanatili ng isang programa.

Kapag ang isang programa ay may mahusay na arkitektura, palaging sapat na madaling maunawaan kung paano ito gumagana at kung saan isusulat ang code. Ang isang mahusay na arkitekto na programa ay mas madaling baguhin, subukan, i-debug, at i-develop. Ang mga matalinong tao ay bumuo ng mga sumusunod na pamantayan para sa mahusay na arkitektura:

• Kahusayan;
• Kakayahang umangkop;
• Pagpapalawak;
• Scalability;
• kakayahang masubok;
• Pagpapanatili ng code.

Kahusayan ng system. Ang programa, siyempre, ay dapat na malutas ang mga itinalagang gawain at maisagawa nang maayos ang mga pag-andar nito, at sa iba't ibang mga kondisyon. Mukhang ginagawa ng anumang programa ang dapat nitong gawin (kung ito ay nakasulat), ngunit madalas na hindi ito ang lahat ng kaso.

Patuloy kang makakatagpo ng mga programa na hindi ginagawa ang sinasabi nilang ginagawa nila.

• Ang Libre Office ay isang ganap na kapalit para sa Microsoft Office (hindi talaga);
• Sinusuportahan ng Edge browser ang lahat ng mga pamantayan sa web (hindi talaga);
• Ang bangko ay nagmamalasakit sa seguridad ng personal na data ng mga gumagamit nito (talagang hindi).

At hindi pa namin naaapektuhan ang pagganap, pagiging maaasahan, napapanahong pag-aayos ng bug o ang paglalathala ng impormasyon tungkol sa mga kilalang kahinaan.

Malinaw na walang perpekto, ngunit dapat lutasin ng programa ang mga pangunahing gawain nito. Samakatuwid, nang walang kahusayan, wala kahit saan.

Kakayahang umangkop

Ang tanging bagay na mas mahalaga kaysa sa kahusayan sa aking opinyon ay ang kakayahang umangkop. Ang anumang aplikasyon ay kailangang magbago sa paglipas ng panahon, habang nagbabago ang mga kinakailangan, nagdaragdag ng mga bago. Ang mas mabilis at mas maginhawang gumawa ng mga pagbabago sa umiiral na pag-andar, mas kaunting mga problema at error na dulot nito, mas nababaluktot ang arkitektura ng system.

Kadalasan, iniisip ng mga baguhang programmer / arkitekto na kailangan nila ng perpektong arkitektura para sa mga kasalukuyang gawain. Hindi. Kailangan mo ng perpektong arkitektura para sa mga gawain na iaanunsyo sa iyo sa isang taon. Ikaw, na ngayon ay hindi alam ang mga gawain sa hinaharap, ay dapat malaman kung ano ang mga ito.

Walang saysay na subukang hulaan ang mga ito, dahil palaging may hindi inaasahang bagay. Ngunit dapat mong isaalang-alang na ang mga naturang gawain ay lilitaw. Samakatuwid, sa proseso ng pag-unlad, subukang suriin kung ano ang nakukuha sa mga tuntunin kung paano ito kailangang baguhin.

Tanungin ang iyong sarili: "Ano ang mangyayari kung ang kasalukuyang desisyon sa arkitektura ay lumabas na mali?", "Gaano karaming code ang babaguhin?". Ang pagpapalit ng isang fragment ng system ay hindi dapat makaapekto sa iba pang mga fragment nito.

Hangga't maaari, ang mga desisyon sa arkitektura ay hindi dapat itakda sa bato, at ang mga kahihinatnan ng mga pagkakamali sa arkitektura ay dapat na makatwirang limitado. "Ang magandang arkitektura ay nagbibigay-daan sa iyo na I-DELAY ang mga pangunahing desisyon" (Bob Martin) at pinapaliit ang "gastos" ng mga pagkakamali.

Ang isa sa mga pamamaraang ito ay ang paghahati ng aplikasyon sa mga microservice: madaling hatiin ang umiiral nang logic sa magkakahiwalay na bahagi. Ngunit ang pinakamalaking problema ay ang paggawa ng mga pagbabago sa hinaharap sa isang dosenang serbisyo nang sabay-sabay upang ipatupad ang isang maliit na tampok.

Scalability

Ang scalability ay ang kakayahang bawasan ang oras ng pag-unlad sa pamamagitan ng pagdaragdag ng mga bagong tao sa proyekto. Dapat pahintulutan ng arkitektura ang proseso ng pag-unlad na maiparallelize upang maraming tao ang makapagtrabaho sa programa nang sabay-sabay.

Tila ang panuntunang ito ay isinasagawa nang mag-isa, ngunit sa pagsasagawa ang lahat ay eksaktong kabaligtaran. Mayroon pa ngang sobrang sikat na libro, The Mythical Man-Month , na nagpapaliwanag kung bakit kapag may mga bagong tao na idinagdag sa isang proyekto, tumataas ang oras ng pag-develop.

Pagpapalawak

Ang extensibility ay ang kakayahang magdagdag ng mga bagong feature at entity sa isang system nang hindi sinisira ang core structure nito. Sa paunang yugto, makatuwirang ilagay lamang ang pangunahing at pinakakailangang pag-andar sa system.

Ito ang tinatawag na prinsipyo ng YAGNI - hindi mo ito kakailanganin , "hindi mo ito kakailanganin". Kasabay nito, ang arkitektura ay dapat magpapahintulot sa iyo na madaling madagdagan ang karagdagang pag-andar kung kinakailangan. At upang ang pagpapakilala ng mga pinaka-malamang na pagbabago ay nangangailangan ng hindi bababa sa pagsisikap.

Ang pangangailangan na ang arkitektura ng system ay nababaluktot at napapalawak (iyon ay, may kakayahang magbago at ebolusyon) ay napakahalaga na kahit na ito ay nabuo bilang isang hiwalay na prinsipyo - ang "Open/ Closed Principle " . Ang Open-Closed Principle ay ang pangalawa sa limang SOLID na prinsipyo: ang mga entity ng software (mga klase, module, function) ay dapat na bukas para sa extension, ngunit sarado para sa pagbabago .

Sa madaling salita: posible na baguhin at palawigin ang pag-uugali ng system nang hindi muling isinusulat ang mga kasalukuyang bahagi ng system .

Nangangahulugan ito na ang application ay dapat na idinisenyo sa paraang ang pagbabago ng pag-uugali nito at pagdaragdag ng bagong functionality ay makakamit sa pamamagitan ng pagsulat ng bagong code (mga extension), nang hindi kinakailangang baguhin ang umiiral na code.

Sa kasong ito, ang paglitaw ng mga bagong kinakailangan ay hindi nangangailangan ng pagbabago ng umiiral na lohika, ngunit maaaring ipatupad pangunahin sa pamamagitan ng pagpapalawak nito. Ang prinsipyong ito ay ang batayan ng "plug-in architecture" (Plugin Architecture). Ang mga pamamaraan kung saan ito ay maaaring makamit ay tatalakayin sa ibang pagkakataon.

Tandaan ang mga servlet at filter? Bakit kailangan ang mga filter, at kahit na may hiwalay na mga interface, kung, sa katunayan, ang lahat ng parehong lohika ay maaaring ipatupad gamit ang mga servlet?

Ito ay ang pag-imbento ng konsepto ng mga filter (service servlets) na naging posible upang ilipat ang iba't ibang mga function ng serbisyo sa isang hiwalay na layer. At sa hinaharap, kapag binabago ang pag-uugali ng mga filter, hindi kinakailangan na baguhin ang mga servlet.

Bago ang pag-imbento ng mga filter, ang lahat ng lohika ng serbisyo na responsable para sa pag-redirect ng mga kahilingan ay matatagpuan sa mga servlet mismo. At kadalasan ang isang maliit na pagbabago sa lohika ay hahantong sa pangangailangan na dumaan sa lahat ng mga servlet at gumawa ng iba't ibang mga pagbabago sa lahat.

Testability

Kung isa kang Java Backend Developer, madalas na inilalantad ng iyong mga server application ang isang hanay ng mga pamamaraan bilang REST API. At upang matiyak na gumagana ang lahat ng iyong mga pamamaraan ayon sa nilalayon, kailangan nilang saklawin ng mga pagsubok.

Sa pangkalahatan, ang saklaw ng pagsubok ng API ay isang magandang istilo. Binibigyang-daan ka nitong tiyakin na talagang ginagawa ng iyong API ang nilalayon nitong gawin. At higit sa lahat, makakagawa ka ng mga pagbabago sa logic ng server at madaling suriin na hindi mo sinasadyang nasira ang anuman .

Sa sandaling magsimula kang magsulat ng mga pagsubok, malalaman mo na ang karamihan sa mga code ay hindi masusuri sa lahat: mga pribadong pamamaraan, malakas na pagkakabit, mga static na klase at mga variable.

"Bakit kailangan natin ng mga pagsubok kung gumagana ang code?", itatanong ng baguhan.

"Bakit kailangan namin ang gumaganang code kung hindi ito masuri?", itatanong ng propesyonal.

Ang code na madaling subukan ay maglalaman ng mas kaunting mga bug at magiging mas maaasahan. Ngunit ang mga pagsubok ay hindi lamang nagpapabuti sa kalidad ng code. Halos lahat ng mga developer sa kalaunan ay dumating sa konklusyon na ang pangangailangan ng "mahusay na pagsubok" ay isa ring puwersang gumagabay na awtomatikong humahantong sa magandang disenyo.

Narito ang isang quote mula sa aklat na Ideal Architecture: "Gamitin ang prinsipyo ng "testability" ng isang klase bilang isang "litmus test" ng magandang disenyo ng klase. Kahit na hindi ka sumulat ng isang linya ng test code, sagutin ang tanong na ito sa 90 % ng mga kaso ay makakatulong upang maunawaan kung paano ang lahat ay mabuti" o "masama" sa kanyang disenyo."

Mayroong isang buong pamamaraan para sa pagbuo ng mga programa batay sa mga pagsubok, na tinatawag na Test-Driven Development (TDD). Ito ay siyempre ang iba pang matinding: magsulat ng code bago ka magsulat ng code.

Pagpapanatili ng code

Bilang isang patakaran, maraming tao ang nagtatrabaho sa programa - ang ilan ay umalis, ang mga bago ay darating. Ang average na oras ng pagtatrabaho ng isang programmer sa isang kumpanya ng IT ay isa at kalahating taon. Kaya kung dumating ka sa isang proyekto na 5 taong gulang, pagkatapos ay 20% lamang ng iyong mga kasamahan ang nagtrabaho dito mula pa sa simula.

Ang pagpapanatili at pagbuo ng isang programa na isinulat ng iba ay napakahirap. Kahit na ang programa ay nakasulat na, madalas na kinakailangan na ipagpatuloy ito upang mapanatili: ayusin ang mga error at gumawa ng maliliit na pagwawasto. At kadalasan ito ay kailangang gawin ng mga taong hindi nakibahagi sa pagsulat nito.

Samakatuwid, ang isang mahusay na arkitektura ay dapat gawing medyo madali at mabilis para sa mga bagong tao na maunawaan ang system . Ang proyekto ay dapat na:

• Well structured.
• Huwag maglaman ng pagdoble.
• Magkaroon ng mahusay na format na code.
• Ito ay kanais-nais na isama ang dokumentasyon.
• Kinakailangang maglapat ng mga pamantayan at pamilyar na mga solusyon para sa mga programmer.

Madali mong ma-rate ang proyektong iyong ginagawa sa 5-point scale . Magbilang lamang ng dalawang puntos para sa bawat isa sa mga kinakailangang ito . At kung nakakuha ka ng 5 o higit pa, kung gayon ikaw ay mapalad.

Kahit na ang mga programmer ay may prinsipyo ng hindi bababa sa sorpresa : kung mas kakaiba ang sistema, mas mahirap para sa iba na maunawaan. Karaniwan, ito ay ginagamit na may kaugnayan sa user interface, ngunit ito ay naaangkop din sa pagsulat ng code.