Past na vzory

Бъдете честни: ако сте в софтуерната разработка повече от няколко години, вероятно сте присъствали на архитектурна ревизия, където някой извади каталог с модели като келнер, поднасящ меню. „Тук можем да използваме Factory. Може би Strategy pattern там. Чували ли сте за CQRS?"

Това не е архитектура. Това е търсене на съответствия, маскирано като инженерство.

Мисъл, която непрекъснато се появява в общностите на разработчиците, улавя това перфектно: страхотната софтуерна архитектура произлиза от моделирането на самия проблем, а не от опитите да се натъпче проблемът в предварително определен набор от модели. Най-добрите разработчици се учат как да използват инструментите си, разбират материалите си и след това следват визията си — вместо да посягат към форми за бисквити, които затъмняват очевидното решение, което стои точно пред тях.

Защо уеб ресурсите за разработка са навсякъде, но архитектурата за системно програмиране е трудна за намиране?

Ако искате да научите за микрослужби, оркестрация на контейнери или разпределени системи в уеб контекста, поздравления — давите се в ресурси. Но какво, ако изграждате компилатор, вградена система, двигател на игра или база данни?

Пейзажът се променя драматично.

Повечето съдържание за „софтуерна архитектура" днес се фокусира върху проблемите на уеб мащабираните приложения: хоризонтално мащабиране, откриване на услуги, eventuality consistency и организационните предизвикателства, които идват с големи инженерни екипи. Това са легитимни проблеми, но те не са универсални проблеми.

За системните програмисти и разработчици извън уеб, речникът се променя. Мислите за:

• Оформление на паметта и модели на достъп
• Гаранции за латентност и ограничения в реално време
• ** среди с ограничени ресурси**
• Формална проверка, когато коректността е критична
• Изграждане за десетилетия поддръжка, не само за следващия спринт

Предизвикателството е, че добрите ресурси за този свят са разпръснати, често академични и рядко се определят като „архитектура", дори когато абсолютно са.

Какво всъщност помага: Ментални модели вместо модели

Вместо още един каталог с модели, ето менталните рамки, които са се доказали като най-ценни за изграждане на стабилни системи, независимо дали пишете вграден C или enterprise Java:

1. Ограниченията първо

Всяка система съществува в рамките на ограничения: бюджет, време, размер на екипа, изисквания за производителност, регулаторна среда. Архитектурата, която произлиза от дълбоко разбиране на вашите ограничения, винаги ще надделее върху „правилната" архитектура, която ги игнорира.

2. Потокът на данни като основа

Преди да мислите за класове, модули или услуги, разберете как данните влизат във вашата система, трансформират се и излизат. Архитектурата често става очевидна след като това се картографира ясно. Странните абстракции отпадат; необходимите стават ясни.

3. Собственост върху зависимостите

Кой притежава тези данни? Кой може да промени това състояние? Ясните отговори на тези въпроси предотвратяват повечето архитектурни бъркотии. Объркването около собствеността — особено собствеността върху данни — е мястото, където повечето системи започват да гният.

4. Цената на индиректността

Всяка абстракция има цена. Всеки слой на индиректност прави дебъгването по-трудно и производителността по-трудна за разсъждение. Въпросът не е „трябва ли да абстрахирам това?", а „каво купувам с тази абстракция и си струва ли цената?"

5. Локалитет на поведението

Код, който е лесен за разбиране сам по себе си, който не изисква да държите три файла в главата си едновременно, е код, който ще оцелее през следващите пет години поддръжка. Архитектура, която създава когнитивно натоварване, рано или късно ще бъде опростена — често от някой, който не разбира защо е бил изграден по този начин.

Препоръчани ресурси (не от уеб вида)

Ако търсите да задълбочите архитектурното си мислене, без да попаднете в заешката дупка на моделите за уеб мащаб, помислете за:

• „A Philosophy of Software Design" от John Ousterhout — Това остава една от най-ясните мисли за управление на сложността в софтуерните системи. Езиково-агностично е и дълбоко практично.

• Документи за операционни системи и разпределени системи от академичната литература, особено тези, предхождащи ерата на микрослужбите. Документи за дизайн на файлови системи, например, съдържат архитектурна мъдрост, приложима далеч отвъд файловите системи.

• Четене на изходния код на добре проектирани системи — Това звучи очевидно, но повечето разработчици не го правят систематично. Разбирането как бази данни, компилатори и добре проектирани проекти с отворен код решават трудни проблеми ще ви научи повече от всяка книга с модели.

Изкуството зад науката

Ето неудобната истина: софтуерната архитектура е повече изкуство, отколкото наука, и това няма да се промени.

Можем да говорим за принципи и евристики. Можем да измерваме coupling и cohesion. Можем да създаваме модели и диаграми. Но в крайна сметка архитектурата отразява преценката на хората, изграждащи системата — тяхната способност да видят проблема ясно, техния опит с това, което обикновено се обърква, и тяхното умение да правят компромиси, които служат на реални нужди, а не на теоретични идеали.

Разработчиците, които изграждат най-добрите системи, споделят обща черта: те са дълбоко любопитни относно проблемната област, не просто относно технологията. Те питат „защо това е трудно?" преди да попитат „какъв модел трябва да използвам?"

Започнете оттам. Разберете дълбоко проблема си. Оставете решението да се появи. И когато някой се опита да ви продаде модел като архитектура, попитайте го какъв проблем решава — и дали този проблем всъщност съществува във вашата система.