![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Mérnöki pályafutásunk során nap mint nap, minden pillanatban sok különböző összetettségű és helyzetű problémával találkozunk, ahol döntést kell hoznunk, vagy adathiány miatt el kell halasztanunk. Amikor új szolgáltatásokat építünk, infrastruktúrát építünk, vagy akár fejlesztési folyamatokat alakítunk ki, különféle kihívások hatalmas világát érintjük.
Nehéz, sőt talán lehetetlen felsorolni az összes problémát. E problémák némelyikével csak akkor találkozhat, ha egy adott résben dolgozik. Másrészt sok olyan probléma van, amelyeket mindannyiunknak meg kell értenünk, hogyan kell megoldani, mivel ezek döntő fontosságúak az informatikai rendszerek felépítésében. Nagy valószínűséggel minden projektben találkozni fog velük.
Ebben a cikkben megosztom tapasztalataimat néhány olyan problémával kapcsolatban, amelyekkel szoftverprogramok létrehozása során találkoztam.
Ha belenézünk a Wikipédiába, a következő definíciót találjuk
Az aspektus-orientált szoftverfejlesztésben az átfogó szempontok a program olyan aspektusai, amelyek több modult érintenek anélkül, hogy bármelyik modulba beágyazódnának. Ezeket az aggályokat gyakran nem lehet tisztán lebontani a rendszer többi részéből sem a tervezés, sem a megvalósítás során, és szóródáshoz (kódduplikáció), összegabalyodáshoz (a rendszerek közötti jelentős függőségek), vagy mindkettőhöz vezethetnek.
Nagyon jól leírja, hogy mi ez, de szeretném egy kicsit kiterjeszteni és leegyszerűsíteni:
A több területet átfogó aggály a rendszer/szervezet olyan koncepciója vagy összetevője, amely számos más részt érint (vagy „átvág”).
Az ilyen aggályok legjobb példái a rendszerarchitektúra, naplózás, biztonság, tranzakciókezelés, telemetria, adatbázis-tervezés és még sok más. A cikk későbbi részében ezek közül sokat fogunk részletesebben kifejteni.
A kód szintjén az átfogó szempontokat gyakran olyan technikák segítségével valósítják meg, mint például az aspektus-orientált programozás (AOP) , ahol ezek az aggályok különálló komponensekké modulárisak, amelyek az egész alkalmazásban alkalmazhatók. Ez elszigeteli az üzleti logikát ezektől a problémáktól, így a kód olvashatóbbá és karbantarthatóbbá válik.
Számos lehetséges módszer létezik a szempontok osztályozására úgy, hogy különböző tulajdonságokkal, például hatókörrel, mérettel, funkcionalitással, fontossággal, céllal és egyebekkel szegmentálja őket, de ebben a cikkben egy egyszerű hatókör-besorolást fogok használni. Ez alatt azt értem, hogy hova irányul ez a konkrét szempont, legyen szó akár az egész szervezetről, egy adott rendszerről, vagy annak egy meghatározott eleméről.
Tehát a szempontokat makróra és mikrora fogom felosztani.
Makrószempont alatt elsősorban azokat a megfontolásokat értem, amelyeket a rendszer egészére vonatkozóan követünk, mint a választott rendszerarchitektúra és annak kialakítása (monolit, mikroszolgáltatások, szolgáltatás-orientált architektúra), technológiai stack, szervezeti struktúra stb. A makroszempontok elsősorban a stratégiai és magas szintű szempontokhoz kapcsolódnak döntéseket.
Mindeközben a Micro aspektus sokkal közelebb áll a kódszinthez és a fejlesztéshez. Például, hogy melyik keretrendszert használjuk az adatbázissal való interakcióhoz, a mappák és osztályok projektstruktúráját, vagy akár konkrét objektumtervezési mintákat.
Bár ez a besorolás nem ideális, segít a lehetséges problémák, valamint a rájuk alkalmazott megoldások fontosságának és hatásának megértésében.
Ebben a cikkben elsősorban a makroszempontokra összpontosítok.
Amikor csak elkezdtem tanulni a szoftverarchitektúráról, sok érdekes cikket olvastam a Conway-törvényről és annak a szervezeti struktúrára gyakorolt hatásáról. Főleg ezt . Tehát ez a törvény kimondja
Minden szervezet, amely rendszert tervez (tág értelemben), olyan tervet készít, amelynek szerkezete a szervezet kommunikációs struktúrájának másolata.
Mindig is azt hittem, hogy ez a fogalom valóban nagyon univerzális, és az aranyszabályt képviseli.
Aztán elkezdtem tanulni Eric Evans Domain-Driven Design (DDD) megközelítését modellezési rendszerekre. Eric Evans hangsúlyozza a Bounded Context azonosítás fontosságát. Ez a koncepció magában foglalja egy összetett tartománymodell felosztását kisebb, jobban kezelhető szakaszokra, amelyek mindegyike saját korlátozott tudáskészlettel rendelkezik. Ez a megközelítés segíti a hatékony csapatkommunikációt, mivel csökkenti a teljes tartomány széles körű ismeretének szükségességét, és minimalizálja a kontextusváltást, ezáltal hatékonyabbá teszi a beszélgetéseket. A kontextusváltás a valaha volt legrosszabb és leginkább erőforrásigényes dolog. Még a számítógépek is küzdenek vele. Bár nem valószínű, hogy a kontextusváltás teljes hiányát elérjük, úgy gondolom, hogy erre kell törekednünk.
Visszatérve Conway törvényéhez, több problémát is találtam vele kapcsolatban.
Az első probléma, amellyel a Conway-törvénnyel találkoztam, amely azt sugallja, hogy a rendszertervezés tükrözi a szervezeti struktúrát, az összetett és átfogó, határos kontextusok kialakításának lehetősége. Ez a bonyolultság akkor merül fel, ha a szervezeti struktúra nincs összhangban a tartomány határaival, ami határos kontextusokhoz vezet, amelyek erősen függenek egymástól és tele vannak információval. Ez gyakori kontextusváltáshoz vezet a fejlesztőcsapat számára.
Egy másik probléma , hogy a szervezeti terminológia a kód szintjére szivárog. Amikor a szervezeti struktúrák megváltoznak, ez kódbázis módosításokat tesz szükségessé, ami értékes erőforrásokat emészt fel.
Így az Inverse Conway Maneuver követése segít felépíteni azt a rendszert és szervezetet, amely elősegíti a kívánt szoftverarchitektúrát. Figyelemre méltó azonban, hogy ez a megközelítés nem működik túl jól a már kialakult architektúrában és struktúrákban, mivel a változások ebben a szakaszban elhúzódnak, de az induló vállalkozásoknál kivételesen teljesít, mivel gyorsan bevezetik a változtatásokat.
Ez a minta vagy „anti-minta” egy rendszer felépítését hajtja végre architektúra nélkül. Nincsenek szabályok, nincsenek határok, és nincs stratégia az elkerülhetetlenül növekvő összetettség ellenőrzésére. A komplexitás a szoftverrendszerek felépítésének legfélelmetesebb ellensége.
Ahhoz, hogy elkerüljük az ilyen típusú rendszer felépítését, meghatározott szabályokat és megszorításokat kell követnünk.
A szoftverarchitektúrára számtalan definíció létezik. Sokukat szeretem, mivel különböző szempontokat fednek le. Ahhoz azonban, hogy érvelni tudjunk az építészetről, természetesen meg kell alkotnunk néhányat az elménkben. És érdemes megjegyezni, hogy ez a meghatározás változhat. Így legalább egyelőre megvan a következő leírás magamnak.
A szoftverarchitektúra azokról a döntésekről és döntésekről szól, amelyeket minden nap meghoz, és amelyek hatással vannak az épített rendszerre.
A döntések meghozatalához a felmerülő problémák megoldására vonatkozó elveknek és mintáknak a „táskájában” kell lenniük, és azt is alapvetően fontos kijelenteni, hogy a követelmények megértése kulcsfontosságú annak kialakításához, amire egy vállalkozásnak szüksége van. Néha azonban a követelmények nem átláthatóak, vagy nem is definiáltak, ebben az esetben jobb, ha megvárod a további felvilágosítást, vagy hagyatkozz a tapasztalatodra és bízz az intuíciódban. De különben is, nem tudsz megfelelően dönteni, ha nincsenek elveid és mintáid, amelyekre támaszkodhatsz. Itt jutok el a szoftverarchitektúra stílusának meghatározásához.
A Software Architecture Style olyan elvek és minták összessége, amelyek meghatározzák a szoftverek felépítését.
A tervezett építészet különböző oldalaira nagyon sok különböző építészeti stílus fókuszál, és ezek egyidejű alkalmazása normális helyzet.
Például, mint például:
Monolit építészet
Domain-vezérelt tervezés
Komponens alapú
Mikroszolgáltatások
Cső és szűrők
Eseményvezérelt
Mikrokernel
Szolgáltatás-orientált
és így tovább…
Természetesen megvannak a maguk előnyei és hátrányai, de a legfontosabb dolog, amit megtanultam, az az, hogy az építészet fokozatosan, a tényleges problémák függvényében fejlődik. A monolitikus architektúrától kezdve nagyszerű választás a működési bonyolultságok csökkentésére, nagy valószínűséggel ez az architektúra megfelel az Ön igényeinek még a termék felépítésének Product-market Fit (PMI) szakaszának elérése után is. Méretben megfontolhatja az eseményvezérelt megközelítés és a mikroszolgáltatások felé történő elmozdulást a független telepítés, a heterogén technológiai veremkörnyezet és a kevésbé csatolt architektúra elérése érdekében (és időközben kevésbé átlátható az eseményvezérelt és a pub-sub megközelítések természete miatt, ha ezeket elfogadják). Az egyszerűség és a hatékonyság közel áll egymáshoz, és nagy hatással vannak egymásra. Általában a bonyolult architektúrák befolyásolják az új funkciók fejlesztési sebességét, támogatják és fenntartják a meglévőket, és kihívást jelentenek a rendszer természetes fejlődésében.
Az összetett rendszerek azonban gyakran összetett és átfogó architektúrát igényelnek, ami elkerülhetetlen.
Valójában ez egy nagyon tág téma, és sok nagyszerű ötlet létezik a természetes evolúcióhoz szükséges rendszerek felépítéséről és felépítéséről. Tapasztalataim alapján a következő megközelítést dolgoztam ki:
Szintén létfontosságú az olyan számok és mutatók megértése, mint például a DAU (napi aktív felhasználók), a MAU (havi aktív felhasználók), az RPC (másodpercenkénti kérés) és a TPC (tranzakció per másodperc), mivel ezek segíthetnek a döntések meghozatalában, mivel az architektúra 100 aktív felhasználó és 100 millió aktív felhasználó különbözik.
Utolsó megjegyzésként azt szeretném mondani, hogy az architektúra jelentős hatással van a termék sikerére. A méretezésnél a termékek rosszul megtervezett architektúrájára van szükség, ami nagy valószínűséggel kudarchoz vezet, mivel az ügyfelek nem várnak, amíg te méretezed a rendszert, hanem versenytársat választanak, így előrébb kell lennünk a potenciális méretezéssel. Bár elismerem, hogy ez néha nem lehet lean megközelítés, az ötlet az, hogy legyen egy méretezhető, de még nem skálázott rendszer. Másrészt, ha egy nagyon bonyolult és már méretezhető rendszerrel rendelkezik anélkül, hogy ügyfelei vannak, vagy nem tervezi, hogy sokakat szerezzen be, az semmibe fog kerülni a vállalkozásának.
A technológiai köteg kiválasztása szintén makroszintű döntés, mivel befolyásolja a felvételt, a rendszer természetes fejlődési perspektíváit, a méretezhetőséget és a rendszer teljesítményét.
Íme a technológiai köteg kiválasztásának alapvető szempontjainak listája:
Hogyan befolyásolhatja az üzleti növekedést a több technológiai halom?
Egyrészt egy újabb köteg bevezetése növelheti a munkaerő-felvételt, másrészt viszont további karbantartási költségekkel jár, mivel mindkét köteget támogatnia kell. Tehát, ahogy korábban mondtam, véleményem szerint csak a plusz igény lehet érv több technológiai halom beépítése mellett.
De mi a helyzet az adott probléma legjobb eszközének kiválasztásával?
Néha nincs más választása, mint új eszközöket hozni egy adott probléma megoldására a fent említett szempontok alapján, ilyen esetekben érdemes a legjobb megoldást kiválasztani.
Kihívást jelenthet olyan rendszerek létrehozása, amelyek nem kapcsolódnak egy adott technológiához. Mégis érdemes olyan állapotra törekedni, ahol a rendszer nincs szorosan összekapcsolva a technológiával, és nem hal meg, ha holnap egy adott keretrendszer vagy eszköz sebezhetővé vagy akár elavulttá válik.
Egy másik fontos szempont a nyílt forráskódú és a védett szoftverek függőségei. A szabadalmaztatott szoftver kevesebb rugalmasságot és testreszabhatóságot biztosít. Mégis, a legveszélyesebb tényező a szállítói bezárkózás, amikor Ön függ a szállító termékeitől, áraitól, feltételeitől és ütemtervétől. Ez kockázatos lehet, ha az eladó irányt változtat, megemeli az árakat vagy leállítja a terméket. A nyílt forráskódú szoftver csökkenti ezt a kockázatot, mivel nem egyetlen entitás irányítja azt. Egyetlen hibapont kiküszöbölése minden szinten kulcsfontosságú a növekedést szolgáló megbízható rendszerek felépítéséhez.
Egyetlen hibapont (SPOF) a rendszer bármely olyan részére vonatkozik, amely meghibásodása esetén az egész rendszer működése leáll. Az SPOF-ok minden szinten történő kiküszöbölése kulcsfontosságú minden olyan rendszer esetében, amely magas rendelkezésre állást igényel. Minden, beleértve a tudást, a személyzetet, a rendszerelemeket, a felhőszolgáltatókat és az internetkábeleket, meghibásodhat.
Számos alapvető technikát alkalmazhatunk az egyes hibák kiküszöbölésére:
Ebben a cikkben számos kulcsfontosságú makró- szemponttal foglalkoztunk, és bemutattuk, hogyan kezeljük ezek összetettségét.
Köszönöm, hogy elolvastad! Találkozunk legközelebb!