![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Svaki dan, svaki trenutak tijekom naše inženjerske karijere susrećemo se s mnogo različitih problema različite složenosti i situacijama u kojima trebamo donijeti odluku ili je odgoditi zbog nedostatka podataka. Kad god gradimo nove usluge, gradimo infrastrukturu ili čak formiramo razvojne procese, dotičemo se golemog svijeta raznih izazova.
Zahtjevno je, a možda i nemoguće, nabrojati sve probleme. Na neke od ovih problema ćete se susresti samo ako radite u određenoj niši. S druge strane, postoje mnogi koje svi moramo razumjeti kako riješiti jer su ključni za izgradnju IT sustava. S velikom vjerojatnošću ćete ih susresti u svim projektima.
U ovom ću članku podijeliti svoja iskustva s nekim problemima na koje sam naišao pri izradi softverskih programa.
Ako pogledamo Wikipediju, pronaći ćemo sljedeću definiciju
U razvoju softvera orijentiranom na aspekte, međusektorski problemi su aspekti programa koji utječu na nekoliko modula, bez mogućnosti da budu zatvoreni u bilo koji od njih. Ovi problemi se često ne mogu jasno razdvojiti od ostatka sustava u dizajnu i implementaciji, i mogu rezultirati raspršivanjem (dupliciranjem koda), petljanjem (značajne ovisnosti između sustava) ili oboje.
Uvelike opisuje što je to, ali želim ga malo proširiti i pojednostaviti:
Međusektorski problem je koncept ili komponenta sustava/organizacije koja utječe (ili 'presijeca') mnoge druge dijelove.
Najbolji primjeri takvih problema su arhitektura sustava, bilježenje, sigurnost, upravljanje transakcijama, telemetrija, dizajn baze podataka i mnogi drugi. Razradit ćemo mnoge od njih kasnije u ovom članku.
Na razini koda, međusektorski problemi često se implementiraju pomoću tehnika kao što je aspektno orijentirano programiranje (AOP) , gdje su ti problemi modularizirani u zasebne komponente koje se mogu primijeniti u cijeloj aplikaciji. Time se poslovna logika drži izoliranom od ovih problema, čineći kod čitljivijim i lakšim za održavanje.
Postoji mnogo mogućih načina za klasificiranje aspekata njihovim segmentiranjem s različitim svojstvima poput opsega, veličine, funkcionalnosti, važnosti, cilja i drugih, ali u ovom ću članku koristiti jednostavnu klasifikaciju opsega. Pod ovim mislim kamo je ovaj specifični aspekt usmjeren, bilo da se radi o cijeloj organizaciji, određenom sustavu ili specifičnom elementu tog sustava.
Dakle, podijelit ću aspekte na makro i mikro .
Pod makro aspektom mislim uglavnom na razmatranja koja slijedimo za cijeli sustav kao što je odabrana arhitektura sustava i njegov dizajn (monolitni, mikroservisi, servisno orijentirana arhitektura), tehnološki stog, organizacijska struktura, itd. Makro aspekti se odnose uglavnom na stratešku i visoku razinu odluke.
U međuvremenu, mikro aspekt je mnogo bliži razini koda i razvoju. Na primjer, koji se okvir koristi za interakciju s bazom podataka, strukturu projekta mapa i klasa ili čak specifične uzorke dizajna objekata.
Iako ova klasifikacija nije idealna, pomaže u strukturiranju razumijevanja mogućih problema te važnosti i utjecaja rješenja koja na njih primjenjujemo.
U ovom članku, moj primarni fokus bit će na makro aspektima.
Kad sam tek počeo učiti o arhitekturi softvera, pročitao sam mnogo zanimljivih članaka o Conwayevom zakonu i njegovom utjecaju na organizacijsku strukturu. Pogotovo ovaj . Dakle, ovaj zakon to kaže
Svaka organizacija koja dizajnira sustav (široko definiran) proizvest će dizajn čija je struktura kopija komunikacijske strukture organizacije.
Uvijek sam vjerovao da je ovaj koncept doista vrlo univerzalan i da predstavlja Zlatno pravilo.
Zatim sam počeo učiti Erica Evansa o pristupu Domain-Driven Design (DDD) za modeliranje sustava. Eric Evans naglašava važnost identifikacije ograničenog konteksta. Ovaj koncept uključuje podjelu složenog modela domene na manje odjeljke kojima je lakše upravljati, a svaki sa svojim ograničenim skupom znanja. Ovaj pristup pomaže u učinkovitoj timskoj komunikaciji jer smanjuje potrebu za opsežnim poznavanjem cijele domene i minimizira promjenu konteksta, čineći razgovore učinkovitijima. Promjena konteksta najgora je stvar koja zahtijeva najviše resursa. Čak se i računala bore s tim. Iako je malo vjerojatno da će postići potpuni izostanak prebacivanja konteksta, smatram da je to ono čemu bismo trebali težiti.
Vraćajući se na Conwayev zakon, naišao sam na nekoliko problema s njim.
Prvo pitanje s kojim sam se susreo kod Conwayevog zakona, koji sugerira da dizajn sustava odražava organizacijsku strukturu, je potencijal za formiranje složenih i sveobuhvatnih ograničenih konteksta. Ova složenost nastaje kada organizacijska struktura nije usklađena s granicama domene, što dovodi do ograničenih konteksta koji su u velikoj mjeri međuovisni i krcati informacijama. To dovodi do čestog mijenjanja konteksta za razvojni tim.
Drugi problem je da organizacijska terminologija curi na razinu koda. Kada se organizacijske strukture mijenjaju, to zahtijeva modifikacije baze koda, trošeći vrijedne resurse.
Stoga, slijeđenje inverznog Conwayevog manevra pomaže u izgradnji sustava i organizacije koji potiču željenu softversku arhitekturu. Međutim, važno je reći da ovaj pristup neće dobro funkcionirati u već formiranoj arhitekturi i strukturama budući da su promjene u ovoj fazi dugotrajne, ali je iznimno uspješan u startupima jer oni brzo uvode bilo kakve promjene.
Ovaj obrazac ili "anti-obrazac" pokreće izgradnju sustava bez ikakve arhitekture. Nema pravila, granica i strategije o tome kako kontrolirati neizbježnu rastuću složenost. Složenost je najstrašniji neprijatelj na putu izgradnje softverskih sustava.
Kako bismo izbjegli izgradnju takve vrste sustava, moramo slijediti određena pravila i ograničenja.
Postoje bezbrojne definicije za softversku arhitekturu. Mnogi od njih mi se sviđaju jer pokrivaju različite aspekte toga. Međutim, da bismo mogli rasuđivati o arhitekturi, moramo prirodno oblikovati neke od njih u našim umovima. I vrijedno je pažnje reći da se ova definicija može razvijati. Dakle, barem za sada, za sebe imam sljedeći opis.
Softverska arhitektura odnosi se na odluke i izbore koje donosite svaki dan, a koje utječu na izgrađeni sustav.
Za donošenje odluka morate imati u svojoj “torbi” načela i obrasce za rješavanje nastalih problema, također je bitno navesti da je razumijevanje zahtjeva ključno za izgradnju onoga što poduzeću treba. Međutim, ponekad zahtjevi nisu transparentni ili čak nisu definirani, u ovom slučaju, bolje je pričekati da dobijete dodatna pojašnjenja ili se osloniti na svoje iskustvo i vjerovati svojoj intuiciji. Ali svejedno, ne možete donositi odluke kako treba ako nemate principe i obrasce na koje se možete osloniti. Tu dolazim do definicije stila softverske arhitekture.
Stil arhitekture softvera je skup principa i obrazaca koji određuju kako izgraditi softver.
Postoji mnogo različitih arhitektonskih stilova usmjerenih na različite strane planirane arhitekture, a primjena više njih odjednom je normalna situacija.
Na primjer, kao što su:
Monolitna arhitektura
Dizajn usmjeren na domenu
Na temelju komponenti
Mikroservisi
Cijev i filteri
Vođen događajima
Mikrojezgra
Orijentiran na usluge
i tako dalje…
Naravno, imaju svoje prednosti i nedostatke, ali najvažnije što sam naučio jest da se arhitektura razvija postupno ovisno o stvarnim problemima. Započinjanje s monolitnom arhitekturom odličan je izbor za smanjenje operativnih složenosti, vrlo vjerojatno će ova arhitektura odgovarati vašim potrebama čak i nakon dostizanja faze prilagođavanja proizvoda tržištu (PMI) u izgradnji proizvoda. U razmjeru, možete razmisliti o prelasku na pristup vođen događajima i mikroservisima za postizanje neovisne implementacije, heterogenog okruženja tehnološkog skupa i manje povezane arhitekture (i manje transparentne u međuvremenu zbog prirode pristupa vođenih događajima i pub-sub pristupa ako te se usvajaju). Jednostavnost i učinkovitost su bliske i imaju veliki utjecaj jedna na drugu. Obično komplicirane arhitekture utječu na brzinu razvoja novih značajki, podržavaju i održavaju postojeće i osporavaju prirodnu evoluciju sustava.
Međutim, složeni sustavi često zahtijevaju složenu i sveobuhvatnu arhitekturu, što je neizbježno.
Iskreno, ovo je vrlo široka tema i postoji mnogo sjajnih ideja o tome kako strukturirati i izgraditi sustave za prirodnu evoluciju. Na temelju svog iskustva razradio sam sljedeći pristup:
Također je bitno razumjeti brojke i metrike kao što su DAU (Dnevni aktivni korisnici), MAU (Mjesečni aktivni korisnici), RPC (Zahtjevi po sekundi) i TPC (Transakcije po sekundi) jer bi vam to moglo pomoći u donošenju odluka jer arhitektura za 100 aktivnih korisnika i 100 milijuna aktivnih korisnika razlikuju se.
Za kraj bih rekao da arhitektura ima značajan utjecaj na uspjeh proizvoda. U skaliranju je potrebna loše dizajnirana arhitektura za proizvode, što vrlo vjerojatno dovodi do neuspjeha jer korisnici neće čekati dok skalirate sustav, oni ć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ć skaliran sustav. S druge strane, posjedovanje vrlo kompliciranog i već skaliranog sustava bez kupaca ili planova za njihovo pridobijanje neće vas koštati novca za vaše poslovanje uzalud.
Odabir tehnološkog skupa također je odluka na makrorazini budući da utječe na zapošljavanje, perspektive prirodne evolucije sustava, skalabilnost i performanse sustava.
Ovo je popis osnovnih razmatranja za odabir tehnološkog skupa:
Kako bi višestruki tehnološki paketi mogli utjecati na rast poslovanja?
Iz jedne perspektive, uvođenje još jednog skupa moglo bi povećati vaše zapošljavanje, ali s druge strane, donosi dodatne troškove održavanja budući da morate podržavati oba skupa. Dakle, kao što sam već rekao, s moje točke gledišta, samo bi dodatna potreba trebala biti argument za uključivanje više tehnoloških skupova.
Ali što je s principom odabira najboljeg alata za određeni problem?
Ponekad nemate drugog izbora nego donijeti nove alate za rješavanje određenog problema na temelju istih prethodno navedenih razmatranja, u takvim slučajevima ima smisla odabrati najbolje rješenje.
Stvaranje sustava bez visoke sprege s određenom tehnologijom moglo bi biti izazov. Ipak, korisno je težiti stanju u kojem sustav nije usko povezan s tehnologijom i neće umrijeti ako sutra određeni okvir ili alat postane ranjiv ili čak zastario.
Još jedno važno razmatranje povezano je s ovisnostima o otvorenom i vlasničkom softveru. Vlasnički softver daje vam manje fleksibilnosti i mogućnost prilagodbe. Ipak, najopasniji čimbenik je vezanost dobavljača, gdje postajete ovisni o proizvodima dobavljača, cijenama, uvjetima i planu. To može biti rizično ako prodavač promijeni smjer, poveća cijene ili ukine proizvod. Softver otvorenog koda smanjuje ovaj rizik jer ga ne kontrolira jedan entitet. Uklanjanje jedne točke kvara na svim razinama ključ je za izgradnju pouzdanih sustava za rast.
Jedna točka kvara (SPOF) odnosi se na bilo koji dio sustava koji će, ako zakaže, uzrokovati prestanak rada cijelog sustava. Uklanjanje SPOF-ova na svim razinama ključno je za bilo koji sustav koji zahtijeva visoku dostupnost. Sve, uključujući znanje, osoblje, komponente sustava, cloud providere i internetske kablove, može zakazati.
Postoji nekoliko osnovnih tehnika koje bismo mogli primijeniti za uklanjanje pojedinačnih točaka kvara:
U ovom smo članku pokrili nekoliko ključnih makroaspekata i kako se možemo nositi s njihovom složenošću.
Hvala vam na čitanju! Vidimo se sljedeći put!