![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Svakog dana, svakog trenutka u toku naše inženjerske karijere, susrećemo se s mnogo različitih problema različite složenosti i situacija u kojima moramo donijeti odluku ili je odgoditi zbog nedostatka podataka. Kad god gradimo nove usluge, gradimo infrastrukturu ili čak formiramo razvojne procese, dodirujemo ogroman svijet raznih izazova.
Izazovno je, a možda čak i nemoguće, nabrojati sve probleme. Na neke od ovih problema naići ćete samo ako radite u određenoj niši. S druge strane, postoji mnogo toga koje svi moramo razumjeti kako riješiti, jer su oni ključni za izgradnju IT sistema. Sa velikom vjerovatnoćom ćete ih susresti u svim projektima.
U ovom članku ću podijeliti svoja iskustva s nekim problemima s kojima sam se susreo prilikom izrade softverskih programa.
Ako pogledamo Wikipediju, naći ćemo sljedeću definiciju
U aspektno orijentisanom razvoju softvera, sveobuhvatna pitanja su aspekti programa koji utiču na nekoliko modula, bez mogućnosti da budu inkapsulirani u bilo koji od njih. Ovi problemi se često ne mogu jasno razdvojiti od ostatka sistema iu dizajnu i u implementaciji, i mogu rezultirati ili raspršivanjem (dupliciranje koda), zapetljavanjem (značajne zavisnosti između sistema) ili oboje.
U velikoj meri opisuje šta je to, ali želim da ga malo proširim i pojednostavim:
Međusektorska briga je koncept ili komponenta sistema/organizacije koja utiče (ili 'presijeca') mnoge druge dijelove.
Najbolji primjeri takvih briga su arhitektura sistema, evidentiranje, sigurnost, upravljanje transakcijama, telemetrija, dizajn baze podataka i mnogi drugi. Kasnije ćemo u ovom članku elaborirati mnoge od njih.
Na nivou koda, sveobuhvatni problemi se često implementiraju korištenjem tehnika kao što je Aspect-Oriented Programming (AOP) , gdje su ovi problemi modularizirani u zasebne komponente koje se mogu primijeniti u cijeloj aplikaciji. Ovo drži poslovnu logiku izolovanom od ovih briga, čineći kod čitljivijim i održivijim.
Postoji mnogo mogućih načina kako da klasifikujete aspekte tako što ćete ih segmentirati različitim svojstvima kao što su opseg, veličina, funkcionalnost, važnost, cilj i drugi, ali u ovom članku ću koristiti jednostavnu klasifikaciju opsega. Pod ovim mislim gdje je usmjeren ovaj specifični aspekt, bilo da se radi o cijeloj organizaciji, određenom sistemu ili specifičnom elementu tog sistema.
Dakle, podijelit ću aspekte na Makro i Mikro .
Pod makro aspektom mislim uglavnom na razmatranja koja slijedimo za cijeli sistem kao što su odabrana arhitektura sistema i njegov dizajn (monolitna, mikroservisna, servisno orijentirana arhitektura), tehnološki stack, organizacijska struktura, itd. Makro aspekti se uglavnom odnose na strateški i visoki nivo odluke.
U međuvremenu, mikro aspekt je mnogo bliži nivou koda i razvoju. Na primjer, koji okvir se koristi za interakciju sa bazom podataka, strukturu projekta fascikli i klasa, ili čak specifične obrasce dizajna objekata.
Iako ova klasifikacija nije idealna, ona pomaže u strukturiranju razumijevanja mogućih problema i važnosti i utjecaja rješenja koja primjenjujemo na njih.
U ovom članku, moj primarni fokus će biti na makro aspektima.
Kada sam tek počeo da učim o softverskoj arhitekturi, pročitao sam mnogo zanimljivih članaka o Konvejevom zakonu i njegovom uticaju na organizacionu strukturu. Posebno ovaj . Dakle, ovaj zakon to kaže
Svaka organizacija koja dizajnira sistem (široko definisan) će proizvesti dizajn čija je struktura kopija komunikacijske strukture organizacije.
Oduvijek sam vjerovao da je ovaj koncept zaista vrlo univerzalan i da predstavlja Zlatno pravilo.
Zatim sam počeo da učim pristup dizajnu vođenom domenom (DDD) Erica Evansa za modeliranje sistema. Eric Evans naglašava važnost identifikacije ograničenog konteksta. Ovaj koncept uključuje podelu kompleksnog modela domena na manje delove kojima se lakše upravlja, svaki sa svojim ograničenim skupom znanja. Ovaj pristup pomaže u efikasnoj timskoj komunikaciji, jer smanjuje potrebu za opsežnim znanjem o cijeloj domeni i minimizira promjenu konteksta, čime razgovore čini efikasnijim. Prebacivanje konteksta je najgora stvar i koja zahtijeva najviše resursa. Čak se i računari bore s tim. Iako je malo vjerovatno da ćemo postići potpuno odsustvo promjene konteksta, mislim da je to ono čemu bismo trebali težiti.
Vraćajući se na Conwayev zakon, našao sam nekoliko problema s njim.
Prvi problem sa kojim sam se susreo sa Konvejevim zakonom, koji sugeriše da dizajn sistema odražava organizacionu strukturu, je potencijal za formiranje složenih i sveobuhvatnih ograničenih konteksta. Ova složenost nastaje kada organizacijska struktura nije usklađena s granicama domena, što dovodi do ograničenih konteksta koji su u velikoj mjeri međusobno zavisni i opterećeni informacijama. To dovodi do čestog mijenjanja konteksta za razvojni tim.
Drugi problem je što organizacijska terminologija curi na nivo koda. Kada se organizacijske strukture mijenjaju, to zahtijeva modifikacije kodne baze, trošeći vrijedne resurse.
Stoga, praćenje Inverznog Conway manevra pomaže u izgradnji sistema i organizacije koji podstiču željenu arhitekturu softvera. Međutim, važno je napomenuti da ovaj pristup neće dobro funkcionirati u već formiranoj arhitekturi i strukturama jer su promjene u ovoj fazi dugotrajne, ali je izuzetno efikasan u startupima jer brzo uvode bilo kakve promjene.
Ovaj obrazac ili „anti-pattern“ pokreće izgradnju sistema bez ikakve arhitekture. Nema pravila, nema granica i nema strategije kako da kontrolišete neizbežno rastuću složenost. Složenost je najstrašniji neprijatelj na putu izgradnje softverskih sistema.
Da bismo izbjegli konstruiranje takvog tipa sistema, moramo slijediti određena pravila i ograničenja.
Postoji bezbroj definicija za softversku arhitekturu. Mnogi od njih mi se sviđaju jer pokrivaju različite aspekte toga. Međutim, da bismo mogli razmišljati o arhitekturi, moramo prirodno da formiramo neke od njih u svom umu. I vrijedno je napomenuti da se ova definicija može razvijati. Tako da, barem za sada, imam za sebe sljedeći opis.
Arhitektura softvera se odnosi na odluke i izbore koje donosite svaki dan i koji utiču na izgrađen sistem.
Da biste donijeli odluke koje trebate imati u svojoj „torbi“ principe i obrasce za rješavanje nastalih problema, također je bitno navesti da je razumijevanje zahtjeva ključno za izgradnju onoga što je poslovnom potrebno. Međutim, ponekad zahtjevi nisu transparentni ili čak nisu definirani, u ovom slučaju je bolje pričekati da dobijete dodatna pojašnjenja ili se osloniti na svoje iskustvo i vjerovati svojoj intuiciji. Ali u svakom slučaju, ne možete pravilno donositi odluke ako nemate principe i obrasce na koje se možete osloniti. Tu dolazim do definicije stila softverske arhitekture.
Stil softverske arhitekture je skup principa i obrazaca koji određuju kako se pravi softver.
Postoji mnogo različitih arhitektonskih stilova fokusiranih na različite strane planirane arhitekture, a primjena više njih odjednom je normalna situacija.
Na primjer, kao što su:
Monolitna arhitektura
Dizajn vođen domenom
Komponentni
Mikrousluge
Cijevi i filteri
Događaj-driven
Microkernel
Servisno orijentisan
i tako dalje…
Naravno, oni imaju svoje prednosti i nedostatke, ali najvažnija stvar koju sam naučio je da se arhitektura postepeno razvija ovisno o stvarnim problemima. Počevši od monolitne arhitekture je odličan izbor za smanjenje operativnih složenosti, vrlo je vjerovatno da će ova arhitektura odgovarati vašim potrebama čak i nakon dostizanja faze prilagođavanja tržištu proizvoda (PMI) izgradnje proizvoda. U velikoj mjeri, možete razmisliti o prelasku na pristup vođen događajima i mikrousluge za postizanje neovisne implementacije, heterogenog tehničkog steka okruženja i manje povezane arhitekture (i manje transparentne u međuvremenu zbog prirode pristupa vođenih događajima i pub-sub pristupa ako ovi se usvajaju). Jednostavnost i efikasnost su bliske i imaju veliki uticaj jedna na drugu. Obično komplikovane arhitekture utiču na brzinu razvoja novih karakteristika, podržavajući i održavajući postojeće, i izazivajući prirodnu evoluciju sistema.
Međutim, složeni sistemi često zahtevaju složenu i sveobuhvatnu arhitekturu, što je neizbežno.
Iskreno, ovo je veoma široka tema i postoji mnogo sjajnih ideja o tome kako strukturirati i izgraditi sisteme za prirodnu evoluciju. Na osnovu svog iskustva, razradio sam sljedeći pristup:
Također je od vitalnog značaja razumjeti brojeve i metriku kao što su DAU (Dnevno aktivni korisnici), MAU (Mjesečno aktivni korisnici), RPC (Zahtjev u sekundi) i TPC (Transakcija u sekundi) jer bi vam to moglo pomoći da donesete odluke jer arhitektura za 100 aktivnih korisnika i 100 miliona aktivnih korisnika se razlikuju.
Kao završnu napomenu, rekao bih da arhitektura ima značajan uticaj na uspeh proizvoda. U skaliranju je potrebna loše dizajnirana arhitektura za proizvode, što vrlo vjerovatno dovodi do neuspjeha jer kupci neće čekati dok skalirate sistem, već će izabrati konkurenta, tako da moramo biti ispred potencijalnog skaliranja. Iako priznajem da ponekad to ne može biti lean pristup, ideja je imati skalabilan, ali ne već skalirani sistem. S druge strane, posjedovanje vrlo komplikovanog i već skaliranog sistema bez kupaca ili planova da dobijete mnoge od njih koštat će vas novca za vaše poslovanje uzalud.
Odabir tehnološkog steka je također odluka na makro nivou jer utiče na zapošljavanje, perspektive prirodne evolucije sistema, skalabilnost i performanse sistema.
Ovo je lista osnovnih razmatranja za odabir tehnološkog skupa:
Kako bi višestruka tehnologija mogla uticati na rast poslovanja?
Iz jedne perspektive, uvođenje još jedne grupe može povećati vaše zapošljavanje, ali s druge strane, to donosi dodatne troškove održavanja jer morate podržati oba steka. Dakle, kao što sam već rekao, po mom mišljenju, samo dodatna potreba bi trebala biti argument za uključivanje više tehnoloških stekova.
Ali šta je sa principom odabira najboljeg alata za određeni problem?
Ponekad nemate drugog izbora osim da donesete nove alate za rješavanje određenog problema na osnovu istih gore navedenih razmatranja, u takvim slučajevima ima smisla odabrati najbolje rješenje.
Stvaranje sistema bez visoke povezanosti sa specifičnom tehnologijom može biti izazov. Ipak, korisno je težiti stanju u kojem sistem nije čvrsto povezan s tehnologijom i neće umrijeti ako sutra određeni okvir ili alat postane ranjiv ili čak zastario.
Još jedno važno pitanje odnosi se na ovisnosti o otvorenom kodu i vlasničkim softverima. Vlasnički softver vam daje manju fleksibilnost i mogućnost prilagođavanja. Ipak, najopasniji faktor je zaključavanje dobavljača, gdje postajete ovisni o proizvodima, cijenama, uvjetima i planovima dobavljača. Ovo može biti rizično ako dobavljač promijeni smjer, poveća cijene ili prekine proizvod. Softver otvorenog koda smanjuje ovaj rizik, jer ga ne kontrolira jedan entitet. Eliminacija jedne tačke kvara na svim nivoima je ključ za izgradnju pouzdanih sistema za rast.
Pojedinačna tačka kvara (SPOF) se odnosi na bilo koji dio sistema koji će, ako zakaže, uzrokovati da cijeli sistem prestane funkcionirati. Eliminacija SPOF-ova na svim nivoima je ključna za svaki sistem koji zahteva visoku dostupnost. Sve, uključujući znanje, osoblje, sistemske komponente, cloud provajdere i internet kablove, može propasti.
Postoji nekoliko osnovnih tehnika koje možemo primijeniti da eliminišemo pojedinačne točke kvara:
U ovom članku pokrili smo nekoliko ključnih makro aspekata i kako se možemo nositi s njihovom složenošću.
Hvala na čitanju! Vidimo se sljedeći put!