Архитектура ПО: что это значит и как выстроить свою

Все разработчики, с которыми мне приходилось сотрудничать, так или иначе упоминали термин «архитектура». Хотя это очень размытое понятие, им оперируют почти все. Я долго пытался разобраться сам: что имею в виду, когда говорю, что это часть архитектуры, а это — нет. Статьи на Wikipedia и в некоторых других источниках крайне занудные. Похоже, что понятие довольно старое и не имеет четкого определения внутри современных Agile стилей разработки. Но мы по-прежнему оперируем им. Поэтому постараюсь дать определение этому понятию в рамках Agile Development Process.

Что считать архитектурой

Начнем с того, на чем сходятся все источники:

  • Архитектура — это фундаментальные договоренности и решения.
  • Архитектура — это нечто важное.
  • Архитектуру сложно менять.
  • Архитектура должна быть использована повторно (в силу своей клевости, естественно).

Это, пожалуй, все. Помимо этого, есть много шума о том, как именно она должна создаваться и какие есть подходы по управлению ею. Во всех этих описаниях используются такие мудреные слова, что сложно представить подобные процедуры в рамках Agile процессов.

Важная мысль, которая, как мне кажется, является истоком понятия архитектура, — «Архитектурные решения сложно менять» или, другими словами, «Решения, которые сложно поменять, — архитектурные». И это действительно то, что имеет наибольшее значение.

То, насколько сложно поменять решение, определяет степень его архитектурности. Также важно, что любое решение легко поменять на следующий день после его принятия или легко поменять решение, которое мало на что влияет. Причем в данном случае «решение»- это как программное решение, так и просто договоренность (которая рано или поздно все равно закрепляется программным решением).

На уровне кода это можно выразить так: архитектурный код или софт — это тот, который используется повторно наибольшее количество раз. Причем это правда как для кода, написанного вами лично, так и для заимствованного.

Пример: степень архитектурности базы данных — это количество данных, которые в ней хранятся. То есть чем больше вы храните данных в этой конкретной базе, тем более архитектурна она для вас. С другой стороны, подключенная к проекту база данных, в которой пока или уже ничего не хранится, архитектурой не является. При этом важно сделать упор именно на то, насколько сложно потом эту базу сменить. Например, если вам понадобится поменять MySQL на PostgreSQL, то архитектурность MySQL будет зависеть от количества специфичных ее фич, которые вы использовали.

Очень важно отслеживать архитектурность тех или иных решений по мере развития проекта, а не только при его зарождении. В outsource-компаниях часто встречается подход, когда в новый проект приходит важный дядя (например, CTO компании) и создает архитектуру, а на следующий день уходит из проекта. Его решения действительно важны, но архитектура им не строится, а строится теми, кто эти решения использует.

Так, возвращаясь к примеру с базой данных, важно отмечать дополнительные завязки на MySQL по мере их появления. Если вы используете ORM поверх базы — появляются они, как правило, не сразу, а намного позже.

Что важно заложить в начале проекта

Конечно же, в начале любого проекта принимается много архитектурных решений: как хранить данные, какой выбрать язык программирования, какой framework? Но также важно понимать, что все еще можно поменять на первых стадиях работы над проектом. И только со временем эти решения становятся настоящей архитектурой — той, которую сложно поменять.

С этой позиции не все начальные решения покажутся настолько прям архитектурными. Например, выбор языка программирования — явно архитектурное решение, потому что его изменение почти равносильно переписыванию проекта с нуля. А выбор key-value базы данных — не очень фундаментальное решение, поскольку подобных баз данных много и можно заменить одну на другую гораздо легче и незаметнее. Сделать это до выхода проекта в production вообще не составляет особого труда.

Очень часто в новых проектах доминирует философия: «Нам нужно с самого начала сделать все правильно, потому что потом у нас не будет времени что-то менять». Это правда, потому что все время потрачено на то, чтобы сделать все правильно, а не на то, чтобы делать корректировки по ходу, которые и представляют собой суть Agile процесса.

Кроме того, команда или отдельные люди часто не хотят признавать ошибочность своих первоначальных решений или хотя бы непредсказуемость развития проекта. Agile, увы, так не работает... По моему опыту, вот список базовых вещей в порядке их важности, которые следует выбрать правильно изначально и потратить на это дополнительное время:

  1. Структура хранения данных
  2. Язык программирования
  3. Development Framework

Все остальное, как правило, можно поменять или выбрать по ходу с гораздо меньшей ответственностью. Если ваш проект проживет достаточно долго, то рано или поздно все остальное придется менять и адаптировать.

Своя или заимствованная архитектура

Зачастую заимствованные программные решения гораздо проще поменять, чем собственные разработки. Так происходит потому, что заимствованный софт совсем ничего не знает о ваших личных целях и задачах. Он решает общие для всего software-community проблемы, которые решены не один раз и похожим способом: поменять один хостинг на другой будет несравнимо проще, чем поменять структуру данных, вами же созданную.

Создание архитектуры из собственного кода в долгоиграющих проектах очень важно. Все начинается с простого повторного использования кода: кто-то написал класс или метод и кто-то им воспользовался. Архитектурность кода как раз определяется количеством его повторных использований. Первый хороший звоночек, что у вас это получается — если написанный вами метод используют другие члены вашей команды без принуждения. Это говорит о том, что им проще положиться на ваш код, как на архитектуру, чем создавать что-то с нуля.

Все мы знаем, как программисты любят создавать велосипеды. Причин этому две. Очевидная — неумение этих программистов адаптировать существующие решения под свою задачу. И неочевидная — низкое качество кода внутри проекта. Думаю, что каждый из нас был по обе стороны баррикады: не хотел использовать код, написанный другими, и писал код, который другие не хотят использовать. Архитектуру можно построить, только если научиться писать свой качественный код и применять старый код.

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

Как же построить свою архитектуру

  • Следить за явными и не очень явными повторениями кода и устранять их сразу.
  • Искать решения похожих проблем, а не только в точности одинаковых.
  • Писать тесты.
  • Обобщать и адаптировать старые решения под новые задачи.
  • Понимать необходимость создания собственной архитектуры для конкретного проекта как важной надстройки над заимствованной.
  • Не бояться менять и расширять код других членов команды (особенно экс-сотрудников, кода которых все боятся как огня).
  • Создавать что-либо с нуля, только если достаточно уверены, что нет абсолютно никаких наработок на эту тему внутри проекта.
  • Понимать, что создание архитектуры — непрерывный процесс, а не просто разовая акция по принятию архитектурных решений.
  • Отслеживать степень завязки проекта на конкретные решения и своевременно их корректировать по ходу его развития.
LinkedIn

44 комментария

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

На основе статьи, для построения «своей» архитектуры должен случиться диалог по типу:
ПМ: Эй, парень, нужно изменить код другого парня, он вчера уволился. Там есть повторения.
ДЕВ: Я боюсь.
*Конец, везде огонь*

рука-лицо.
Мой любимый вопрос: «Какая у вас архитектура на проекте?» Единственно ожидаемый мной ответ звучит примерно так: «А какая архитектура вас интересует?»
Business/Information/Solution/Data Architecture — не, не слышали.

рука-лицо.

Казалось бы и при чем тут теорема CAP? :)

Структура хранения данных

На цьому можна завершувати. Структура на довгострокових проектах змінюється зі швидкістю світла. Що б не закладував, все в смітник піде. Краще закладати гнучкість як основу, тоді страждати не будете.

Ну да, на всех проектах происходит точно то же что вам говорит ваш частный опыт =D
На одном проекте на котором я работал, что бы описать объемы и серьезность данных — так вот на нем в день каждый бизнес день генерится более лимона репортов клиентам, и не пустышек!
Так вот, когда я пришел на проект там был актуальны ранбук с описанием общей логики и общей структуры данных, созданный 10 лет назад!
Конечно, некоторые слои обновляются и расширяются, но вот именно это можно назвать хорошей архитектурой, когда офигиваешь видя что кор архитектура, заложеная 10 лет назад в таком бизе как инвестиционные финансы — до сих пор актуальна.
А те кто

Структура на довгострокових проектах змінюється зі швидкістю світла

Делают просто херовую архитектуру и меняют ее каждый раз когда дым начинает идти из...)

Делают просто херовую архитектуру

Швидкість бізнесу та вимог бізнеса змінилися з тих часів. Хто це зрозумів — виживе. Хто ні — потоне. Раніше до мільярдного обороту можна було йти десятиріччями, зараз це можливо за три роки. І не тому що гроші знецінилися, а тому що процеси стали протікати в сотні разів швидше.

Швидкість бізнесу та вимог бізнеса змінилися з тих часів

Не стоит обобщать весь бизнес. У стартапов и банков кардинально разные виды деятельности, например, и подходы к информационным системам у них будут совершенно разные.

Банки сьогодення набагато більш динамічні, ніж вони були 10 років тому. Якщо раніше це були монолітні програмні комплекси, то зараз все більше використовується підхід мікросервісів. Банки почали інтегруватися із різними зовнішніми сервісами та між собою. Прискорювати та автоматизовувати процес прийняття рішень. Вимоги до захисту даних та протидії шахрайству теж помінялися. Хто не встигне змінитися — вимре як мамонт.

о чем вы говорите, декомисия одной кор системы может занимать от года до 2 лет, ввод вместо нее новой — не менее года. И таких систем в банках может быть до 3000.
та еще скорость света

Структура на довгострокових проектах змінюється зі швидкістю світла.

Все-таки скорость ограничена скоростью работы ЕТЛей, которые перегоняют данные в новый формат :)
Бывают вообще ужасные ситуации, когда есть дата-архитектор (борд), который фиксирует определенную структуру и никого не и...волнует что нужно команде, которая пишет бизнес-логику

Не бояться менять и расширять код других членов команды (особенно экс-сотрудников, кода которых все боятся как огня).

Экс-сотрудник тоже не боялся трогать этот код?

Архитектура — это нечто важное.

Грубо говоря, архитектура системы — это совокупность ключевых принципов, технологий, элементов и отношений между ними, алгоритмов и т.д. этой системы, изменения которых существенно влияют на всю системы в целом.
Вот тут хорошо расписано по теме — www.ibm.com/...​onal/library/feb06/eeles

Я бы мог написать пример антиархитектуры и осветить моменты когда она не нужна.

— Так мне Паваротти не понравился, картавит, в ноты не попадает...
— Вы были на концерте Паваротти?
— Нет, мне Рабинович по телефону напел.
(старый бородатый анекдот)

Я долго пытался разобраться сам: что имею в виду, когда говорю, что это часть архитектуры, а это — нет. Статьи на Wikipedia и в некоторых других источниках крайне занудные.

Стесняюсь спросить, а «CTO» у вас в профиле — это как расшифровывается? А то никак не могу поверить, что такое может написать Chief Technology Officer...

Добавлю от себя ссылочку en.wikipedia.org/wiki/Systems_design
Сферический конь обычно в какой то среде летает поэтому среду эту тоже имеет смысл учитывать.

Где-то сейчас заплакал выпускник SEI.

Пример: степень архитектурности базы данных — это количество данных, которые в ней хранятся.

Мда... Нечасто такое встретишь Бог с тем что такой термин встречается мне впервые в жизни (бывает)
Но Вы правда считаете что кол-во данных определяет степень архитектурности (еле заставил употребить сей термин) ?

Простой пример
1 База содержит 1 таблицу и миллиард строк
2 База содержит схему из 1000 таблиц и 1 строку в каждой + куча сервер сайд логики

Выходит в первом случае архитектор молодец...

Следует ли доверять такому СТО ?!

именно о первом случае подумал. Покупали для одного проекта базу данных адресов, которая из одной такой таблицы и состояла. Данных много, все отлично работает после индексирования, но где здесь «архитектурность»?

Вы ведь хорошо понимаете суть: дело не совсем в объеме данных, не совсем в колличестве записей. Скорее дело в том насколько сложно будет менять эту RDBMS, структуру или данные. «Степень архитектурности» — да... термин не очень. Лучше сказать «Степень завязки на решение». Предложите лучше свой термин если можете....

Трёхзвенная архитектура на Delphi — это вам не фунт изюма...

Уже думал ставить лайк не глядя, а тут такая пустышка...
— во первых ни одного дельного реального совета, где описанные подходы к анализу и построению архитектуры (как например сверху-вниз, снизу-вверх), где общепринятые подходы построения моделей на разных уровнях, начиная с концептуального и заканчивая физическим, где специфика построения архитектуры со стороны информационных потоков внутри экосистемы?
— во вторых некоторые утверждения реально сомнительны.

С другой стороны, подключенная к проекту база данных, в которой пока или уже ничего не хранится, архитектурой не является.

чеееее? тоесть выбрали технологию, модель, завязали на нее 40% кода, все выкатили, начали лить данные, на 0.1% проценте оказалось что были допущены фундаментальные ошибки и модель надо менять, а значить не только модель а и 40% всего кода — и она для вас по прежнему недостаточно архитектурная? (что за термин ваще, sic)
— в третьих — где бест практис, хотя бы названия упомянуть что бы было от чего строить свои архитектуры тем кто начинает это делать?

Одна вода.

Архитектура — это выбор самого современного хайпового фреймворка, о чем статья вообще?

Статья о том, что автор не может в архитектуру.

1) Архитектура — это впринципе любой код, любого вида и любой структуры. Вопрос лишь в том что есть хорошая архитектура, а что есть плохая.
2) Что есть хорошая архитектура — это не более чем организация разработки, деплоймента и выполнения нацеленная на минимизацию общих расходов компании/проекта. Проще говоря лучше так которая стоит дешевле и делает тоже самое. Все остальное про как строить код и прочее не имеет к ней никакого отношения, так как это частные случа которые когда то дают резалт а когда то нет.
3) что же делать что бы строить хорошую архитектуру? — Научиться понимать бизнес, его издержки и структуру работы, смотреть на продукт в целом на не только со стороны ИТ.
Как пример вот вам архитектура ФБ, основной идеей в которой есть использование дешевых и часто выходящи из строя серваков, не потому что это проще, круче или юзабильней, а только лишь потому что это экономит компании миллионы долларов.
А посему если вы делаете дорогую архитектуру то это на 100% Говно.

1) Архитектура — это впринципе любой код, любого вида и любой структуры. Вопрос лишь в том что есть хорошая архитектура, а что есть плохая.

Архитектура — это совершенно не обязательно код. Это может быть например документ. Или рисунок фломастерами на доске.

А посему если вы делаете дорогую архитектуру то это на 100% Говно.

Скажем так, я бы постеснялся делать такие резкие и всеобъемлющие утверждения.

Архитектура — это совершенно не обязательно код. Это может быть например документ. Или рисунок фломастерами на доске.

Все это идеи, пока они не реализованы то это План архитектуры, но никак не архитектура. Это всеравно что 3д модель машини назвать машиной.

Скажем так, я бы постеснялся делать такие резкие и всеобъемлющие утверждения.

Если человек не делает финальных утверждений то он балобол желающий всегд отмазаться от своих слов. Мне отмазывать не от чего. Можете пойти спросить своего гендира, и я думаю ответ будет крайне похож на мой)

Все это идеи, пока они не реализованы то это План архитектуры, но никак не архитектура. Это всеравно что 3д модель машини назвать машиной.

Это ваша личная тока зрения, совершенно не соответствующая отраслевым определениям и признанным «best practice». Одно из них я привел ниже. «Финальное утверждение» про ценность этой точки зрения я пожалуй приводить не буду. :)

Если человек не делает финальных утверждений то он балобол желающий всегд отмазаться от своих слов.

Вы выборочно прочитали мой предыдущий пост. Проблема в том что категоричность совмещается со всеобъемлемость. Тоесть утверждать что «архитектура твиттера — говно» или там «архитектура ФБ — это няшка», особенно если аргументировать — это неплохо, но когда «финально» и про 100% — это уже говорит как минимум об недочно широком вИдении.

Можете пойти спросить своего гендира, и я думаю ответ будет крайне похож на мой)

Спасибо, я посмеялся. CEO ~25000 инженеров — он совершенно нетехнический и не архитектурами занимается. Впрочем отмечу, мне повезло с ним пообщаться(не тет-а-тет ессна ж), и он был очень «нефинален» в своих утверждениях, даже по отношению к подчиненным. :)

Люди делять на 2 типа, которые принимают решения, и те которые от них уходят.
Хотите мазать по стене дело ваше, но не стоит выдавать это за положительное качество а тем более рекомендовать так делать другим. Дал бы я вам покамандовать ротой солдат и посмотрел чего бы стоила ваша «некатегоричность». А бизнес это еще по жешче войны будет.

Ну тоесть вы предлагаете вообще отказаться от каких либо метрики в стиле толерастии, и все называть «ну впринципе ок».. тока непонятно тогда вообещ куда двигаться.. если на вопрос на «на лево, направа или прямо», будут отвечать «нельзя быть таким категоричным давайте поедим кругами и боком»)

Меня мало интересует в каких утвеждениях он был нефинален. спросите его конкретно об этом вопросе. Темы из серии «какие девушки кому нра», к вопросу врядли имеет отношение)

Я посмеюсь вместе с вами, когда ваша ЗП будет напрямую зависить от профита компании, а не я получаю ЗП, а что там с продуктом мне пох) А то все такие мастера слова.. тока чето работают на ставочку без рисков))

Вы так ничего и не понял, приписали мне зачем-то что я «желаю отказываться от метрик» и «ууходить от отвественности». Ну да ладно, надеюсь повзрослеете.

Ваша надменность прям так и прет и это при том что судя по резюме из зоны компфорта вы в жизни не вылазили. Сделайте пару бизнесов, подымите пару проектом из минусов в профит, а потом уже говорите о взрослости и ответсвенности.

Сперва добейся :)
Переход с аргументов на личности говорит лучше любых других дел, резюме и распальцовки :)

Андрей вышел из зоны комфорта, стал СТО и сроит дешевую архитектуру. Не мешайте ему самоутрверждаться.

Предалгаю вам подучить немношка русский и перичитывать свои посты хотя бы ра. ))

> Все это идеи, пока они не реализованы то это План архитектуры, но никак не архитектура. Это всеравно что 3д модель машини назвать машиной.

Архитектура — это как раз совокупность высокоуровневых идей об устройстве системы, о её разбиении на компоненты и взаимодействии этих компонентов друг с другом. А код архитектуру реализует. Одну и ту же архитектуру можно реализовать практически бесконечным множеством способов. Например, одну и ту же архитектуру можно реализовать на разных языках программирования с различиями лишь на уровне синтаксиса. Где-то больше кода придётся писать, где-то меньше, но архитектура будет одна.

Архитектура — это впринципе любой код, любого вида и любой структуры.
Что есть хорошая архитектура — это не более чем организация разработки, деплоймента и выполнения
А посему если вы делаете дорогую архитектуру то это на 100% Говно.

pbs.twimg.com/...​media/CLl0bKMWcAA92Xt.jpg

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

В Вашем примере важно только наличие регистрации как таковой и ее удовлетворение требованиям бизнеса. Реализация процесса регистрации может быть любой. Если это легко изменить, я бы не вкладывал силы в детальное и фундаментальное ее проектирование. Это и есть идея статьи: не вкладывайтесь в то что легко изменить.

Если честно, я не до конца понял идею вашей статьи, у меня сложилось впечатление что вы просто рассуждаете вслух.

не вкладывайтесь в то что легко изменить.

Процесс регистрации может иметь разную важность в зависимости от типа приложения. Где-то это неважный процесс с поддержкой одного возможного метода. Где-то интегрированы все возможные современные методы, а легкость, удобство и стабильность работы регистрации — это залог доходов бизнеса. В зависимости от этого и выбирается насколько нужно вкладываться в продумывание решения а также его гибкости, защиты, устойчивости и возможности масштабирования. Хотя и в первом и во втором случае это решение не используется повторно и его можно менять.

Улыбнуло, но в целом статья относительно вменяемая и выдает человека прошедшего по граблям в небольшом проекте(не обязательно на позиции архитектора),но со слабой теоретической подготовкой.
Что бросилось в глаза:

Что считать архитектурой

Внезапно оказывается что в источниках написан ответ. Даже есть несколько определений, лично мне больше всего нравится

The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.

Это гораздо более полное и четкое определене, чем данное ТС, хотя его определение «полной дичью» назвать нельзя и в нем есть капля здравого смысла. Более того,в книжке, в которой это определение дано, целая глава посвящена его обьяснению.

На уровне кода это можно выразить так: архитектурный код или софт — это тот, который используется повторно наибольшее количество раз. Причем это правда как для кода, написанного вами лично, так и для заимствованного.

Это в корне неверно. Пример: left-pad в javascript. Это совершенно не архитектурная библиотека, однако использовалась чуть более чем везде: www.theregister.co.uk/...​03/23/npm_left_pad_chaos
Более того, огромное количество архитектурных решений имеют весьма косвенное отношение к коду разрабатываемых приложений, как то: схема деплоймента, организационные изменения компании(это более к ентерпрайз, но тем не менее), покупка решений вместо разработки своих, разработка стратегии тестирования, меры обеспечения безопасности(включая физические) и так далее.

Например, выбор языка программирования — явно архитектурное решение, потому что его изменение почти равносильно переписыванию проекта с нуля.

Еще одна предпосылка, верная только в узком спектре проектов. Например в SOA(особенно микросервисной) архитектуре, язык программирования конкретного микросервиса совершенно неважен. В монолитах скрещивание ужа с ежом, С/С++ со всем, джаву с дотнетом, пхп с чем нить еще и так далее встречается очень часто.
Аналогично про хранилища данных. Выбор конкретного решения может быть. а может не быть архитектурным решением.

В outsource-компаниях часто встречается подход, когда в новый проект приходит важный дядя (например, CTO компании) и создает архитектуру, а на следующий день уходит из проекта.

Такое бывает не только в аутсорсе. Банально потому что архитектора нечем занять на 100% на этапах активного девелопмента. Он нужен точечно, для принятия/документирования важных решений которые надо принять по ходу проекта(причин — миллион). Если архитектора держат на 100% на фазе констракшна, то он обычно занимается техлидством.

Своя или заимствованная архитектура

Вопрос сформулирован в корне неверно. И своих и заимсвованных архитекур может быть десятки и сотни. Правильный вопрос: «какую архитектуру выбрать чтобы решить проблему бизнеса максимально эффективно?»

Как же построить свою архитектуру

Исходя из неправильного вопроса выше, советы тут абсолютно нерелевантны и даже вредны. Этот вопрос подробно разобран в литературе, к ней и направляю автора. Надеюсь в гугле его не забанили.

Нужно больше абстрактных обобщений, а то эта теория еще как-то соотносится с реальными задачами.

Очевидная — неумение этих программистов адаптировать существующие решения под свою задачу.

Особенно когда существующее решение — это фюзеляж для самолета, а тебе нужно колесо для мотоцикла.

А где про архитектуру?

Как же построить свою архитектуру
Писать тесты.

Подписаться на комментарии