Araw-araw, bawat sandali sa panahon ng aming karera sa engineering, nakakaranas kami ng maraming iba't ibang mga problema ng iba't ibang kumplikado at mga sitwasyon kung saan kailangan naming gumawa ng desisyon o ipagpaliban ito dahil sa kakulangan ng data. Sa tuwing nagtatayo kami ng mga bagong serbisyo, gumagawa ng imprastraktura, o kahit na bumubuo ng mga proseso ng pag-unlad, hinahawakan namin ang isang malaking mundo ng iba't ibang mga hamon.
Mahirap, at marahil imposible pa, na ilista ang lahat ng mga problema. Makakaharap mo lang ang ilan sa mga isyung ito kung nagtatrabaho ka sa isang partikular na angkop na lugar. Sa kabilang banda, marami ang dapat nating maunawaan kung paano lutasin, dahil mahalaga ang mga ito sa pagbuo ng mga IT system. Sa mataas na posibilidad, makakatagpo mo sila sa lahat ng mga proyekto.
Sa artikulong ito, ibabahagi ko ang aking mga karanasan sa ilan sa mga problemang naranasan ko habang gumagawa ng mga software program.
Kung titingnan natin ang Wikipedia, makikita natin ang sumusunod na kahulugan
Sa aspect-oriented na software development, ang mga cross-cutting na alalahanin ay mga aspeto ng isang program na nakakaapekto sa ilang mga module, nang walang posibilidad na ma-encapsulated sa alinman sa mga ito. Ang mga alalahaning ito ay kadalasang hindi maaaring malinis na mabulok mula sa iba pang bahagi ng system sa parehong disenyo at pagpapatupad, at maaaring magresulta sa alinman sa pagkalat (pagdoble ng code), pagkagusot (mga makabuluhang dependency sa pagitan ng mga system), o pareho.
Lubos nitong inilalarawan kung ano ito, ngunit gusto kong palawigin at pasimplehin ito nang kaunti:
Ang cross-cutting concern ay isang konsepto o bahagi ng system/organisasyon na nakakaapekto (o 'pumaputol') sa maraming iba pang bahagi.
Ang pinakamahusay na mga halimbawa ng naturang mga alalahanin ay ang arkitektura ng system, pag-log, seguridad, pamamahala ng transaksyon, telemetry, disenyo ng database at marami pang iba. Tatalakayin natin ang marami sa kanila sa ibang pagkakataon sa artikulong ito.
Sa antas ng code, ang mga cross-cutting na alalahanin ay madalas na ipinapatupad gamit ang mga diskarte tulad ng Aspect-Oriented Programming (AOP) , kung saan ang mga alalahaning ito ay bina-modularize sa magkakahiwalay na bahagi na maaaring ilapat sa buong application. Pinapanatili nitong nakahiwalay ang lohika ng negosyo sa mga alalahaning ito, na ginagawang mas nababasa at napanatili ang code.
Maraming posibleng paraan kung paano i-classify ang mga aspeto sa pamamagitan ng pagse-segment ng mga ito sa iba't ibang katangian tulad ng saklaw, laki, functionality, kahalagahan, target, at iba pa, ngunit sa artikulong ito, gagamit ako ng isang simpleng pag-uuri ng saklaw. Sa pamamagitan nito, ang ibig kong sabihin ay kung saan ang partikular na aspetong ito ay nakadirekta kung ito ay ang buong organisasyon, isang partikular na sistema, o isang partikular na elemento ng sistemang iyon.
Kaya, hahatiin ko ang mga aspeto sa Macro at Micro .
Sa aspeto ng Macro , ang ibig kong sabihin ay ang mga pagsasaalang-alang na sinusunod namin para sa buong sistema tulad ng napiling arkitektura ng system at ang disenyo nito (monolitik, microservice, arkitektura na nakatuon sa serbisyo), stack ng teknolohiya, istraktura ng organisasyon, atbp. Ang mga macro na aspeto ay pangunahing nauugnay sa estratehiko at mataas na antas mga desisyon.
Pansamantala, ang aspetong Micro ay mas malapit sa antas ng code at pag-unlad. Halimbawa, kung aling balangkas ang ginagamit para sa pakikipag-ugnayan sa database, ang istraktura ng proyekto ng mga folder at klase, o kahit na mga partikular na pattern ng disenyo ng bagay.
Bagama't hindi perpekto ang pag-uuri na ito, nakakatulong itong buuin ang pag-unawa sa mga posibleng problema at ang kahalagahan at epekto ng mga solusyong inilalapat namin sa kanila.
Sa artikulong ito, ang aking pangunahing pagtutuon ay sa mga macro na aspeto.
Noong nagsimula akong matuto tungkol sa arkitektura ng software, nagbasa ako ng maraming kawili-wiling artikulo tungkol sa batas ng Conway at ang epekto nito sa istruktura ng organisasyon. Lalo na ang isang ito . Kaya, ang batas na ito ay nagsasaad na
Ang anumang organisasyon na nagdidisenyo ng isang sistema (malawak na tinukoy) ay gagawa ng isang disenyo na ang istraktura ay isang kopya ng istraktura ng komunikasyon ng organisasyon.
Palagi akong naniniwala na ang konseptong ito ay talagang napaka-unibersal at kumakatawan sa Golden Rule.
Pagkatapos ay sinimulan kong matutunan ang diskarte ng Domain-Driven Design (DDD) ni Eric Evans para sa mga sistema ng pagmomodelo. Binibigyang-diin ni Eric Evans ang kahalagahan ng pagkilala sa Bounded Context. Ang konseptong ito ay nagsasangkot ng paghahati ng isang kumplikadong modelo ng domain sa mas maliit, mas mapapamahalaang mga seksyon, bawat isa ay may sarili nitong limitadong hanay ng kaalaman. Nakakatulong ang diskarteng ito sa epektibong komunikasyon ng koponan, dahil binabawasan nito ang pangangailangan para sa malawak na kaalaman sa buong domain at pinapaliit ang paglipat ng konteksto, kaya ginagawang mas mahusay ang mga pag-uusap. Ang paglipat ng konteksto ay ang pinakamasama at pinaka nakakaubos ng mapagkukunan. Kahit na ang mga computer ay nahihirapan dito. Bagama't malamang na hindi makamit ang kumpletong kawalan ng paglipat ng konteksto, sa palagay ko iyon ang dapat nating pagsikapan.
Pagbabalik sa Conway's Law, nakakita ako ng ilang isyu dito.
Ang unang isyu na naranasan ko sa Conway's Law, na nagmumungkahi na ang disenyo ng system ay sumasalamin sa istruktura ng organisasyon, ay ang potensyal para sa pagbuo ng kumplikado at komprehensibong Bounded Contexts. Lumilitaw ang pagiging kumplikadong ito kapag ang istraktura ng organisasyon ay hindi nakahanay sa mga hangganan ng domain, na humahantong sa Mga Bounded na Konteksto na lubos na magkakaugnay at puno ng impormasyon. Ito ay humahantong sa madalas na paglipat ng konteksto para sa development team.
Ang isa pang isyu ay ang paglabas ng terminolohiya ng organisasyon sa antas ng code. Kapag nagbago ang mga istruktura ng organisasyon, nangangailangan ito ng mga pagbabago sa codebase, na kumukonsumo ng mahahalagang mapagkukunan.
Kaya, ang pagsunod sa Inverse Conway Maneuver ay nakakatulong sa pagbuo ng system at organisasyon na humihikayat ng ninanais na arkitektura ng software. Gayunpaman, kapansin-pansing sabihin na ang diskarte na ito ay hindi gagana nang maayos sa nabuo nang arkitektura at mga istraktura dahil ang mga pagbabago sa yugtong ito ay pinahaba, ngunit ito ay pambihirang gumaganap sa mga startup dahil mabilis silang magpakilala ng anumang mga pagbabago.
Ang pattern na ito o "anti-pattern" ay nagtutulak sa pagbuo ng isang sistema nang walang anumang arkitektura. Walang mga panuntunan, walang mga hangganan, at walang diskarte sa kung paano kontrolin ang hindi maiiwasang lumalagong kumplikado. Ang pagiging kumplikado ay ang pinakakakila-kilabot na kalaban sa paglalakbay ng pagbuo ng mga software system.
Upang maiwasan ang pagbuo ng ganitong uri ng isang sistema, kailangan nating sundin ang mga partikular na alituntunin at mga hadlang.
Mayroong maraming mga kahulugan para sa Arkitektura ng Software. Gusto ko ang marami sa kanila dahil saklaw nila ang iba't ibang aspeto nito. Gayunpaman, upang makapagpaliwanag tungkol sa arkitektura, kailangan nating natural na mabuo ang ilan sa mga ito sa ating isipan. At kapansin-pansing sabihin na ang kahulugang ito ay maaaring umunlad. Kaya, hindi bababa sa ngayon, mayroon akong sumusunod na paglalarawan para sa aking sarili.
Ang Arkitektura ng Software ay tungkol sa mga desisyon at pagpipiliang ginagawa mo araw-araw na nakakaapekto sa binuong sistema.
Upang makagawa ng mga pagpapasya na kailangan mong taglayin sa iyong "bag" na mga prinsipyo at mga pattern para sa paglutas ng mga lumalabas na problema, mahalagang sabihin din na ang pag-unawa sa mga kinakailangan ay susi sa pagbuo ng kung ano ang kailangan ng isang negosyo. Gayunpaman, kung minsan ang mga kinakailangan ay hindi malinaw o kahit na hindi tinukoy, sa kasong ito, mas mahusay na maghintay upang makakuha ng higit pang paglilinaw o umasa sa iyong karanasan at magtiwala sa iyong intuwisyon. Ngunit gayon pa man, hindi ka makakapagdesisyon nang maayos kung wala kang mga prinsipyo at pattern na maaasahan. Doon ako pupunta sa kahulugan ng Software Architecture Style.
Ang Estilo ng Arkitektura ng Software ay isang hanay ng mga prinsipyo at pattern na tumutukoy kung paano bumuo ng software.
Mayroong maraming iba't ibang mga istilo ng arkitektura na nakatuon sa iba't ibang panig ng nakaplanong arkitektura, at ang paglalapat ng marami sa mga ito nang sabay-sabay ay isang normal na sitwasyon.
Halimbawa, tulad ng:
Monolithic na arkitektura
Disenyong batay sa domain
Nakabatay sa bahagi
Mga microservice
Pipe at mga filter
Dahil sa kaganapan
Microkernel
Nakatuon sa serbisyo
at iba pa…
Siyempre, mayroon silang kanilang mga pakinabang at disadvantages, ngunit ang pinakamahalagang bagay na natutunan ko ay ang arkitektura ay unti-unting nagbabago habang nakadepende sa mga aktwal na problema. Ang simula sa monolithic na arkitektura ay isang magandang pagpipilian para sa pagbabawas ng mga kumplikadong pagpapatakbo, malamang na ang arkitektura na ito ay akma sa iyong mga pangangailangan kahit na matapos na maabot ang Product-market Fit (PMI) na yugto ng pagbuo ng produkto. Sa laki, maaari mong isaalang-alang ang paglipat patungo sa isang event-driven na diskarte at mga microservice para sa pagkamit ng independiyenteng deployment, heterogenous tech stack environment, at hindi gaanong pinagsamang arkitektura (at hindi gaanong transparent sa pansamantala dahil sa likas na katangian ng event-driven at pub-sub approach kung ang mga ito ay pinagtibay). Ang pagiging simple at kahusayan ay malapit at may malaking epekto sa isa't isa. Karaniwan, ang mga kumplikadong arkitektura ay nakakaapekto sa bilis ng pag-develop ng mga bagong feature, pagsuporta at pagpapanatili ng mga umiiral na, at paghamon sa natural na ebolusyon ng system.
Gayunpaman, ang mga kumplikadong sistema ay madalas na nangangailangan ng kumplikado at komprehensibong arkitektura, na hindi maiiwasan.
Medyo, ito ay isang napakalawak na paksa, at mayroong maraming magagandang ideya tungkol sa kung paano buuin at bumuo ng mga sistema para sa natural na ebolusyon. Batay sa aking karanasan, nagawa ko ang sumusunod na diskarte:
Mahalaga rin na maunawaan ang mga numero at sukatan tulad ng DAU (Daily Active Users), MAU (Monthly Active Users), RPC (Request Per Second), at TPC (Transaction Per Second) dahil makakatulong ito sa iyong gumawa ng mga pagpipilian dahil ang architecture para sa Iba ang 100 aktibong user at 100 milyong aktibong user.
Bilang pangwakas na tala, sasabihin ko na ang arkitektura ay may malaking epekto sa tagumpay ng produkto. Ang hindi magandang idinisenyong arkitektura para sa mga produkto ay kinakailangan sa pag-scale, na malamang na humantong sa pagkabigo dahil hindi maghihintay ang mga customer habang sinusukat mo ang system, pipili sila ng isang katunggali, kaya kailangan nating mauna sa potensyal na pag-scale. Bagama't inaamin ko na kung minsan ay hindi ito maaaring maging isang matangkad na diskarte, ang ideya ay magkaroon ng isang nasusukat ngunit hindi pa naka-scale na sistema. Sa kabilang banda, ang pagkakaroon ng isang napaka-komplikado at naka-scale na sistema na walang mga customer o mga plano na makakuha ng marami sa kanila ay gagastos ng pera sa iyong negosyo nang walang bayad.
Ang pagpili ng isang stack ng teknolohiya ay isa ring desisyon sa antas ng macro dahil nakakaimpluwensya ito sa pag-hire, mga natural na pananaw sa ebolusyon ng system, scalability, at performance ng system.
Ito ang listahan ng mga pangunahing pagsasaalang-alang para sa pagpili ng isang stack ng teknolohiya:
Paano makakaapekto sa paglago ng negosyo ang pagkakaroon ng maramihang mga stack ng teknolohiya?
Mula sa isang pananaw, ang pagpapakilala ng isa pang stack ay maaaring palakihin ang iyong pagkuha, ngunit sa kabilang banda, nagdadala ito ng mga karagdagang gastos sa pagpapanatili dahil kailangan mong suportahan ang parehong mga stack. Kaya, tulad ng sinabi ko dati, sa aking pananaw, dagdag na pangangailangan lamang ang dapat na isang argumento para sa pagsasama ng higit pang mga stack ng teknolohiya.
Ngunit ano ang tungkol sa prinsipyo ng pagpili ng pinakamahusay na tool para sa isang partikular na problema?
Minsan wala kang ibang pagpipilian kundi magdala ng mga bagong tool upang malutas ang isang partikular na problema batay sa parehong mga pagsasaalang-alang na nabanggit, sa mga ganitong kaso, makatuwirang piliin ang pinakamahusay na solusyon.
Ang paglikha ng mga system na walang mataas na pagkakabit sa isang partikular na teknolohiya ay maaaring maging isang hamon. Gayunpaman, nakakatulong na magsikap para sa isang kundisyon kung saan ang system ay hindi mahigpit na pinagsama sa teknolohiya, at hindi ito mamamatay kung bukas, ang isang partikular na balangkas o tool ay magiging mahina o hindi na ginagamit.
Ang isa pang mahalagang pagsasaalang-alang ay nauugnay sa open-source at proprietary software dependencies. Ang proprietary software ay nagbibigay sa iyo ng mas kaunting flexibility at ang posibilidad na ma-customize. Gayunpaman, ang pinakamapanganib na kadahilanan ay ang pag-lock-in ng vendor, kung saan nakadepende ka sa mga produkto, presyo, tuntunin, at roadmap ng isang vendor. Maaari itong maging peligroso kung magbabago ng direksyon ang vendor, magtataas ng mga presyo, o ihinto ang produkto. Binabawasan ng open-source software ang panganib na ito, dahil hindi ito kinokontrol ng isang entity. Ang pag-aalis ng isang punto ng kabiguan sa lahat ng antas ay isang susi sa pagbuo ng maaasahang mga sistema para sa paglago.
Ang nag-iisang punto ng kabiguan (SPOF) ay tumutukoy sa anumang bahagi ng isang system na, kung mabibigo ito, ay magiging sanhi ng paghinto ng buong system sa paggana. Ang pag-aalis ng mga SPOF sa lahat ng antas ay mahalaga para sa anumang system na nangangailangan ng mataas na kakayahang magamit. Lahat, kabilang ang kaalaman, tauhan, bahagi ng system, cloud provider, at internet cable, ay maaaring mabigo.
Mayroong ilang mga pangunahing pamamaraan na maaari naming ilapat upang maalis ang mga solong punto ng pagkabigo:
Sa artikulong ito, tinalakay namin ang ilang pangunahing aspeto ng Macro at kung paano namin haharapin ang pagiging kumplikado ng mga ito.
Salamat sa pagbabasa! See you next time!