Mistä siinä on kyse?  Joka päivä, joka hetki insinööriuramme aikana kohtaamme monia erilaisia ja monimutkaisia ongelmia ja tilanteita, joissa joudumme tekemään päätöksen tai lykkäämään sitä tiedon puutteen vuoksi. Aina kun rakennamme uusia palveluita, rakennamme infrastruktuuria tai jopa muodostamme kehitysprosesseja, kosketamme valtavaa erilaisten haasteiden maailmaa.  On haastavaa ja ehkä jopa mahdotonta luetella kaikkia ongelmia. Kohtaat joitakin näistä ongelmista vain, jos työskentelet tietyllä markkinaraolla. Toisaalta on monia asioita, jotka meidän kaikkien on ymmärrettävä ratkaistavaksi, koska ne ovat tärkeitä IT-järjestelmien rakentamisessa. Suurella todennäköisyydellä kohtaat niitä kaikissa projekteissa.  Tässä artikkelissa jaan kokemukseni joistakin ongelmista, joita olen kohdannut ohjelmistojen luomisen aikana.  Mikä on monialainen huoli?  Jos katsomme Wikipediaa, löydämme seuraavan määritelmän  Aspektisuuntautuneessa ohjelmistokehityksessä poikkileikkaushuolet ovat ohjelman näkökohtia, jotka vaikuttavat useisiin moduuleihin ilman mahdollisuutta kapseloitua mihinkään niistä. Näitä huolenaiheita ei useinkaan voida selkeästi hajottaa muusta järjestelmästä sekä suunnittelussa että toteutuksessa, ja ne voivat johtaa joko hajoamiseen (koodin monistaminen), sotkeutumiseen (merkittävistä riippuvuuksista järjestelmien välillä) tai molempiin.  Se kuvaa hyvin, mitä se on, mutta haluan laajentaa ja yksinkertaistaa sitä hieman:    on järjestelmän/organisaation käsite tai osa, joka vaikuttaa moniin muihin osiin (tai "kattaa"). Monialainen huolenaihe  Parhaita esimerkkejä tällaisista huolenaiheista ovat järjestelmäarkkitehtuuri, kirjaus, turvallisuus, tapahtumien hallinta, telemetria, tietokantojen suunnittelu ja monet muut. Aiomme käsitellä monia niistä myöhemmin tässä artikkelissa.  Kooditasolla monialaiset huolenaiheet toteutetaan usein käyttämällä tekniikoita, kuten   , jossa nämä huolenaiheet on modulisoitu erillisiksi komponenteiksi, joita voidaan soveltaa koko sovelluksessa. Tämä pitää liiketoimintalogiikan erillään näistä huolenaiheista, mikä tekee koodista luettavamman ja ylläpidettävämmän. AOP (Aspect-Oriented Programming)  Aspektien luokittelu  On monia mahdollisia tapoja luokitella aspekteja segmentoimalla ne eri ominaisuuksilla, kuten laajuus, koko, toiminnallisuus, tärkeys, kohde ja muut, mutta tässä artikkelissa aion käyttää yksinkertaista laajuusluokitusta. Tarkoitan tällä sitä, mihin tämä erityinen näkökohta on suunnattu, onko kyseessä koko organisaatio, tietty järjestelmä vai järjestelmän tietty osa.  Joten aion jakaa näkökohdat   ja   . makroon mikroon    tarkoitan pääasiassa koko järjestelmää koskevia huomioita, joita noudatamme, kuten valittu järjestelmäarkkitehtuuri ja sen suunnittelu (monoliittinen, mikropalvelut, palvelukeskeinen arkkitehtuuri), teknologiapino, organisaatiorakenne jne.   liittyvät pääasiassa strategiseen ja korkeaan tasoon. päätöksiä. Makronäkökohdalla Makronäkökohdat  Sillä välin   näkökulma on paljon lähempänä koodin tasoa ja kehitystä. Esimerkiksi mitä kehystä käytetään vuorovaikutukseen tietokannan kanssa, kansioiden ja luokkien projektirakennetta tai jopa tiettyjä objektisuunnittelumalleja. Micro-  Vaikka tämä luokittelu ei olekaan ihanteellinen, se auttaa jäsentämään ymmärrystä mahdollisista ongelmista ja niihin sovellettavien ratkaisujen tärkeydestä ja vaikutuksista.  Tässä artikkelissa keskityn ensisijaisesti makronäkökohtiin.  Makronäkökohdat  Organisaation rakenne  Kun aloin juuri oppia ohjelmistoarkkitehtuurista, luin monia mielenkiintoisia artikkeleita Conwayn laista ja sen vaikutuksesta organisaatiorakenteeseen. Varsinkin   . Tämä laki siis sanoo sen tämä  Jokainen organisaatio, joka suunnittelee järjestelmän (määriteltynä laajasti), tuottaa suunnittelun, jonka rakenne on kopio organisaation viestintärakenteesta.  Olen aina uskonut, että tämä käsite on todellakin hyvin universaali ja edustaa kultaista sääntöä.  Sitten aloin oppia Eric Evansin Domain-Driven Design (DDD) -lähestymistapaa järjestelmien mallintamiseen. Eric Evans korostaa rajatun kontekstin tunnistamisen merkitystä. Tämä konsepti sisältää monimutkaisen toimialueen mallin jakamisen pienempiin, paremmin hallittaviin osiin, joista jokaisella on omat rajalliset tietonsa. Tämä lähestymistapa auttaa tehokkaassa tiimiviestinnässä, koska se vähentää tarvetta saada laajaa tietoa koko toimialueesta ja minimoi kontekstin vaihtamisen, mikä tekee keskusteluista tehokkaampia. Kontekstin vaihtaminen on kaikkien aikojen pahin ja resursseja vievin asia. Jopa tietokoneet kamppailevat sen kanssa. Vaikka on epätodennäköistä, että kontekstin vaihtamisen täydellistä puuttumista ei saavuteta, siihen meidän pitäisi mielestäni pyrkiä.   Palatakseni Conwayn lakiin, olen löytänyt sen kanssa useita ongelmia.    jonka olen kohdannut Conwayn laissa, joka ehdottaa, että järjestelmän suunnittelu heijastelee organisaatiorakennetta, on mahdollisuus muodostaa monimutkaisia ja kattavia rajattuja konteksteja. Tämä monimutkaisuus syntyy, kun organisaatiorakenne ei ole linjassa toimialueen rajojen kanssa, mikä johtaa rajallisiin konteksteihin, jotka ovat voimakkaasti riippuvaisia toisistaan ja täynnä tietoa. Se johtaa usein kehitystiimin kontekstin vaihtamiseen. Ensimmäinen ongelma,    on, että organisaation terminologia vuotaa kooditasolle. Kun organisaatiorakenteet muuttuvat, se edellyttää koodikannan muutoksia, mikä kuluttaa arvokkaita resursseja. Toinen ongelma  Siten   seuraaminen auttaa rakentamaan järjestelmän ja organisaation, jotka edistävät haluttua ohjelmistoarkkitehtuuria. On kuitenkin huomionarvoista sanoa, että tämä lähestymistapa ei toimi kovin hyvin jo muodostuneessa arkkitehtuurissa ja rakenteissa, koska muutokset tässä vaiheessa pitkittyvät, mutta se toimii poikkeuksellisen hyvin startupeissa, koska ne ovat nopeita tekemään muutoksia. Inverse Conway Maneuverin  Suuri mutapallo  Tämä malli tai "anti-kuvio" ajaa järjestelmän rakentamista ilman arkkitehtuuria. Ei ole sääntöjä, ei rajoja eikä strategiaa väistämättömän kasvavan monimutkaisuuden hallitsemiseksi. Monimutkaisuus on ohjelmistojärjestelmien rakentamisen pahin vihollinen.   Välttääksemme rakentamasta tällaista järjestelmää, meidän on noudatettava erityisiä sääntöjä ja rajoituksia.  Järjestelmän arkkitehtuuri  Ohjelmistoarkkitehtuurille on olemassa lukemattomia määritelmiä. Pidän monista niistä, koska ne kattavat sen eri puolia. Kuitenkin, jotta voimme perustella arkkitehtuuria, meidän on luonnollisesti muodostettava niitä mielessämme. Ja on huomionarvoista sanoa, että tämä määritelmä voi kehittyä. Joten ainakin toistaiseksi minulla on seuraava kuvaus itselleni.    on kyse päätöksistä ja valinnoista, joita teet joka päivä ja jotka vaikuttavat rakennettuun järjestelmään. Ohjelmistoarkkitehtuurissa  Tehdäksesi päätöksiä, jotka tarvitsevat "laukussasi" periaatteet ja mallit nousevien ongelmien ratkaisemiseksi, on myös oleellista todeta, että vaatimusten ymmärtäminen on avainasemassa yrityksen tarpeiden rakentamisessa. Joskus vaatimukset eivät kuitenkaan ole läpinäkyviä tai niitä ei ole edes määritelty, tässä tapauksessa on parempi odottaa saadaksesi lisäselvitystä tai luottaa kokemukseesi ja luottaa intuitioon. Mutta joka tapauksessa, et voi tehdä päätöksiä kunnolla, jos sinulla ei ole periaatteita ja malleja, joihin tukeutua. Tässä olen tulossa  ohjelmistoarkkitehtuurityylin määritelmään.    on joukko periaatteita ja malleja, jotka määrittelevät kuinka ohjelmisto rakennetaan. Ohjelmistoarkkitehtuurityyli  Suunnitellun arkkitehtuurin eri puolille keskittyy paljon erilaisia arkkitehtonisia tyylejä, joiden soveltaminen kerralla on normaali tilanne.  Esimerkiksi, kuten:  Monoliittista arkkitehtuuria  Verkkotunnuslähtöinen suunnittelu  Komponenttipohjainen  Mikropalvelut  Putki ja suodattimet  Tapahtumalähtöinen  Mikroydin  Palvelukeskeinen  ja niin edelleen…  Tietysti niillä on hyvät ja huonot puolensa, mutta tärkein asia, jonka olen oppinut, on se, että arkkitehtuuri kehittyy vähitellen todellisista ongelmista riippuen. Aloittaen monoliittisesta arkkitehtuurista, se on loistava valinta toimintojen monimutkaisuuden vähentämiseen. Hyvin todennäköisesti tämä arkkitehtuuri sopii tarpeisiisi jopa tuotteen rakennusvaiheen (PMI) saavuttamisen jälkeen. Suuressa mittakaavassa voit harkita siirtymistä kohti tapahtumalähtöistä lähestymistapaa ja mikropalveluita itsenäisen käyttöönoton, heterogeenisen teknologiapinoympäristön ja vähemmän kytketyn arkkitehtuurin saavuttamiseksi (ja vähemmän läpinäkyvän sillä välin tapahtumalähtöisten ja pubi-lähestymistapojen luonteen vuoksi, jos nämä hyväksytään). Yksinkertaisuus ja tehokkuus ovat lähellä toisiaan ja niillä on suuri vaikutus toisiinsa. Yleensä monimutkaiset arkkitehtuurit vaikuttavat uusien ominaisuuksien kehitysnopeuteen, tukevat ja ylläpitävät olemassa olevia ominaisuuksia ja haastavat järjestelmän luonnollisen kehityksen.  Monimutkaiset järjestelmät vaativat kuitenkin usein monimutkaista ja kattavaa arkkitehtuuria, mikä on väistämätöntä.  Tämä on todella laaja aihe, ja on olemassa monia hienoja ideoita siitä, miten luonnollista evoluutiota varten rakennetaan ja rakennetaan järjestelmiä.  Kokemukseni perusteella olen kehittänyt seuraavan lähestymistavan:  Lähes aina alkaa monoliittisella arkkitehtuurityylillä, koska se eliminoi suurimman osan hajautettujen järjestelmien luonteesta johtuvista ongelmista. On myös järkevää seurata modulaarista monoliittia keskittyäksesi rakennuskomponentteihin, joilla on selkeät rajat. Komponenttipohjaisen lähestymistavan soveltaminen voisi auttaa heitä kommunikoimaan keskenään tapahtumien avulla, mutta suorat puhelut (alias RPC) yksinkertaistavat asioita alussa. On kuitenkin tärkeää seurata komponenttien välisiä riippuvuuksia, koska jos komponentti A tietää paljon komponentista B, on ehkä järkevää yhdistää ne yhdeksi.  Kun tulet lähemmäksi tilannetta, jossa sinun on skaalattava kehitystäsi ja järjestelmääsi, voit harkita   mallin noudattamista ja poimia asteittain komponentteja, jotka on otettava käyttöön itsenäisesti tai jopa skaalattava tiettyjen vaatimusten mukaan. Stangler-  Nyt, jos sinulla on selkeä näkemys tulevaisuudesta, mikä on vähän uskomatonta onnea, voit päättää halutun arkkitehtuurin. Tällä hetkellä voit päättää siirtyäksesi kohti mikropalveluarkkitehtuuria soveltamalla myös orkestrointi- ja koreografialähestymistapoja, sisällyttämällä CQRS-kuvion itsenäiseen mittakaavaan kirjoitus- ja lukutoimintoihin, tai jopa päättää pysyä monoliittisessa arkkitehtuurissa, jos se sopii tarpeisiisi.  On myös tärkeää ymmärtää numerot ja mittarit, kuten   (Daily Active Users),   (Monthly Active Users),   (Request Per Second) ja   (Tapahtuma sekunnissa), koska ne voivat auttaa sinua tekemään valintoja, koska 100 aktiivista käyttäjää ja 100 miljoonaa aktiivista käyttäjää ovat erilaisia. DAU MAU RPC TPC  Viimeisenä huomautuksena sanoisin, että arkkitehtuurilla on merkittävä vaikutus tuotteen menestykseen. Skaalauksessa vaaditaan tuotteiden huonosti suunniteltua arkkitehtuuria, mikä todennäköisesti johtaa epäonnistumiseen, koska asiakkaat eivät odota järjestelmän skaalausta, vaan he valitsevat kilpailijan, joten meidän on oltava edellä mahdollisia skaalauksia.   Toisaalta erittäin monimutkainen ja jo skaalattu järjestelmä ilman asiakkaita tai suunnitelmia hankkia monia heistä maksaa yrityksellesi turhaan rahaa. Vaikka myönnän, että toisinaan se ei voisi olla laiha lähestymistapa, ideana on skaalautuva, mutta ei jo skaalattu järjestelmä.  Teknologiapinon valinta  Teknologiapinon valitseminen on myös makrotason päätös, koska se vaikuttaa palkkaamiseen, järjestelmän luonnollisen kehityksen näkökulmiin, skaalautumiseen ja järjestelmän suorituskykyyn.  Tässä on luettelo perusnäkökohdista teknologiapinon valinnassa:    Esimerkiksi yksinkertainen verkkosovellus voidaan rakentaa Blazor-kehyksen avulla, jos kehittäjilläsi on kokemusta siitä, mutta WebAssemblyn kypsyyden puutteen vuoksi Reactin ja Typescriptin valitseminen pitkän aikavälin menestykseen voisi olla parempi päätös. Projektin vaatimukset ja monimutkaisuus.    Jos odotat saavasi paljon liikennettä, ASP.NET Coren valitseminen Djangon sijaan voi olla viisas valinta sen erinomaisen suorituskyvyn vuoksi samanaikaisten pyyntöjen käsittelyssä. Tämä päätös riippuu kuitenkin odottamastasi liikenteen laajuudesta. Jos sinun täytyy hallita mahdollisesti miljardeja pyyntöjä alhaisella viiveellä, roskienkeräys voi olla haaste. Skaalautuvuus ja suorituskykyvaatimukset.    Useimmissa tapauksissa nämä ovat tekijöitä, joista meidän on huolehdittava. Markkinoille tuloaika, ylläpitokustannukset ja vakaus rekrytoinnissa ohjaavat yrityksesi tarpeita ilman esteitä. Palkkaus, kehitysaika ja kustannukset.    Kehitystiimisi osaaminen on kriittinen tekijä. Yleensä on tehokkaampaa käyttää tiimisi jo tuntemia teknologioita, ellei ole painavaa syytä investoida uuden pinon oppimiseen. Tiimin asiantuntemus ja resurssit.    Vahva yhteisö ja rikas kirjastojen ja työkalujen ekosysteemi voivat helpottaa kehitysprosessia huomattavasti. Suosituilla teknologioilla on usein parempi yhteisön tuki, mikä voi olla korvaamatonta ongelmien ratkaisemisessa ja resurssien löytämisessä. Näin voit säästää resursseja ja keskittyä pääasiassa tuotteeseen. Kypsyys.    Harkitse tekniikan pitkän aikavälin elinkelpoisuutta. Laajalti omaksutut ja tuetut tekniikat eivät todennäköisesti vanhene ja saavat yleensä säännöllisesti päivityksiä ja parannuksia. Pitkäaikainen huolto ja tuki.   Kuinka useiden teknologiapintojen käyttö voi vaikuttaa liiketoiminnan kasvuun?  Yhdestä näkökulmasta yhden pinon lisääminen voi skaalata palkkaamistasi, mutta toisaalta se tuo ylimääräisiä ylläpitokustannuksia, koska sinun on tuettava molempia pinoja. Joten, kuten sanoin aiemmin, minun näkökulmastani vain ylimääräisen tarpeen pitäisi olla peruste teknologiapinojen sisällyttämiselle.   Mutta mikä on periaate, jonka mukaan valitaan paras työkalu tiettyyn ongelmaan?  Joskus sinulla ei ole muuta vaihtoehtoa kuin tuoda uusia työkaluja tietyn ongelman ratkaisemiseen samojen edellä mainittujen näkökohtien pohjalta, tällaisissa tapauksissa on järkevää valita paras ratkaisu.  Sellaisten järjestelmien luominen, joissa ei ole korkeaa yhteyttä tiettyyn teknologiaan, voi olla haaste. Silti on hyödyllistä pyrkiä tilanteeseen, jossa järjestelmä ei ole tiukasti kytketty teknologiaan, eikä se kuole, jos huomenna tietystä viitekehyksestä tai työkalusta tulee haavoittuva tai jopa vanhentunut.  Toinen tärkeä näkökohta liittyy avoimen lähdekoodin ja ohjelmistojen riippuvuuteen. Oma ohjelmisto antaa sinulle vähemmän joustavuutta ja mahdollisuuden mukauttaa. Silti vaarallisin tekijä on toimittajan lukkiutuminen, jossa sinusta tulee riippuvainen myyjän tuotteista, hinnoista, ehdoista ja etenemissuunnitelmasta. Tämä voi olla riskialtista, jos myyjä muuttaa suuntaa, nostaa hintoja tai lopettaa tuotteen.   Yhden vikakohdan poistaminen kaikilla tasoilla on avain luotettavien kasvujärjestelmien rakentamiseen. Avoimen lähdekoodin ohjelmistot vähentävät tätä riskiä, koska yksittäinen kokonaisuus ei hallitse sitä.  Single Point of Failure (SPOF)  Yksi vikapiste (SPOF) viittaa mihin tahansa järjestelmän osaan, joka epäonnistuessaan aiheuttaa koko järjestelmän toiminnan pysähtymisen. SPOF:ien poistaminen kaikilla tasoilla on ratkaisevan tärkeää kaikissa korkeaa käytettävyyttä vaativissa järjestelmissä. Kaikki, mukaan lukien tieto, henkilöstö, järjestelmäkomponentit, pilvipalveluntarjoajat ja Internet-kaapelit, voi epäonnistua.  On olemassa useita perustekniikoita, joita voimme soveltaa yksittäisten vikakohtien poistamiseen:    Ota käyttöön kriittisten komponenttien redundanssi. Tämä tarkoittaa, että sinulla on varmuuskopiokomponentit, jotka voivat ottaa haltuunsa, jos ensisijainen komponentti epäonnistuu. Redundanssia voidaan soveltaa järjestelmän eri tasoilla, mukaan lukien laitteistot (palvelimet, levyt), verkot (linkit, kytkimet) ja ohjelmistot (tietokannat, sovelluspalvelimet). Jos isännöit kaikkea yhdessä pilvipalveluntarjoajassa ja sinulla on siellä jopa varmuuskopioita, harkitse säännöllisen lisävarmuuskopion luomista toiseen, jotta menetät kustannukset katastrofin sattuessa. Redundanssi.    Jaa järjestelmäsi useisiin fyysisiin paikkoihin, kuten datakeskuksiin tai pilvialueisiin. Tämä lähestymistapa suojaa järjestelmääsi paikkakohtaisilta häiriöiltä, kuten sähkökatkoilta tai luonnonkatastrofilta. Palvelinkeskukset.    Käytä vikasietotapaa kaikille komponenteillesi (DNS, CDN, kuormituksen tasaajat, Kubernetes, API-yhdyskäytävät ja tietokannat). Koska ongelmia voi ilmaantua odottamatta, on erittäin tärkeää, että sinulla on varmuuskopiointisuunnitelma minkä tahansa komponentin korvaamiseksi sen kloonilla tarvittaessa nopeasti. Failover.    Varmista, että palvelusi on rakennettu vaakasuunnassa skaalautuviksi ja erittäin saataville alusta alkaen noudattamalla seuraavia periaatteita: Korkean saatavuuden palvelut.  Harjoittele palvelun valtiottomuutta ja vältä käyttäjien istuntojen tallentamista muistin välimuistiin. Käytä sen sijaan hajautettua välimuistijärjestelmää, kuten Redis.  Vältä luottamista viestien kulutuksen kronologiseen järjestykseen logiikkaa kehitettäessä.  Minimoi rikkoutuvat muutokset estääksesi häiritsevät API-kuluttajia. Jos mahdollista, valitse taaksepäin yhteensopivat muutokset. Harkitse myös kustannuksia, koska joskus murtuvan muutoksen toteuttaminen voi olla kustannustehokkaampaa.  Sisällytä siirron suorittaminen käyttöönottoprosessiin.  Luo strategia samanaikaisten pyyntöjen käsittelemiseksi.  Ota palveluhaku, seuranta ja kirjaaminen käyttöön parantaaksesi luotettavuutta ja havaittavuutta.  Kehitä liiketoimintalogiikka idempotenttiksi ja tunnusta, että verkkohäiriöt ovat väistämättömiä.    Tarkista säännöllisesti ja minimoi ulkoiset riippuvuudet. Jokainen ulkoinen riippuvuus voi aiheuttaa mahdollisia SPOF:ita, joten on tärkeää ymmärtää ja lieventää näitä riskejä. Riippuvuuden tarkistus.    Älä koskaan unohda tiedon levittämisen tärkeyttä organisaatiossasi. Ihmiset voivat olla arvaamattomia, ja yhteen yksilöön luottaminen on riskialtista. Kannusta tiimin jäseniä digitalisoimaan tietonsa dokumentoinnin avulla. Muista kuitenkin liiallinen dokumentointi. Käytä erilaisia tekoälytyökaluja tämän prosessin yksinkertaistamiseksi. Säännöllinen tiedon jakaminen.  Johtopäätös  Tässä artikkelissa käsittelimme useita   ja kuinka voimme käsitellä niiden monimutkaisuutta. makronäkökohtia  Kiitos kun luit! Nähdään ensi kerralla!

Read My Stories

Tämä ääni on tuotettu tarinan alkuperäisellä kielellä!

Kuinka käsitellä monimutkaisuutta ohjelmistojärjestelmiä suunniteltaessa

About Author

KOMMENTIT

RIPUTA TAGSIA

TÄMÄ ARTIKKELI ESITETTIIN

Related Stories

Spaghetti

Dotcom on edelleen uusien yritysten suosituin verkkotunnus, mutta käyttö laskee

How Apex Fusion Achieved FINMA Qualification Without Compromising Decentralization

Noonies Interview with Stefano Pavone, the Retrogaming Reporter

Spaghetti

Dotcom on edelleen uusien yritysten suosituin verkkotunnus, mutta käyttö laskee

How Apex Fusion Achieved FINMA Qualification Without Compromising Decentralization

Noonies Interview with Stefano Pavone, the Retrogaming Reporter

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps