Критерии за добра софтуерна архитектура

Ефективност

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

Въпреки това, ако се замислите, можете да напишете редица критерии, на които трябва да отговаря една добра архитектура. Добрата архитектура е преди всичко логична архитектура, която прави процеса на разработване и поддържане на програма по-прост и по-ефективен.

Когато една програма има добра архитектура, винаги е достатъчно лесно да разберете How работи и къде да напишете code. Една добре проектирана програма е по-лесна за промяна, тестване, отстраняване на грешки и разработване. Умните хора са формулирали следните критерии за добра архитектура:

• Ефективност;
• Гъвкавост;
• Разширяемост;
• мащабируемост;
• тестируемост;
• Поддържаемост на codeа.

Ефективност на системата. Програмата, разбира се, трябва да решава възложените задачи и да изпълнява функциите си добре и в различни условия. Изглежда, че всяка програма прави това, което трябва (ако е написана), но често това изобщо не е така.

Постоянно ще срещате програми, които не правят това, за което твърдят, че правят.

• Libre Office е пълен заместител на Microsoft Office (не наистина);
• Браузърът Edge поддържа всички уеб стандарти (не наистина);
• Банката се грижи за сигурността на личните данни на своите потребители (всъщност не).

И все още не сме засегнали производителността, надеждността, навременните корекции на грешки or публикуването на информация за известни уязвимости.

Ясно е, че никой не е съвършен, но програмата трябва да решава основните си задачи. Следователно, без ефективност, никъде.

Гъвкавост

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

Много често начинаещите програмисти/архитекти смятат, че имат нужда от идеална архитектура за текущи задачи. Не. Имате нужда от идеална архитектура за задачите, които ще ви бъдат обявени след година. Вие, вече не знаейки бъдещите задачи, трябва да знаете Howви ще бъдат те.

Няма смисъл да се опитваме да ги прогнозираме, защото винаги ще има нещо неочаквано. Но трябва да имате предвид, че такива задачи ще се появят. Следователно, в процеса на разработка, опитайте се да оцените това, което се получава по отношение на това How ще трябва да бъде променено.

Запитайте се: „Какво ще се случи, ако текущото архитектурно решение се окаже грешно?“, „Колко code ще бъде променен?“. Промяната на един фрагмент от системата не трябва да засяга останалите й фрагменти.

Когато е възможно, архитектурните решения не трябва да бъдат фиксирани в камък и последствията от архитектурни грешки трябва да бъдат разумно ограничени. „Добрата архитектура ви позволява да ОТЛАГАТЕ ключови решения“ (Боб Мартин) и минимизира „цената“ на грешките.

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

Мащабируемост

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

Изглежда, че това правило се изпълнява от само себе си, но на практика всичко е точно обратното. Има дори супер популярна книга The Mythical Man-Month , която обяснява защо, когато се добавят нови хора към даден проект, времето за разработка се увеличава.

Разширяемост

Разширяемостта е способността да се добавят нови функции и обекти към система, без да се нарушава основната й структура. В началния етап има смисъл да поставите само основната и най-необходима функционалност в системата.

Това е така нареченият принцип ЯГНИ - няма да ти трябва , "няма да ти трябва". В същото време архитектурата трябва да ви позволява лесно да увеличите допълнителната функционалност, ако е необходимо. И така, че въвеждането на най-вероятните промени изисква най-малко усorя.

Изискването архитектурата на системата да бъде гъвкава и разширяема (т.е. да може да се променя и еволюира) е толкова важно, че дори е формулирано като отделен принцип - „Принцип отворен/затворен “ . Принципът отворено-затворено е вторият от петте принципа на SOLID: софтуерните единици (класове, модули, функции) трябва да бъдат отворени за разширение, но затворени за модификация .

С други думи: трябва да е възможно да се променя и разширява поведението на системата, без да се пренаписват съществуващи части от системата .

Това означава, че приложението трябва да бъде проектирано по такъв начин, че промяната на поведението му и добавянето на нова функционалност да се постигне чрез писане на нов code (разширения), без да се налага промяна на съществуващия code.

В този случай появата на нови изисквания няма да доведе до промяна на съществуващата логика, но може да се приложи предимно чрез нейното разширяване. Този принцип е в основата на "архитектурата на добавките" (Plugin Architecture). Техниките, чрез които може да се постигне това, ще бъдат обсъдени по-късно.

Спомняте ли си сървлети и филтри? Защо са необходими филтри и дори с отделни интерфейси, ако всъщност една и съща логика може да бъде реализирана с помощта на сървлети?

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

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

Тестваемост

Ако сте Java Backend разработчик, вашите сървърни applications често излагат набор от методи като REST API. И за да проверите дали всички ваши методи работят по преднаmeaning, те трябва да бъдат покрити с тестове.

Като цяло покритието на тестовете на API е добър стил. Това ви позволява да се уверите, че вашият API наистина прави това, за което е предназначен. И също така, което е по-важно, можете да направите промени в логиката на сървъра и лесно да проверите дали случайно не сте счупor нещо .

Веднага щом започнете да пишете тестове, ще разберете, че повечето codeове изобщо не могат да бъдат тествани: частни методи, силно свързване, статични класове и променливи.

„Защо имаме нужда от тестове, ако codeът работи?“, ще попита начинаещият.

„Защо ни трябва работещ code, ако не може да бъде тестван?“, ще попита професионалистът.

Кодът, който е лесен за тестване, ще съдържа по-малко грешки и ще бъде по-надежден. Но тестовете не само подобряват качеството на codeа. Почти всички разработчици в крайна сметка стигат до извода, че изискването за „добра възможност за тестване“ също е водеща сила, която автоматично води до добър дизайн.

Ето цитат от книгата Ideal Architecture: "Използвайте принципа на "тестваемостта" на клас като "лакмус" за добър дизайн на клас. Дори и да не напишете нито един ред тестов code, отговорете на този въпрос в 90 % от случаите ще помогне да се разбере How всичко е добро" or "лошо" с неговия дизайн."

Има цяла методология за разработване на програми, базирани на тестове, която се нарича Test-Driven Development (TDD). Това, разбира се, е другата крайност: пишете code, преди да пишете code.

Поддържаемост на codeа

По правило много хора работят по програмата – някои напускат, идват нови. Средното време на работа на един програмист в IT компания е година и половина. Така че, ако сте стигнали до проект, който е на 5 години, тогава само 20% от вашите колеги са работor по него от самото начало.

Поддържането и разработването на програма, която други са написали, е много трудно. Дори ако програмата вече е написана, често е необходимо да продължите да я поддържате: коригирайте грешки и правете малки корекции. И често това трябва да се прави от хора, които не са участвали в написването му.

Следователно добрата архитектура трябва да направи сравнително лесно и бързо разбирането на системата от нови хора . Проектът трябва да бъде:

• Добре структуриран.
• Не съдържа дублиране.
• Имате добре форматиран code.
• Желателно е да се приложи documentация.
• Необходимо е да се прилагат стандартни и познати на програмистите решения.

Можете лесно да оцените проекта, върху който работите, по 5-точкова система . Просто пребройте две точки за всяко от тези изисквания . И ако получите 5 or повече, значи сте късметлия.

Програмистите дори имат принцип на най-малкото изненадване : колкото по-екзотична е системата, толкова по-трудна е за другите да я разберат. Обикновено се използва във връзка с потребителския интерфейс, но е приложим и за писане на code.