Paano Haharapin ang Pagiging Kumplikado Kapag Nagdidisenyo ng Mga Software System

Ano ang lahat ng ito?

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.

Ano ang Cross-Cutting Concern?

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.

Pag-uuri ng mga Aspekto

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.

Makro Aspekto

Istruktura ng organisasyon

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.

Malaking Bola ng Putik

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.

Arkitektura ng system

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:

1. Monolithic na arkitektura

2. Disenyong batay sa domain

3. Nakabatay sa bahagi

4. Mga microservice

5. Pipe at mga filter

6. Dahil sa kaganapan

7. Microkernel

8. 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:

1. Halos palaging nagsisimula sa monolitikong istilo ng arkitektura dahil inaalis nito ang karamihan sa mga problemang lumitaw dahil sa likas na katangian ng mga distributed system. Makatuwiran din na sundin ang modular monolith upang tumuon sa pagbuo ng mga bahagi na may malinaw na mga hangganan. Ang paglalapat ng isang component-based na diskarte ay maaaring makatulong sa kanila na makipag-usap sa isa't isa sa pamamagitan ng paggamit ng mga kaganapan, ngunit ang pagkakaroon ng mga direktang tawag (aka RPC) ay nagpapasimple sa mga bagay sa simula. Gayunpaman, mahalagang subaybayan ang mga dependency sa pagitan ng mga bahagi dahil kung ang component A ay maraming alam tungkol sa component B, marahil, makatuwirang pagsamahin ang mga ito sa isa.
2. Kapag lumalapit ka sa sitwasyon kung kailan kailangan mong sukatin ang iyong pag-unlad at system, maaari mong isaalang-alang ang pagsunod sa pattern ng Stangler upang unti-unting kunin ang mga bahagi na kailangang i-deploy nang nakapag-iisa o kahit na i-scale sa mga partikular na kinakailangan.
3. Ngayon, kung mayroon kang malinaw na pananaw sa hinaharap, na medyo hindi kapani-paniwalang swerte, maaari kang magpasya sa nais na arkitektura. Sa sandaling ito, maaari kang magpasya sa paglipat patungo sa arkitektura ng microservices sa pamamagitan ng paglalapat din ng mga diskarte sa Orchestration at Choreography, pagsasama ng pattern ng CQRS para sa mga independent scale write at read operations, o kahit na magpasya na manatili sa monolithic architecture kung umaangkop ito sa iyong mga pangangailangan.

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.

Pagpili ng stack ng teknolohiya

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:

• Mga kinakailangan at pagiging kumplikado ng proyekto. Halimbawa, ang isang simpleng web application ay maaaring itayo gamit ang Blazor framework kung ang iyong mga developer ay may karanasan dito, ngunit dahil sa kakulangan ng pagiging mature ng WebAssembly, ang pagpili ng React at Typescript para sa pangmatagalang tagumpay ay maaaring maging isang mas mahusay na desisyon
• Scalability at Mga Pangangailangan sa Pagganap. Kung inaasahan mong makatanggap ng malaking dami ng trapiko, ang pagpili para sa ASP.NET Core sa Django ay maaaring maging isang matalinong pagpipilian dahil sa mahusay nitong pagganap sa paghawak ng mga sabay-sabay na kahilingan. Gayunpaman, ang desisyong ito ay nakasalalay sa laki ng trapiko na iyong inaasahan. Kung kailangan mong pamahalaan ang potensyal na bilyun-bilyong kahilingan na may mababang latency, maaaring maging isang hamon ang pagkakaroon ng Garbage Collection.
• Pag-hire, Oras ng Pag-unlad, at Gastos. Sa karamihan ng mga kaso, ito ang mga salik na kailangan nating pangalagaan. Ang Oras sa Market, Gastos sa Pagpapanatili, at Katatagan ng Pag-hire ay nagtutulak sa iyong mga pangangailangan sa negosyo nang walang mga hadlang.
• Dalubhasa at Mga Mapagkukunan ng Koponan. Ang hanay ng kasanayan ng iyong development team ay isang kritikal na salik. Sa pangkalahatan, mas epektibong gumamit ng mga teknolohiya na pamilyar na sa iyong koponan maliban kung may matibay na dahilan para mamuhunan sa pag-aaral ng bagong stack.
• Pagkamagulang. Ang isang malakas na komunidad at isang mayamang ecosystem ng mga aklatan at tool ay lubos na makakapagpadali sa proseso ng pag-unlad. Ang mga sikat na teknolohiya ay kadalasang may mas mahusay na suporta sa komunidad, na maaaring maging napakahalaga para sa paglutas ng mga problema at paghahanap ng mga mapagkukunan. Kaya, maaari mong i-save ang mga mapagkukunan at tumutok pangunahin sa produkto.
• Pangmatagalang Pagpapanatili at Suporta. Isaalang-alang ang pangmatagalang kakayahang mabuhay ng teknolohiya. Ang mga teknolohiyang malawakang ginagamit at sinusuportahan ay mas malamang na maging lipas na at sa pangkalahatan ay tumatanggap ng mga regular na update at pagpapahusay.

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.

Single Point of Failure (SPOF)

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:

1. Redundancy. Ipatupad ang redundancy para sa mga kritikal na bahagi. Nangangahulugan ito ng pagkakaroon ng mga backup na bahagi na maaaring pumalit kung nabigo ang pangunahing bahagi. Maaaring ilapat ang redundancy sa iba't ibang layer ng system, kabilang ang hardware (server, disk), networking (link, switch), at software (mga database, application server). Kung ikaw ay nagho-host ng lahat sa isang Cloud Provider at kahit na may mga backup doon, isaalang-alang ang pagbuo ng isang regular na karagdagang backup sa isa pa upang mabawasan ang iyong nawalang gastos sa kaso ng sakuna.
2. Mga Data Center. Ipamahagi ang iyong system sa maraming pisikal na lokasyon, gaya ng mga data center o cloud region. Pinoprotektahan ng diskarteng ito ang iyong system laban sa mga pagkabigo na partikular sa lokasyon tulad ng pagkawala ng kuryente o natural na sakuna.
3. Failover. Mag-apply ng failover approach para sa lahat ng iyong component (DNS, CDN, Load balancers, Kubernetes, API Gateways, at Databases). Dahil maaaring lumitaw ang mga isyu nang hindi inaasahan, mahalagang magkaroon ng backup na plano upang palitan ang anumang bahagi ng clone nito kung kinakailangan nang mabilis.
4. Mga serbisyong mataas ang availability. Tiyakin na ang iyong mga serbisyo ay binuo upang maging pahalang na nasusukat at lubos na magagamit mula sa simula sa pamamagitan ng pagsunod sa mga sumusunod na prinsipyo:
   • Magsanay ng statelessness ng serbisyo at iwasang mag-imbak ng mga session ng user sa mga in-memory na cache. Sa halip, gumamit ng distributed cache system, gaya ng Redis.
   • Iwasan ang pag-asa sa magkakasunod na pagkakasunud-sunod ng pagkonsumo ng mensahe kapag bumubuo ng lohika.
   • I-minimize ang paglabag sa mga pagbabago upang maiwasan ang pagkagambala sa mga consumer ng API. Kung posible, mag-opt para sa mga pabalik na katugmang pagbabago. Gayundin, isaalang-alang ang gastos dahil kung minsan, ang pagpapatupad ng paglabag sa pagbabago ay maaaring maging mas epektibo sa gastos.
   • Isama ang pagsasagawa ng paglipat sa pipeline ng deployment.
   • Magtatag ng isang diskarte para sa paghawak ng mga sabay-sabay na kahilingan.
   • Ipatupad ang pagtuklas ng serbisyo, pagsubaybay, at pag-log upang mapahusay ang pagiging maaasahan at pagmamasid.
   • Bumuo ng lohika ng negosyo upang maging idempotent, na kinikilala na ang mga pagkabigo sa network ay hindi maiiwasan.
5. Pagsusuri ng dependency. Regular na suriin at bawasan ang mga panlabas na dependency. Ang bawat panlabas na dependency ay maaaring magpakilala ng mga potensyal na SPOF, kaya mahalagang maunawaan at mabawasan ang mga panganib na ito.
6. Regular na pagbabahagi ng kaalaman. Huwag kalimutan ang kahalagahan ng pagpapalaganap ng kaalaman sa loob ng iyong organisasyon. Ang mga tao ay maaaring hindi mahuhulaan, at ang pag-asa sa isang indibidwal ay mapanganib. Hikayatin ang mga miyembro ng pangkat na i-digitize ang kanilang kaalaman sa pamamagitan ng dokumentasyon. Gayunpaman, maging maingat sa labis na pagdodokumento. Gumamit ng iba't ibang tool sa AI para pasimplehin ang prosesong ito.

Konklusyon

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!