Як справіцца са складанасцю пры распрацоўцы праграмных сістэм

Пра што гэта? Кожны дзень, кожны момант на працягу нашай інжынернай кар'еры мы сутыкаемся з мноствам розных праблем рознай складанасці і сітуацыямі, калі нам трэба прыняць рашэнне або адкласці яго з-за недахопу дадзеных. Кожны раз, калі мы ствараем новыя сэрвісы, будуем інфраструктуру ці нават фарміруем працэсы распрацоўкі, мы дакранаемся да велізарнага свету розных праблем. Пералічыць усе праблемы цяжка, а можа, і немагчыма. Вы сутыкнецеся з некаторымі з гэтых праблем, толькі калі працуеце ў пэўнай нішы. З іншага боку, ёсць шмат праблем, якія мы ўсе павінны разумець, як вырашыць, бо яны маюць вырашальнае значэнне для стварэння ІТ-сістэм. З вялікай верагоднасцю вы сутыкнецеся з імі ва ўсіх праектах. У гэтым артыкуле я падзялюся сваім вопытам адносна некаторых праблем, з якімі я сутыкнуўся пры стварэнні праграмнага забеспячэння. Што такое міжсекторальны клопат? Калі мы зазірнем у Вікіпедыю, то знойдзем наступнае вызначэнне У аспектна-арыентаванай распрацоўцы праграмнага забеспячэння скразнымі праблемамі з'яўляюцца аспекты праграмы, якія ўплываюць на некалькі модуляў, без магчымасці быць інкапсуляванымі ні ў адным з іх. Гэтыя праблемы часта немагчыма выразна аддзяліць ад астатняй сістэмы як пры распрацоўцы, так і пры рэалізацыі, і могуць прывесці альбо да рассейвання (дубліравання кода), зблытвання (значныя залежнасці паміж сістэмамі), альбо да абодвух. Гэта ў значнай ступені апісвае, што гэта такое, але я хачу пашырыць і спрасціць яго трохі: - гэта канцэпцыя або кампанент сістэмы/арганізацыі, які закранае (або «перасякае») многія іншыя часткі. Скразная праблема Лепшымі прыкладамі такіх праблем з'яўляюцца архітэктура сістэмы, вядзенне часопісаў, бяспека, кіраванне транзакцыямі, тэлеметрыя, дызайн базы дадзеных і шмат іншых. Мы збіраемся падрабязна спыніцца на многіх з іх далей у гэтым артыкуле. На ўзроўні кода скразныя задачы часта рэалізуюцца з дапамогай такіх метадаў, як , дзе гэтыя задачы разбіваюцца на асобныя кампаненты, якія можна ўжываць ва ўсім дадатку. Гэта робіць бізнес-логіку ізаляванай ад гэтых праблем, робячы код больш зручным для чытання і абслугоўвання. Аспектна-арыентаванае праграмаванне (AOP) Класіфікацыя аспектаў Ёсць шмат магчымых спосабаў класіфікацыі аспектаў шляхам іх сегментацыі па розных уласцівасцях, такіх як аб'ём, памер, функцыянальнасць, важнасць, мэта і іншыя, але ў гэтым артыкуле я буду выкарыстоўваць простую класіфікацыю аб'ёму. Пад гэтым я маю на ўвазе, куды накіраваны гэты спецыфічны аспект, няхай гэта будзе цэлая арганізацыя, асобная сістэма або пэўны элемент гэтай сістэмы. Такім чынам, я збіраюся падзяліць аспекты на і . макра мікра Пад я маю на ўвазе ў асноўным меркаванні, якія мы прытрымліваемся для ўсёй сістэмы, такія як абраная сістэмная архітэктура і яе дызайн (маналітная, мікрасэрвісы, сэрвіс-арыентаваная архітэктура), тэхналагічны стэк, арганізацыйная структура і г.д. звязаны ў асноўным са стратэгічнымі і высокім узроўнем рашэнні. макрааспектам Макрааспекты У той жа час аспект значна бліжэй да ўзроўню кода і распрацоўкі. Напрыклад, які фрэймворк выкарыстоўваецца для ўзаемадзеяння з базай дадзеных, структура праекта папак і класаў або нават пэўныя шаблоны праектавання аб'ектаў. Micro Хоць гэтая класіфікацыя не з'яўляецца ідэальнай, яна дапамагае структураваць разуменне магчымых праблем і важнасці і ўплыву рашэнняў, якія мы да іх прымяняем. У гэтым артыкуле мая асноўная ўвага будзе сканцэнтравана на макрааспектах. Макрааспекты Арганізацыйная структура Калі я толькі пачаў вывучаць архітэктуру праграмнага забеспячэння, я прачытаў шмат цікавых артыкулаў пра закон Конвея і яго ўплыў на арганізацыйную структуру. Асабліва . Такім чынам, у гэтым законе гэта сказана гэты Любая арганізацыя, якая распрацоўвае сістэму (у шырокім сэнсе), створыць праект, структура якога з'яўляецца копіяй камунікацыйнай структуры арганізацыі. Я заўсёды лічыў, што гэтая канцэпцыя сапраўды вельмі універсальная і ўяўляе сабой залатое правіла. Потым я пачаў вывучаць падыход Эрыка Эванса да кіраванага даменам праектавання (DDD) для мадэлявання сістэм. Эрык Эванс падкрэслівае важнасць ідэнтыфікацыі абмежаванага кантэксту. Гэтая канцэпцыя ўключае ў сябе падзел складанай мадэлі дамена на меншыя, больш кіраваныя раздзелы, кожны са сваім абмежаваным наборам ведаў. Такі падыход спрыяе эфектыўнай камунікацыі ў камандзе, паколькі зніжае патрэбу ў шырокіх ведах усёй вобласці і мінімізуе пераключэнне кантэксту, што робіць размовы больш эфектыўнымі. Пераключэнне кантэксту - гэта горшая і найбольш рэсурсаёмкая рэч. З гэтым змагаюцца нават кампутары. Хаця поўная адсутнасць пераключэння кантэксту наўрад ці ўдасца дасягнуць, я лічу, што гэта тое, да чаго мы павінны імкнуцца. Вяртаючыся да закона Конвея, я выявіў некалькі праблем з ім. з якой я сутыкнуўся з законам Конвея, які сведчыць аб тым, што дызайн сістэмы адлюстроўвае арганізацыйную структуру, - гэта патэнцыял для фарміравання складаных і ўсёабдымных абмежаваных кантэкстаў. Гэтая складанасць узнікае, калі арганізацыйная структура не адпавядае межам вобласці, што прыводзіць да абмежаваных кантэкстаў, якія моцна ўзаемазалежныя і загружаныя інфармацыяй. Гэта прыводзіць да частага пераключэння кантэксту для каманды распрацоўшчыкаў. Першая праблема, , што арганізацыйная тэрміналогія выцякае на ўзровень кодэкса. Калі арганізацыйныя структуры змяняюцца, гэта патрабуе мадыфікацыі кодавай базы, спажываючы каштоўныя рэсурсы. Іншая справа Такім чынам, выкананне дапамагае пабудаваць сістэму і арганізацыю, якія спрыяюць жаданай архітэктуры праграмнага забеспячэння. Тым не менш, варта адзначыць, што гэты падыход не будзе працаваць вельмі добра ва ўжо сфарміраванай архітэктуры і структурах, паколькі змены на гэтай стадыі працягваюцца, але ён выключна эфектыўны ў стартапах, паколькі яны хутка ўносяць любыя змены. зваротнага манеўру Конвея Вялікі шар гразі Гэты шаблон або «антышаблон» стварае сістэму без якой-небудзь архітэктуры. Няма правілаў, межаў і стратэгіі, як кантраляваць непазбежны рост складанасці. Складанасць - самы грозны вораг на шляху стварэння праграмных сістэм. Каб пазбегнуць пабудовы такога тыпу сістэмы, мы павінны прытрымлівацца пэўных правілаў і абмежаванняў. Архітэктура сістэмы Існуе мноства азначэнняў архітэктуры праграмнага забеспячэння. Мне падабаюцца многія з іх, бо яны ахопліваюць розныя яго аспекты. Аднак, каб мець магчымасць разважаць пра архітэктуру, нам трэба натуральным чынам сфармаваць некаторыя з іх у нашай свядомасці. І варта адзначыць, што гэта вызначэнне можа эвалюцыянаваць. Такім чынам, прынамсі на дадзены момант, я маю наступнае апісанне для сябе. - гэта рашэнні і выбары, якія вы робіце кожны дзень, якія ўплываюць на створаную сістэму. Архітэктура праграмнага забеспячэння Для прыняцця рашэнняў неабходна мець у «сумцы» прынцыпы і шаблоны для вырашэння ўзнікаючых праблем, важна таксама заявіць, што разуменне патрабаванняў з'яўляецца ключом да стварэння таго, што патрэбна бізнесу. Аднак часам патрабаванні непразрыстыя ці нават не вызначаны, у гэтым выпадку лепш пачакаць, каб атрымаць дадатковыя тлумачэнні, або спадзявацца на свой вопыт і давяраць сваёй інтуіцыі. Але ў любым выпадку вы не можаце правільна прымаць рашэнні, калі ў вас няма прынцыпаў і шаблонаў, на якія можна спадзявацца. Вось тут я падыходжу да вызначэння стылю архітэктуры праграмнага забеспячэння. - гэта набор прынцыпаў і шаблонаў, якія вызначаюць, як ствараць праграмнае забеспячэнне. Стыль архітэктуры праграмнага забеспячэння Існуе мноства розных архітэктурных стыляў, арыентаваных на розныя бакі планаванай архітэктуры, і прымяненне некалькіх з іх адначасова - нармальная сітуацыя. Напрыклад, такія як: Маналітная архітэктура Дызайн, арыентаваны на дамен Кампанентны Мікрасэрвісы Труба і фільтры Кіраваны падзеямі Мікраядро Сэрвісны і гэтак далей... Вядома, у іх ёсць свае перавагі і недахопы, але самае галоўнае, што я даведаўся, гэта тое, што архітэктура развіваецца паступова, у залежнасці ад рэальных праблем. Пачатак з маналітнай архітэктуры - выдатны выбар для зніжэння эксплуатацыйных складанасцей, вельмі верагодна, што гэтая архітэктура будзе адпавядаць вашым патрэбам нават пасля дасягнення стадыі адаптацыі прадукту да рынку (PMI). У маштабе вы можаце разгледзець магчымасць пераходу да падыходу, які кіруецца падзеямі, і мікрасэрвісаў для дасягнення незалежнага разгортвання, гетэрагеннага асяроддзя тэхналагічнага стэка і менш звязанай архітэктуры (і тым часам менш празрыстых з-за характару падыходаў, кіраваных падзеямі і pub-sub, калі гэта прынята). Прастата і эфектыўнасць блізкія і моцна ўплываюць адзін на аднаго. Звычайна складаныя архітэктуры ўплываюць на хуткасць распрацоўкі новых функцый, падтрымліваюць і падтрымліваюць існуючыя і кідаюць выклік натуральнай эвалюцыі сістэмы. Аднак складаныя сістэмы часта патрабуюць складанай і комплекснай архітэктуры, што непазбежна. Шчыра кажучы, гэта вельмі шырокая тэма, і ёсць шмат выдатных ідэй аб тым, як структураваць і будаваць сістэмы для натуральнай эвалюцыі. Грунтуючыся на сваім вопыце, я выпрацаваў наступны падыход: Амаль заўсёды пачынаецца са стылю маналітнай архітэктуры, паколькі ён ліквідуе большасць праблем, якія ўзнікаюць з-за прыроды размеркаваных сістэм. Таксама мае сэнс прытрымлівацца модульнага маналіту, каб засяродзіцца на стварэнні кампанентаў з выразнымі межамі. Прымяненне кампанентнага падыходу магло б дапамагчы ім мець зносіны адзін з адным з дапамогай падзей, але прамыя выклікі (ён жа RPC) спрашчаюць усё напачатку. Аднак важна адсочваць залежнасці паміж кампанентамі, бо калі кампанент А ведае шмат пра кампанент В, магчыма, мае сэнс аб'яднаць іх у адзін. Калі вы падыходзіце бліжэй да сітуацыі, калі вам трэба маштабаваць сваю распрацоўку і сістэму, вы можаце разгледзець прытрымліванне шаблону , каб паступова здабываць кампаненты, якія трэба разгортваць незалежна або нават маштабаваць з улікам пэўных патрабаванняў. Stangler Цяпер, калі ў вас ёсць дакладнае бачанне будучыні, што з'яўляецца крыху неверагоднай удачай, вы можаце вызначыцца з жаданай архітэктурай. У гэты момант вы можаце прыняць рашэнне аб пераходзе да архітэктуры мікрасэрвісаў, таксама прымяніўшы падыходы аркестрацыі і харэаграфіі, уключыўшы шаблон CQRS для незалежных маштабных аперацый запісу і чытання, або нават вырашыўшы прытрымлівацца маналітнай архітэктуры, калі яна адпавядае вашым патрэбам. Таксама вельмі важна разумець лічбы і паказчыкі, такія як (штодзённыя актыўныя карыстальнікі), (штомесячныя актыўныя карыстальнікі), (запыт у секунду) і (транзакцыя ў секунду), паколькі гэта можа дапамагчы вам зрабіць выбар, таму што архітэктура для 100 актыўных карыстальнікаў і 100 мільёнаў актыўных карыстальнікаў розныя. DAU MAU RPC TPC У якасці апошняй заўвагі я б сказаў, што архітэктура мае значны ўплыў на поспех прадукту. Дрэнна распрацаваная архітэктура для прадуктаў патрабуецца для маштабавання, што, хутчэй за ўсё, прывядзе да няўдачы, паколькі кліенты не будуць чакаць, пакуль вы маштабуеце сістэму, яны выберуць канкурэнта, таму мы павінны апярэджваць патэнцыйнае маштабаванне. З іншага боку, наяўнасць вельмі складанай і ўжо маштабаванай сістэмы без кліентаў або планаў па прыцягненню многіх з іх будзе каштаваць вам грошай на ваш бізнес дарма. Хаця я прызнаю, што часам гэта не можа быць эканомным падыходам, ідэя заключаецца ў тым, каб мець маштабаваную, але яшчэ не маштабаваную сістэму. Выбар стэка тэхналогій Выбар тэхналагічнага стэка таксама з'яўляецца рашэннем на макраўзроўні, паколькі ён уплывае на прыём на працу, перспектывы натуральнага развіцця сістэмы, маштабаванасць і прадукцыйнасць сістэмы. Вось спіс асноўных меркаванняў для выбару тэхналагічнага стэка: Напрыклад, простае вэб-прыкладанне можна стварыць з фрэймворкам Blazor, калі ў вашых распрацоўшчыкаў ёсць досвед працы з ім, але з-за недастатковай сталасці WebAssembly выбар React і Typescript для доўгатэрміновага поспеху можа быць лепшым рашэннем Патрабаванні і складанасць праекта. Калі вы мяркуеце атрымаць вялікі аб'ём трафіку, выбар ASP.NET Core замест Django можа быць разумным выбарам з-за яго высокай прадукцыйнасці пры апрацоўцы адначасовых запытаў. Аднак гэтае рашэнне залежыць ад чаканага маштабу трафіку. Калі вам трэба кіраваць патэнцыяльна мільярдамі запытаў з нізкай затрымкай, наяўнасць зборкі смецця можа стаць праблемай. Патрэбы ў маштабаванасці і прадукцыйнасці. У большасці выпадкаў гэта тыя фактары, пра якія нам трэба клапаціцца. Час выхаду на рынак, кошт абслугоўвання і стабільнасць найму бесперашкодна забяспечваюць патрэбы вашага бізнесу. Найм, час распрацоўкі і кошт. Набор навыкаў вашай каманды распрацоўшчыкаў з'яўляецца найважнейшым фактарам. Як правіла, больш эфектыўна выкарыстоўваць тэхналогіі, з якімі ваша каманда ўжо знаёмая, калі толькі няма сур'ёзных прычын інвеставаць у вывучэнне новага стэка. Экспертыза каманды і рэсурсы. Моцная супольнасць і багатая экасістэма бібліятэк і інструментаў могуць значна палегчыць працэс распрацоўкі. Папулярныя тэхналогіі часта маюць лепшую падтрымку супольнасці, што можа быць неацэнным для вырашэння праблем і пошуку рэсурсаў. Такім чынам, вы можаце зэканоміць рэсурсы і сканцэнтравацца ў асноўным на прадукце. Спеласць. Разгледзім доўгатэрміновую жыццяздольнасць тэхналогіі. Шырока распаўсюджаныя і падтрымоўваныя тэхналогіі з меншай верагоднасцю састарэюць і, як правіла, рэгулярна абнаўляюцца і паляпшаюцца. Доўгатэрміновае абслугоўванне і падтрымка. Як наяўнасць некалькіх стэкаў тэхналогій можа паўплываць на рост бізнесу? З аднаго пункту гледжання, увядзенне яшчэ аднаго стэка можа павялічыць ваш набор, але з іншага боку, гэта прыносіць дадатковыя выдаткі на абслугоўванне, паколькі вам трэба падтрымліваць абодва стэка. Такім чынам, як я ўжо казаў раней, з майго пункту гледжання, толькі дадатковая патрэба павінна быць аргументам для ўключэння большай колькасці стэкаў тэхналогій. Але як жа прынцып выбару лепшага інструмента для канкрэтнай праблемы? Часам у вас няма іншага выбару, акрамя як прынесці новыя інструменты для вырашэння канкрэтнай праблемы, заснаваныя на тых жа меркаваннях, што згадваліся вышэй, у такіх выпадках мае сэнс выбраць лепшае рашэнне. Стварэнне сістэм без моцнай сувязі з пэўнай тэхналогіяй можа стаць праблемай. Тым не менш, карысна імкнуцца да таго, каб сістэма не была цесна звязана з тэхналогіямі, і яна не памрэ, калі заўтра пэўны фрэймворк або інструмент стануць уразлівымі або нават састарэюць. Яшчэ адно важнае меркаванне звязана з залежнасцямі ад адкрытага і прапрыетарнага праграмнага забеспячэння. Запатэнтаванае праграмнае забеспячэнне дае вам менш гнуткасці і магчымасць наладжвання. Тым не менш, самым небяспечным фактарам з'яўляецца прывязка да пастаўшчыка, калі вы становіцеся залежнымі ад прадуктаў, цэн, умоў і дарожнай карты пастаўшчыка. Гэта можа быць рызыкоўна, калі пастаўшчык зменіць кірунак, павысіць цэны або спыніць выпуск прадукту. Ліквідацыя адной кропкі адмовы на ўсіх узроўнях з'яўляецца ключом да стварэння надзейных сістэм для росту. Праграмнае забеспячэнне з адкрытым зыходным кодам зніжае гэтую рызыку, бо адзін суб'ект не кантралюе яго. Адзіная кропка адмовы (SPOF) Адзіная кропка адмовы (SPOF) адносіцца да любой часткі сістэмы, якая ў выпадку збою прывядзе да спынення функцыянавання ўсёй сістэмы. Ліквідацыя SPOF на ўсіх узроўнях мае вырашальнае значэнне для любой сістэмы, якая патрабуе высокай даступнасці. Усё, уключаючы веды, персанал, сістэмныя кампаненты, воблачныя правайдэры і інтэрнэт-кабелі, можа выйсці з ладу. Ёсць некалькі асноўных метадаў, якія мы можам прымяніць для ліквідацыі асобных кропак адмовы: Рэалізаваць рэзерваванне для важных кампанентаў. Гэта азначае наяўнасць рэзервовых кампанентаў, якія могуць узяць на сябе ўладу, калі асноўны кампанент выйдзе з ладу. Рэзерваванне можа прымяняцца на розных узроўнях сістэмы, уключаючы абсталяванне (серверы, дыскі), сетку (спасылкі, камутатары) і праграмнае забеспячэнне (базы даных, серверы прыкладанняў). Калі вы размяшчаеце ўсё ў адным воблачным пастаўшчыку і нават маеце там рэзервовыя копіі, падумайце аб стварэнні рэгулярнай дадатковай рэзервовай копіі ў іншым, каб паменшыць страты ў выпадку аварыі. Надмернасць. Размяркуйце сваю сістэму па некалькіх фізічных месцах, такіх як цэнтры апрацоўкі дадзеных або воблачныя рэгіёны. Такі падыход абараняе вашу сістэму ад збояў у пэўным месцы, такіх як перабоі з электрычнасцю або стыхійныя бедствы. Цэнтры апрацоўкі дадзеных. Прымяніце адмоваапрацоўчы падыход для ўсіх вашых кампанентаў (DNS, CDN, балансіроўшчыкі нагрузкі, Kubernetes, шлюзы API і базы даных). Паколькі праблемы могуць узнікнуць нечакана, вельмі важна мець план рэзервовага капіявання, каб па меры неабходнасці хутка замяніць любы кампанент яго клонам. Пераключэнне пасля адмовы. Пераканайцеся, што вашыя паслугі з самага пачатку пабудаваны для гарызантальнага маштабавання і высокай даступнасці, прытрымліваючыся наступных прынцыпаў: Паслугі высокай даступнасці. Практыкуйце абслугоўванне без грамадзянства і пазбягайце захоўвання сеансаў карыстальнікаў у кэшах у памяці. Замест гэтага выкарыстоўвайце сістэму размеркаванага кэша, напрыклад Redis. Пазбягайце залежнасці ад храналагічнага парадку спажывання паведамлення пры распрацоўцы логікі. Звядзіце да мінімуму непрыемныя змены, каб прадухіліць збой спажыўцоў API. Па магчымасці выбірайце змены з зваротнай сумяшчальнасцю. Акрамя таго, улічвайце кошт, бо часам укараненне рэзкіх змяненняў можа быць больш эканамічна эфектыўным. Уключыце выкананне міграцыі ў канвеер разгортвання. Стварыце стратэгію апрацоўкі адначасовых запытаў. Укараняйце выяўленне, маніторынг і вядзенне сэрвісаў для павышэння надзейнасці і назіральнасці. Развівайце бізнес-логіку, каб быць ідэмпэнтным, прызнаючы, што збоі ў сетцы непазбежныя. Рэгулярна правярайце і мінімізуйце знешнія залежнасці. Кожная знешняя залежнасць можа выклікаць патэнцыйныя SPOF, таму вельмі важна разумець і зніжаць гэтыя рызыкі. Агляд залежнасці. Ніколі не забывайце пра важнасць распаўсюджвання ведаў у вашай арганізацыі. Людзі могуць быць непрадказальнымі, і спадзявацца на аднаго чалавека рызыкоўна. Заахвочвайце членаў каманды алічбоўваць свае веды з дапамогай дакументацыі. Аднак памятайце пра празмернае дакументаванне. Выкарыстоўвайце розныя інструменты штучнага інтэлекту, каб спрасціць гэты працэс. Рэгулярны абмен ведамі. Заключэнне У гэтым артыкуле мы разгледзелі некалькі ключавых аспектаў і тое, як мы можам справіцца з іх складанасцю. Макра Дзякуй за чытанне! Да наступнай сустрэчы!