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

Пра што гэта?

Кожны дзень, кожны момант на працягу нашай інжынернай кар'еры мы сутыкаемся з мноствам розных праблем рознай складанасці і сітуацыямі, калі нам трэба прыняць рашэнне або адкласці яго з-за недахопу дадзеных. Кожны раз, калі мы ствараем новыя сэрвісы, будуем інфраструктуру ці нават фарміруем працэсы распрацоўкі, мы дакранаемся да велізарнага свету розных праблем.

Пералічыць усе праблемы цяжка, а можа, і немагчыма. Вы сутыкнецеся з некаторымі з гэтых праблем, толькі калі працуеце ў пэўнай нішы. З іншага боку, ёсць шмат праблем, якія мы ўсе павінны разумець, як вырашыць, бо яны маюць вырашальнае значэнне для стварэння ІТ-сістэм. З вялікай верагоднасцю вы сутыкнецеся з імі ва ўсіх праектах.

У гэтым артыкуле я падзялюся сваім вопытам адносна некаторых праблем, з якімі я сутыкнуўся пры стварэнні праграмнага забеспячэння.

Што такое міжсекторальны клопат?

Калі мы зазірнем у Вікіпедыю, то знойдзем наступнае вызначэнне

У аспектна-арыентаванай распрацоўцы праграмнага забеспячэння скразнымі праблемамі з'яўляюцца аспекты праграмы, якія ўплываюць на некалькі модуляў, без магчымасці быць інкапсуляванымі ні ў адным з іх. Гэтыя праблемы часта немагчыма выразна аддзяліць ад астатняй сістэмы як пры распрацоўцы, так і пры рэалізацыі, і могуць прывесці альбо да рассейвання (дубліравання кода), зблытвання (значныя залежнасці паміж сістэмамі), альбо да абодвух.

Гэта ў значнай ступені апісвае, што гэта такое, але я хачу пашырыць і спрасціць яго трохі:

Скразная праблема - гэта канцэпцыя або кампанент сістэмы/арганізацыі, які закранае (або «перасякае») многія іншыя часткі.

Лепшымі прыкладамі такіх праблем з'яўляюцца архітэктура сістэмы, вядзенне часопісаў, бяспека, кіраванне транзакцыямі, тэлеметрыя, дызайн базы дадзеных і шмат іншых. Мы збіраемся падрабязна спыніцца на многіх з іх далей у гэтым артыкуле.

На ўзроўні кода скразныя задачы часта рэалізуюцца з дапамогай такіх метадаў, як Аспектна-арыентаванае праграмаванне (AOP) , дзе гэтыя задачы разбіваюцца на асобныя кампаненты, якія можна ўжываць ва ўсім дадатку. Гэта робіць бізнес-логіку ізаляванай ад гэтых праблем, робячы код больш зручным для чытання і абслугоўвання.

Класіфікацыя аспектаў

Ёсць шмат магчымых спосабаў класіфікацыі аспектаў шляхам іх сегментацыі па розных уласцівасцях, такіх як аб'ём, памер, функцыянальнасць, важнасць, мэта і іншыя, але ў гэтым артыкуле я буду выкарыстоўваць простую класіфікацыю аб'ёму. Пад гэтым я маю на ўвазе, куды накіраваны гэты спецыфічны аспект, няхай гэта будзе цэлая арганізацыя, асобная сістэма або пэўны элемент гэтай сістэмы.

Такім чынам, я збіраюся падзяліць аспекты на макра і мікра .

Пад макрааспектам я маю на ўвазе ў асноўным меркаванні, якія мы прытрымліваемся для ўсёй сістэмы, такія як абраная сістэмная архітэктура і яе дызайн (маналітная, мікрасэрвісы, сэрвіс-арыентаваная архітэктура), тэхналагічны стэк, арганізацыйная структура і г.д. Макрааспекты звязаны ў асноўным са стратэгічнымі і высокім узроўнем рашэнні.

У той жа час аспект Micro значна бліжэй да ўзроўню кода і распрацоўкі. Напрыклад, які фрэймворк выкарыстоўваецца для ўзаемадзеяння з базай дадзеных, структура праекта папак і класаў або нават пэўныя шаблоны праектавання аб'ектаў.

Хоць гэтая класіфікацыя не з'яўляецца ідэальнай, яна дапамагае структураваць разуменне магчымых праблем і важнасці і ўплыву рашэнняў, якія мы да іх прымяняем.

У гэтым артыкуле мая асноўная ўвага будзе сканцэнтравана на макрааспектах.

Макрааспекты

Арганізацыйная структура

Калі я толькі пачаў вывучаць архітэктуру праграмнага забеспячэння, я прачытаў шмат цікавых артыкулаў пра закон Конвея і яго ўплыў на арганізацыйную структуру. Асабліва гэты . Такім чынам, у гэтым законе гэта сказана

Любая арганізацыя, якая распрацоўвае сістэму (у шырокім сэнсе), створыць праект, структура якога з'яўляецца копіяй камунікацыйнай структуры арганізацыі.

Я заўсёды лічыў, што гэтая канцэпцыя сапраўды вельмі універсальная і ўяўляе сабой залатое правіла.

Потым я пачаў вывучаць падыход Эрыка Эванса да кіраванага даменам праектавання (DDD) для мадэлявання сістэм. Эрык Эванс падкрэслівае важнасць ідэнтыфікацыі абмежаванага кантэксту. Гэтая канцэпцыя ўключае ў сябе падзел складанай мадэлі дамена на меншыя, больш кіраваныя раздзелы, кожны са сваім абмежаваным наборам ведаў. Такі падыход спрыяе эфектыўнай камунікацыі ў камандзе, паколькі зніжае патрэбу ў шырокіх ведах усёй вобласці і мінімізуе пераключэнне кантэксту, што робіць размовы больш эфектыўнымі. Пераключэнне кантэксту - гэта горшая і найбольш рэсурсаёмкая рэч. З гэтым змагаюцца нават кампутары. Хаця поўная адсутнасць пераключэння кантэксту наўрад ці ўдасца дасягнуць, я лічу, што гэта тое, да чаго мы павінны імкнуцца.

Вяртаючыся да закона Конвея, я выявіў некалькі праблем з ім.

Першая праблема, з якой я сутыкнуўся з законам Конвея, які сведчыць аб тым, што дызайн сістэмы адлюстроўвае арганізацыйную структуру, - гэта патэнцыял для фарміравання складаных і ўсёабдымных абмежаваных кантэкстаў. Гэтая складанасць узнікае, калі арганізацыйная структура не адпавядае межам вобласці, што прыводзіць да абмежаваных кантэкстаў, якія моцна ўзаемазалежныя і загружаныя інфармацыяй. Гэта прыводзіць да частага пераключэння кантэксту для каманды распрацоўшчыкаў.

Іншая справа , што арганізацыйная тэрміналогія выцякае на ўзровень кодэкса. Калі арганізацыйныя структуры змяняюцца, гэта патрабуе мадыфікацыі кодавай базы, спажываючы каштоўныя рэсурсы.

Такім чынам, выкананне зваротнага манеўру Конвея дапамагае пабудаваць сістэму і арганізацыю, якія спрыяюць жаданай архітэктуры праграмнага забеспячэння. Тым не менш, варта адзначыць, што гэты падыход не будзе працаваць вельмі добра ва ўжо сфарміраванай архітэктуры і структурах, паколькі змены на гэтай стадыі працягваюцца, але ён выключна эфектыўны ў стартапах, паколькі яны хутка ўносяць любыя змены.

Вялікі шар гразі

Гэты шаблон або «антышаблон» стварае сістэму без якой-небудзь архітэктуры. Няма правілаў, межаў і стратэгіі, як кантраляваць непазбежны рост складанасці. Складанасць - самы грозны вораг на шляху стварэння праграмных сістэм.

Каб пазбегнуць пабудовы такога тыпу сістэмы, мы павінны прытрымлівацца пэўных правілаў і абмежаванняў.

Архітэктура сістэмы

Існуе мноства азначэнняў архітэктуры праграмнага забеспячэння. Мне падабаюцца многія з іх, бо яны ахопліваюць розныя яго аспекты. Аднак, каб мець магчымасць разважаць пра архітэктуру, нам трэба натуральным чынам сфармаваць некаторыя з іх у нашай свядомасці. І варта адзначыць, што гэта вызначэнне можа эвалюцыянаваць. Такім чынам, прынамсі на дадзены момант, я маю наступнае апісанне для сябе.

Архітэктура праграмнага забеспячэння - гэта рашэнні і выбары, якія вы робіце кожны дзень, якія ўплываюць на створаную сістэму.

Для прыняцця рашэнняў неабходна мець у «сумцы» прынцыпы і шаблоны для вырашэння ўзнікаючых праблем, важна таксама заявіць, што разуменне патрабаванняў з'яўляецца ключом да стварэння таго, што патрэбна бізнесу. Аднак часам патрабаванні непразрыстыя ці нават не вызначаны, у гэтым выпадку лепш пачакаць, каб атрымаць дадатковыя тлумачэнні, або спадзявацца на свой вопыт і давяраць сваёй інтуіцыі. Але ў любым выпадку вы не можаце правільна прымаць рашэнні, калі ў вас няма прынцыпаў і шаблонаў, на якія можна спадзявацца. Вось тут я падыходжу да вызначэння стылю архітэктуры праграмнага забеспячэння.

Стыль архітэктуры праграмнага забеспячэння - гэта набор прынцыпаў і шаблонаў, якія вызначаюць, як ствараць праграмнае забеспячэнне.

Існуе мноства розных архітэктурных стыляў, арыентаваных на розныя бакі планаванай архітэктуры, і прымяненне некалькіх з іх адначасова - нармальная сітуацыя.

Напрыклад, такія як:

1. Маналітная архітэктура

2. Дызайн, арыентаваны на дамен

3. Кампанентны

4. Мікрасэрвісы

5. Труба і фільтры

6. Кіраваны падзеямі

7. Мікраядро

8. Сэрвісны

   
   

і гэтак далей...

Вядома, у іх ёсць свае перавагі і недахопы, але самае галоўнае, што я даведаўся, гэта тое, што архітэктура развіваецца паступова, у залежнасці ад рэальных праблем. Пачатак з маналітнай архітэктуры - выдатны выбар для зніжэння эксплуатацыйных складанасцей, вельмі верагодна, што гэтая архітэктура будзе адпавядаць вашым патрэбам нават пасля дасягнення стадыі адаптацыі прадукту да рынку (PMI). У маштабе вы можаце разгледзець магчымасць пераходу да падыходу, які кіруецца падзеямі, і мікрасэрвісаў для дасягнення незалежнага разгортвання, гетэрагеннага асяроддзя тэхналагічнага стэка і менш звязанай архітэктуры (і тым часам менш празрыстых з-за характару падыходаў, кіраваных падзеямі і pub-sub, калі гэта прынята). Прастата і эфектыўнасць блізкія і моцна ўплываюць адзін на аднаго. Звычайна складаныя архітэктуры ўплываюць на хуткасць распрацоўкі новых функцый, падтрымліваюць і падтрымліваюць існуючыя і кідаюць выклік натуральнай эвалюцыі сістэмы.

Аднак складаныя сістэмы часта патрабуюць складанай і комплекснай архітэктуры, што непазбежна.

Шчыра кажучы, гэта вельмі шырокая тэма, і ёсць шмат выдатных ідэй аб тым, як структураваць і будаваць сістэмы для натуральнай эвалюцыі. Грунтуючыся на сваім вопыце, я выпрацаваў наступны падыход:

1. Амаль заўсёды пачынаецца са стылю маналітнай архітэктуры, паколькі ён ліквідуе большасць праблем, якія ўзнікаюць з-за прыроды размеркаваных сістэм. Таксама мае сэнс прытрымлівацца модульнага маналіту, каб засяродзіцца на стварэнні кампанентаў з выразнымі межамі. Прымяненне кампанентнага падыходу магло б дапамагчы ім мець зносіны адзін з адным з дапамогай падзей, але прамыя выклікі (ён жа RPC) спрашчаюць усё напачатку. Аднак важна адсочваць залежнасці паміж кампанентамі, бо калі кампанент А ведае шмат пра кампанент В, магчыма, мае сэнс аб'яднаць іх у адзін.
2. Калі вы падыходзіце бліжэй да сітуацыі, калі вам трэба маштабаваць сваю распрацоўку і сістэму, вы можаце разгледзець прытрымліванне шаблону Stangler , каб паступова здабываць кампаненты, якія трэба разгортваць незалежна або нават маштабаваць з улікам пэўных патрабаванняў.
3. Цяпер, калі ў вас ёсць дакладнае бачанне будучыні, што з'яўляецца крыху неверагоднай удачай, вы можаце вызначыцца з жаданай архітэктурай. У гэты момант вы можаце прыняць рашэнне аб пераходзе да архітэктуры мікрасэрвісаў, таксама прымяніўшы падыходы аркестрацыі і харэаграфіі, уключыўшы шаблон CQRS для незалежных маштабных аперацый запісу і чытання, або нават вырашыўшы прытрымлівацца маналітнай архітэктуры, калі яна адпавядае вашым патрэбам.

Таксама вельмі важна разумець лічбы і паказчыкі, такія як DAU (штодзённыя актыўныя карыстальнікі), MAU (штомесячныя актыўныя карыстальнікі), RPC (запыт у секунду) і TPC (транзакцыя ў секунду), паколькі гэта можа дапамагчы вам зрабіць выбар, таму што архітэктура для 100 актыўных карыстальнікаў і 100 мільёнаў актыўных карыстальнікаў розныя.

У якасці апошняй заўвагі я б сказаў, што архітэктура мае значны ўплыў на поспех прадукту. Дрэнна распрацаваная архітэктура для прадуктаў патрабуецца для маштабавання, што, хутчэй за ўсё, прывядзе да няўдачы, паколькі кліенты не будуць чакаць, пакуль вы маштабуеце сістэму, яны выберуць канкурэнта, таму мы павінны апярэджваць патэнцыйнае маштабаванне. Хаця я прызнаю, што часам гэта не можа быць эканомным падыходам, ідэя заключаецца ў тым, каб мець маштабаваную, але яшчэ не маштабаваную сістэму. З іншага боку, наяўнасць вельмі складанай і ўжо маштабаванай сістэмы без кліентаў або планаў па прыцягненню многіх з іх будзе каштаваць вам грошай на ваш бізнес дарма.

Выбар стэка тэхналогій

Выбар тэхналагічнага стэка таксама з'яўляецца рашэннем на макраўзроўні, паколькі ён уплывае на прыём на працу, перспектывы натуральнага развіцця сістэмы, маштабаванасць і прадукцыйнасць сістэмы.

Вось спіс асноўных меркаванняў для выбару тэхналагічнага стэка:

• Патрабаванні і складанасць праекта. Напрыклад, простае вэб-прыкладанне можна стварыць з фрэймворкам Blazor, калі ў вашых распрацоўшчыкаў ёсць досвед працы з ім, але з-за недастатковай сталасці WebAssembly выбар React і Typescript для доўгатэрміновага поспеху можа быць лепшым рашэннем
• Патрэбы ў маштабаванасці і прадукцыйнасці. Калі вы мяркуеце атрымаць вялікі аб'ём трафіку, выбар ASP.NET Core замест Django можа быць разумным выбарам з-за яго высокай прадукцыйнасці пры апрацоўцы адначасовых запытаў. Аднак гэтае рашэнне залежыць ад чаканага маштабу трафіку. Калі вам трэба кіраваць патэнцыяльна мільярдамі запытаў з нізкай затрымкай, наяўнасць зборкі смецця можа стаць праблемай.
• Найм, час распрацоўкі і кошт. У большасці выпадкаў гэта тыя фактары, пра якія нам трэба клапаціцца. Час выхаду на рынак, кошт абслугоўвання і стабільнасць найму бесперашкодна забяспечваюць патрэбы вашага бізнесу.
• Экспертыза каманды і рэсурсы. Набор навыкаў вашай каманды распрацоўшчыкаў з'яўляецца найважнейшым фактарам. Як правіла, больш эфектыўна выкарыстоўваць тэхналогіі, з якімі ваша каманда ўжо знаёмая, калі толькі няма сур'ёзных прычын інвеставаць у вывучэнне новага стэка.
• Спеласць. Моцная супольнасць і багатая экасістэма бібліятэк і інструментаў могуць значна палегчыць працэс распрацоўкі. Папулярныя тэхналогіі часта маюць лепшую падтрымку супольнасці, што можа быць неацэнным для вырашэння праблем і пошуку рэсурсаў. Такім чынам, вы можаце зэканоміць рэсурсы і сканцэнтравацца ў асноўным на прадукце.
• Доўгатэрміновае абслугоўванне і падтрымка. Разгледзім доўгатэрміновую жыццяздольнасць тэхналогіі. Шырока распаўсюджаныя і падтрымоўваныя тэхналогіі з меншай верагоднасцю састарэюць і, як правіла, рэгулярна абнаўляюцца і паляпшаюцца.

Як наяўнасць некалькіх стэкаў тэхналогій можа паўплываць на рост бізнесу?

З аднаго пункту гледжання, увядзенне яшчэ аднаго стэка можа павялічыць ваш набор, але з іншага боку, гэта прыносіць дадатковыя выдаткі на абслугоўванне, паколькі вам трэба падтрымліваць абодва стэка. Такім чынам, як я ўжо казаў раней, з майго пункту гледжання, толькі дадатковая патрэба павінна быць аргументам для ўключэння большай колькасці стэкаў тэхналогій.

Але як жа прынцып выбару лепшага інструмента для канкрэтнай праблемы?

Часам у вас няма іншага выбару, акрамя як прынесці новыя інструменты для вырашэння канкрэтнай праблемы, заснаваныя на тых жа меркаваннях, што згадваліся вышэй, у такіх выпадках мае сэнс выбраць лепшае рашэнне.

Стварэнне сістэм без моцнай сувязі з пэўнай тэхналогіяй можа стаць праблемай. Тым не менш, карысна імкнуцца да таго, каб сістэма не была цесна звязана з тэхналогіямі, і яна не памрэ, калі заўтра пэўны фрэймворк або інструмент стануць уразлівымі або нават састарэюць.

Яшчэ адно важнае меркаванне звязана з залежнасцямі ад адкрытага і прапрыетарнага праграмнага забеспячэння. Запатэнтаванае праграмнае забеспячэнне дае вам менш гнуткасці і магчымасць наладжвання. Тым не менш, самым небяспечным фактарам з'яўляецца прывязка да пастаўшчыка, калі вы становіцеся залежнымі ад прадуктаў, цэн, умоў і дарожнай карты пастаўшчыка. Гэта можа быць рызыкоўна, калі пастаўшчык зменіць кірунак, павысіць цэны або спыніць выпуск прадукту. Праграмнае забеспячэнне з адкрытым зыходным кодам зніжае гэтую рызыку, бо адзін суб'ект не кантралюе яго. Ліквідацыя адной кропкі адмовы на ўсіх узроўнях з'яўляецца ключом да стварэння надзейных сістэм для росту.

Адзіная кропка адмовы (SPOF)

Адзіная кропка адмовы (SPOF) адносіцца да любой часткі сістэмы, якая ў выпадку збою прывядзе да спынення функцыянавання ўсёй сістэмы. Ліквідацыя SPOF на ўсіх узроўнях мае вырашальнае значэнне для любой сістэмы, якая патрабуе высокай даступнасці. Усё, уключаючы веды, персанал, сістэмныя кампаненты, воблачныя правайдэры і інтэрнэт-кабелі, можа выйсці з ладу.

Ёсць некалькі асноўных метадаў, якія мы можам прымяніць для ліквідацыі асобных кропак адмовы:

1. Надмернасць. Рэалізаваць рэзерваванне для важных кампанентаў. Гэта азначае наяўнасць рэзервовых кампанентаў, якія могуць узяць на сябе ўладу, калі асноўны кампанент выйдзе з ладу. Рэзерваванне можа прымяняцца на розных узроўнях сістэмы, уключаючы абсталяванне (серверы, дыскі), сетку (спасылкі, камутатары) і праграмнае забеспячэнне (базы даных, серверы прыкладанняў). Калі вы размяшчаеце ўсё ў адным воблачным пастаўшчыку і нават маеце там рэзервовыя копіі, падумайце аб стварэнні рэгулярнай дадатковай рэзервовай копіі ў іншым, каб паменшыць страты ў выпадку аварыі.
2. Цэнтры апрацоўкі дадзеных. Размяркуйце сваю сістэму па некалькіх фізічных месцах, такіх як цэнтры апрацоўкі дадзеных або воблачныя рэгіёны. Такі падыход абараняе вашу сістэму ад збояў у пэўным месцы, такіх як перабоі з электрычнасцю або стыхійныя бедствы.
3. Пераключэнне пасля адмовы. Прымяніце адмоваапрацоўчы падыход для ўсіх вашых кампанентаў (DNS, CDN, балансіроўшчыкі нагрузкі, Kubernetes, шлюзы API і базы даных). Паколькі праблемы могуць узнікнуць нечакана, вельмі важна мець план рэзервовага капіявання, каб па меры неабходнасці хутка замяніць любы кампанент яго клонам.
4. Паслугі высокай даступнасці. Пераканайцеся, што вашыя паслугі з самага пачатку пабудаваны для гарызантальнага маштабавання і высокай даступнасці, прытрымліваючыся наступных прынцыпаў:
   • Практыкуйце абслугоўванне без грамадзянства і пазбягайце захоўвання сеансаў карыстальнікаў у кэшах у памяці. Замест гэтага выкарыстоўвайце сістэму размеркаванага кэша, напрыклад Redis.
   • Пазбягайце залежнасці ад храналагічнага парадку спажывання паведамлення пры распрацоўцы логікі.
   • Звядзіце да мінімуму непрыемныя змены, каб прадухіліць збой спажыўцоў API. Па магчымасці выбірайце змены з зваротнай сумяшчальнасцю. Акрамя таго, улічвайце кошт, бо часам укараненне рэзкіх змяненняў можа быць больш эканамічна эфектыўным.
   • Уключыце выкананне міграцыі ў канвеер разгортвання.
   • Стварыце стратэгію апрацоўкі адначасовых запытаў.
   • Укараняйце выяўленне, маніторынг і вядзенне сэрвісаў для павышэння надзейнасці і назіральнасці.
   • Развівайце бізнес-логіку, каб быць ідэмпэнтным, прызнаючы, што збоі ў сетцы непазбежныя.
5. Агляд залежнасці. Рэгулярна правярайце і мінімізуйце знешнія залежнасці. Кожная знешняя залежнасць можа выклікаць патэнцыйныя SPOF, таму вельмі важна разумець і зніжаць гэтыя рызыкі.
6. Рэгулярны абмен ведамі. Ніколі не забывайце пра важнасць распаўсюджвання ведаў у вашай арганізацыі. Людзі могуць быць непрадказальнымі, і спадзявацца на аднаго чалавека рызыкоўна. Заахвочвайце членаў каманды алічбоўваць свае веды з дапамогай дакументацыі. Аднак памятайце пра празмернае дакументаванне. Выкарыстоўвайце розныя інструменты штучнага інтэлекту, каб спрасціць гэты працэс.

Заключэнне

У гэтым артыкуле мы разгледзелі некалькі ключавых аспектаў Макра і тое, як мы можам справіцца з іх складанасцю.

Дзякуй за чытанне! Да наступнай сустрэчы!