Како се носити са сложеношћу приликом пројектовања софтверских система

о чему се ради? Сваког дана, сваког тренутка током наше инжењерске каријере, сусрећемо се са много различитих проблема различите сложености и ситуација у којима морамо да донесемо одлуку или да је одложимо због недостатка података. Кад год градимо нове услуге, градимо инфраструктуру или чак формирамо развојне процесе, додирујемо огроман свет различитих изазова. Изазовно је, а можда чак и немогуће, навести све проблеме. Наићи ћете на неке од ових проблема само ако радите у одређеној ниши. С друге стране, постоји много тога које сви морамо да разумемо како да решимо, јер су они кључни за изградњу ИТ система. Са великом вероватноћом ћете их срести у свим пројектима. У овом чланку ћу поделити своја искуства са неким проблемима на које сам наишао приликом креирања софтверских програма. Шта је међусобна забринутост? Ако погледамо Википедију, наћи ћемо следећу дефиницију У аспектно оријентисаном развоју софтвера, међусекторска питања су аспекти програма који утичу на неколико модула, без могућности да буду инкапсулирани у било који од њих. Ови проблеми се често не могу јасно раздвојити од остатка система иу дизајну и у имплементацији, и могу довести до распршивања (дуплицирање кода), запетљавања (значајне зависности између система) или обоје. У великој мери описује шта је то, али желим да га мало проширим и поједноставим: је концепт или компонента система/организације која утиче (или 'пресече') многе друге делове. Међусекторска брига Најбољи примери таквих брига су архитектура система, евидентирање, безбедност, управљање трансакцијама, телеметрија, дизајн базе података и постоје многи други. Касније ћемо у овом чланку елаборирати многе од њих. На нивоу кода, свеобухватни проблеми се често имплементирају коришћењем техника као што је , где су ови проблеми модулисани у засебне компоненте које се могу применити у целој апликацији. Ово држи пословну логику изолованом од ових брига, чинећи код читљивијим и одржавајућим. Аспецт-Ориентед Программинг (АОП) Класификација аспеката Постоји много могућих начина како да класификујете аспекте тако што ћете их сегментирати различитим својствима као што су обим, величина, функционалност, важност, циљ и други, али у овом чланку ћу користити једноставну класификацију опсега. Под овим мислим на то где је усмерен овај специфични аспект, било да се ради о целој организацији, одређеном систему или специфичном елементу тог система. Дакле, поделићу аспекте на и . Макро Микро Под аспектом мислим углавном на разматрања која следимо за цео систем, као што су одабрана архитектура система и његов дизајн (монолит, микросервис, сервисно оријентисана архитектура), технолошки стек, организациона структура, итд. аспекти су углавном повезани са стратешким и високим нивоом. одлуке. макро Макро У међувремену, аспект је много ближи нивоу кода и развоју. На пример, који оквир се користи за интеракцију са базом података, структуру пројекта фасцикли и класа, или чак специфичне обрасце дизајна објеката. микро Иако ова класификација није идеална, она помаже да се структурира разумевање могућих проблема и важности и утицаја решења која примењујемо на њих. У овом чланку, мој примарни фокус ће бити на макро аспектима. Макро аспекти Организациона структура Када сам тек почео да учим о архитектури софтвера, прочитао сам много занимљивих чланака о Конвејевом закону и његовом утицају на организациону структуру. Посебно . Дакле, овај закон то каже овај Свака организација која дизајнира систем (широко дефинисан) ће произвести дизајн чија је структура копија комуникацијске структуре организације. Увек сам веровао да је овај концепт заиста веома универзалан и да представља Златно правило. Затим сам почео да учим приступ дизајна вођеног доменом (ДДД) Ерица Еванса за моделирање система. Ерик Еванс наглашава важност идентификације ограниченог контекста. Овај концепт укључује поделу комплексног модела домена на мање делове којима је лакше управљати, сваки са сопственим ограниченим скупом знања. Овај приступ помаже у ефикасној тимској комуникацији, јер смањује потребу за опсежним познавањем читавог домена и минимизира промену контекста, чинећи тако разговоре ефикаснијим. Промена контекста је најгора ствар и која захтева највише ресурса. Чак се и рачунари боре са тим. Иако је мало вероватно да ће се постићи потпуно одсуство промене контекста, мислим да је то оно чему треба да тежимо. Враћајући се на Конвејев закон, нашао сам неколико проблема у вези са њим. са којим сам се сусрео са Конвејевим законом, који сугерише да дизајн система одражава организациону структуру, јесте потенцијал за формирање сложених и свеобухватних ограничених контекста. Ова сложеност настаје када организациона структура није усклађена са границама домена, што доводи до ограничених контекста који су у великој мери међусобно зависни и оптерећени информацијама. То доводи до честог мењања контекста за развојни тим. Прво питање је то што терминологија организације цури на ниво кода. Када се организационе структуре промене, то захтева модификације базе кода, трошећи вредне ресурсе. Друго питање Стога, праћење помаже у изградњи система и организације који подстичу жељену архитектуру софтвера. Међутим, вреди напоменути да овај приступ неће добро функционисати у већ формираној архитектури и структурама јер су промене у овој фази дуготрајне, али је изузетно ефикасан у стартапима јер брзо уводе било какве промене. Инверзног Цонваи маневра Велика лопта од блата Овај образац или „анти-паттерн“ покреће изградњу система без икакве архитектуре. Нема правила, нема граница и нема стратегије како да контролишете неизбежно растућу сложеност. Сложеност је најстрашнији непријатељ на путу изградње софтверских система. Да бисмо избегли конструисање таквог типа система, морамо да се придржавамо специфичних правила и ограничења. Архитектура система Постоји безброј дефиниција за софтверску архитектуру. Многи од њих ми се свиђају јер покривају различите аспекте тога. Међутим, да бисмо могли да размишљамо о архитектури, морамо природно да формирамо неке од њих у свом уму. И вреди напоменути да се ова дефиниција може развијати. Дакле, бар за сада, имам следећи опис за себе. се односи на одлуке и изборе које доносите сваки дан и који утичу на изграђен систем. Архитектура софтвера Да бисте донели одлуке које морате да имате у својој „торби“ принципе и обрасце за решавање насталих проблема, такође је од суштинске важности да кажете да је разумевање захтева кључно за изградњу онога што је потребно предузећу. Међутим, понекад захтеви нису транспарентни или чак нису дефинисани, у овом случају је боље сачекати да добијете додатна појашњења или се ослонити на своје искуство и веровати својој интуицији. Али у сваком случају, не можете правилно доносити одлуке ако немате принципе и обрасце на које се можете ослонити. Ту долазим до дефиниције стила софтверске архитектуре. је скуп принципа и образаца који одређују како се прави софтвер. Стил софтверске архитектуре Постоји много различитих архитектонских стилова фокусираних на различите стране планиране архитектуре, а примена више њих одједном је нормална ситуација. На пример, као што су: Монолитна архитектура Дизајн вођен доменом Компонентни Микроуслуге Цеви и филтери Догађај-дривен Мицрокернел Сервисно оријентисан и тако даље… Наравно, они имају своје предности и мане, али најважнија ствар коју сам научио је да се архитектура постепено развија зависно од стварних проблема. Почевши од монолитне архитектуре је одличан избор за смањење оперативних сложености, врло је вероватно да ће ова архитектура одговарати вашим потребама чак и након достизања фазе прилагођавања тржишту производа (ПМИ) изградње производа. У великој мери, можете размислити о преласку на приступ вођен догађајима и микроуслуге за постизање независног привођења, хетерогеног окружења технолошког стека и мање повезане архитектуре (и мање транспарентне у међувремену због природе приступа вођених догађајима и пуб-суб приступа ако ови се усвајају). Једноставност и ефикасност су блиске и имају велики утицај једна на другу. Обично компликоване архитектуре утичу на брзину развоја нових карактеристика, подржавајући и одржавајући постојеће, и изазивајући природну еволуцију система. Међутим, сложени системи често захтевају сложену и свеобухватну архитектуру, што је неизбежно. Искрено, ово је веома широка тема и постоји много сјајних идеја о томе како структурирати и изградити системе за природну еволуцију. На основу свог искуства, разрадио сам следећи приступ: Скоро увек почиње са монолитним стилом архитектуре јер елиминише већину проблема који настају због природе дистрибуираних система. Такође има смисла пратити модуларни монолит да бисте се фокусирали на изградњу компоненти са јасним границама. Примена приступа заснованог на компонентама могла би им помоћи да комуницирају једни са другима коришћењем догађаја, али директни позиви (ака РПЦ) поједностављују ствари на почетку. Међутим, важно је пратити зависности између компоненти јер ако компонента А зна много о компоненти Б, можда има смисла спојити их у једну. Када се приближите ситуацији када треба да скалирате свој развој и систем, могли бисте размислити о праћењу обрасца да бисте постепено издвојили компоненте које треба да се примене независно или чак скалирају са специфичним захтевима. Станглеровог Сада, ако имате јасну визију будућности, што је мало невјероватне среће, могли бисте се одлучити за жељену архитектуру. У овом тренутку, можете одлучити да пређете на архитектуру микросервиса тако што ћете такође применити оркестрацију и кореографију, укључити ЦКРС образац за независне операције писања и читања, или чак одлучити да се држите монолитне архитектуре ако то одговара вашим потребама. Такође је од виталног значаја да разумете бројеве и метрике као што су (Дневни активни корисници), (Месечно активни корисници), (Захтев у секунди) и (Трансакција у секунди) јер би вам то могло помоћи да донесете одлуке јер архитектура за 100 активних корисника и 100 милиона активних корисника се разликују. ДАУ МАУ РПЦ ТПЦ Као завршну напомену, рекао бих да архитектура има значајан утицај на успех производа. У скалирању је потребна лоше дизајнирана архитектура за производе, што врло вероватно доводи до неуспеха јер купци неће чекати док скалирате систем, већ ће изабрати конкурента, тако да морамо бити испред потенцијалног скалирања. С друге стране, поседовање веома компликованог и већ скалираног система без купаца или планова да добијете многе од њих ће вас коштати новца за ваше пословање узалуд. Иако признајем да понекад то не може бити леан приступ, идеја је да имамо скалабилан, али не већ скалиран систем. Избор технолошког стека Избор технолошког стека је такође одлука на макро нивоу јер утиче на запошљавање, перспективе природне еволуције система, скалабилност и перформансе система. Ово је листа основних разматрања за одабир технолошке групе: На пример, једноставна веб апликација се може направити са Блазор оквиром ако ваши програмери имају искуства са њим, али због недостатка зрелости ВебАссембли-а, одабир Реацт-а и Типесцрипт-а за дугорочни успех могао би бити боља одлука Захтеви и сложеност пројекта. Ако очекујете да ћете примити велику количину саобраћаја, одлучивање за АСП.НЕТ Цоре преко Дјанга може бити мудар избор због његових супериорних перформанси у руковању истовременим захтевима. Међутим, ова одлука зависи од обима саобраћаја који очекујете. Ако треба да управљате потенцијално милијардама захтева са малим кашњењем, присуство прикупљања смећа може бити изазов. Скалабилност и потребе за перформансама. У већини случајева, ово су фактори о којима треба да бринемо. Време до тржишта, трошкови одржавања и стабилност запошљавања покрећу ваше пословне потребе без препрека. Запошљавање, време развоја и цена. Скуп вештина вашег развојног тима је критичан фактор. Генерално, ефикасније је користити технологије са којима је ваш тим већ упознат осим ако не постоји јак разлог за улагање у учење новог стека. Стручност и ресурси тима. Јака заједница и богат екосистем библиотека и алата могу у великој мери олакшати процес развоја. Популарне технологије често имају бољу подршку заједнице, што може бити од непроцењиве вредности за решавање проблема и проналажење ресурса. Тако можете уштедети ресурсе и фокусирати се углавном на производ. Зрелост. Узмите у обзир дугорочну одрживост технологије. Технологије које су широко прихваћене и подржане су мање вероватно да ће застарети и генерално добијају редовна ажурирања и побољшања. Дугорочно одржавање и подршка. Како постојање више технолошких група може утицати на раст пословања? Из једне перспективе, увођење још једне групе могло би повећати ваше запошљавање, али с друге стране, то доноси додатне трошкове одржавања јер морате подржати оба стека. Дакле, као што сам раније рекао, по мом мишљењу, само додатна потреба треба да буде аргумент за укључивање више технолошких стекова. Али шта је са принципом одабира најбољег алата за одређени проблем? Понекад немате другог избора осим да донесете нове алате за решавање одређеног проблема на основу истих претходно наведених разматрања, у таквим случајевима има смисла изабрати најбоље решење. Стварање система без високе повезаности са специфичном технологијом може бити изазов. Ипак, корисно је тежити стању у којем систем није чврсто повезан са технологијом и неће умрети ако сутра одређени оквир или алатка постану рањиви или чак застарели. Још једно важно питање односи се на зависности од отвореног кода и власничког софтвера. Власнички софтвер вам даје мању флексибилност и могућност прилагођавања. Ипак, најопаснији фактор је закључавање добављача, где постајете зависни од производа, цена, услова и мапе пута добављача. Ово може бити ризично ако продавац промени правац, повећа цене или прекине производ. Елиминисање једне тачке квара на свим нивоима је кључ за изградњу поузданих система за раст. Софтвер отвореног кода смањује овај ризик, јер га не контролише један ентитет. Једна тачка квара (СПОФ) Појединачна тачка квара (СПОФ) се односи на било који део система који ће, ако откаже, узроковати да цео систем престане да функционише. Елиминисање СПОФ-ова на свим нивоима је кључно за сваки систем који захтева високу доступност. Све, укључујући знање, особље, системске компоненте, цлоуд провајдере и интернет каблове, може да пропадне. Постоји неколико основних техника које можемо применити да елиминишемо појединачне тачке квара: Имплементирајте редундантност за критичне компоненте. То значи да имате резервне компоненте које могу преузети ако примарна компонента поквари. Редунданција се може применити на различите слојеве система, укључујући хардвер (сервери, дискови), умрежавање (линкови, прекидачи) и софтвер (базе података, сервери апликација). Ако све хостујете у једном добављачу облака, па чак и тамо имате резервне копије, размислите о изградњи редовне додатне резервне копије у другом да бисте смањили изгубљене трошкове у случају катастрофе. Редундантност. Дистрибуирајте свој систем на више физичких локација, као што су центри података или региони у облаку. Овај приступ штити ваш систем од кварова специфичних за локацију, попут нестанка струје или природних катастрофа. Дата Центерс. Примените приступ преласка на грешку за све своје компоненте (ДНС, ЦДН, балансери оптерећења, Кубернетес, АПИ мрежни пролази и базе података). Пошто проблеми могу настати неочекивано, кључно је имати резервни план за брзу замену било које компоненте њеним клоном по потреби. Фаиловер. Уверите се да су ваше услуге направљене тако да буду хоризонтално скалабилне и високо доступне од самог почетка придржавајући се следећих принципа: Услуге високе доступности. Практикујте услугу без држављанства и избегавајте складиштење корисничких сесија у кеш меморије. Уместо тога, користите дистрибуирани кеш систем, као што је Редис. Избегавајте ослањање на хронолошки редослед потрошње порука када развијате логику. Минимизирајте промене које се могу оштетити да бисте спречили ометање АПИ потрошача. Где је могуће, одлучите се за промене компатибилне уназад. Такође, узмите у обзир трошак јер понекад примена преломне промене може бити исплативија. Укључите извршење миграције у цевовод за примену. Успоставите стратегију за руковање истовременим захтевима. Имплементирајте откривање услуга, праћење и евидентирање да бисте побољшали поузданост и уочљивост. Развијте пословну логику да будете идемпотентни, признајући да су кварови на мрежи неизбежни. Редовно прегледајте и минимизирајте спољне зависности. Свака спољна зависност може да уведе потенцијалне СПОФ-ове, тако да је неопходно разумети и ублажити ове ризике. Преглед зависности. Никада не заборавите на важност ширења знања унутар ваше организације. Људи могу бити непредвидиви, а ослањање на једног појединца је ризично. Подстакните чланове тима да дигитализују своје знање кроз документацију. Међутим, водите рачуна о претераном документовању. Користите различите АИ алате да поједноставите овај процес. Редовна дељење знања. Закључак У овом чланку смо покрили неколико кључних аспеката и како се можемо носити са њиховом сложеношћу. макро Хвала на читању! Видимо се следећи пут!