Всем привет. Меня зовут Тетка Андрей, я занимаюсь программированием уже больше 10 лет и за это время несколько раз приходилось разрабатывать архитектуру как крупных проектов, так и не больших фич. Я когда то уже делал вебинар на эту тему, но сейчас хотелось бы всё систематизировать и рассказать об этом вам.

И прежде чем мы начнем проектировать архитектуру, давайте сначала ответим на вопрос, а что же это собственно такое?

Ниже я привёл несколько картинок которые описывают ту или иную архитектуру


И как мы видим все эти картинки абсолютно разные. Так что же всё таки такое архитектура?

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

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


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

Ну хорошо, мы разобрались что такое архитектура и зачем она собственно нужна, но как же её собственно строить? 

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

Далее нам нужно понять, а зачем вообще заказчику понадобилась новая архитектура и почему мы должны её продумывать. Так же мы должны ответить на вопрос, а почему была выбрана именно текущая архитектура, и почему мы попали в ситуацию что заказчику нужно её поменять? Какие проблемы мы имеем с текущей архитектурой?

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

  • fault tolerance (reliability) / отказоустойчивость (надёжность)

  • speed of development / скорость разработки

  • ease deployed / простота деплоя

  • scalability by the number of people in the project / масштабируемость по количеству человек в проекте

  • scalability in terms of requests per second / масштабируемость по количеству запросов в секунду

  • fast entry / exit to resolution / быстрый вход/выход в разработку

  • application deployment speed / скорость развертывания приложения

  • remove old code / избавиться от старого кода

  • complexity of adding new integrations / сложность новых интеграций

  • etc. / И т.д.

Например на одном из моих проектов важно была отказоустойчивость, но вот масштабируемость проекта, чтобы на нём могли находиться тысяча человек одновременно - не требовалось. Есть проекты в которых наоборот нужно чтобы миллионы пользователей могли одновременно сидеть, но если у одного из них случались проблемы(например сообщение не отправилось за 5 секунд), то это не критично, отправим его через 10 секунд.

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

Такс, а теперь давайте ещё раз повторим вопросы на которые нам нужно ответить. Их всего 5:

  1. Что мы делаем?

  2. Почему мы имеем текущую архитектуру?

  3. Почему нам нужна новая архитектура?

  4. Какие проблемы мы имеем с текущей архитектурой?

  5. Что хочет наш клиент от новой архитектуры?

Ну а теперь мы можем приступать к разработке нашей новой архитектуры.

Продолжение следует:

Часть 2: https://habr.com/ru/post/658151/

Комментарии (10)


  1. SergeiMinaev
    06.04.2022 22:00
    +16

    ease deployed / простата в деплоя

    Это сильно :)


    1. Albert2009ru
      06.04.2022 22:11
      +10

      Профилактика деплоя простаты - быстро, качественно, недорого...


  1. XaBoK
    06.04.2022 22:32
    +2

    То, что на некоторых картинках есть слово архитектура, ещё не делает их таковыми. А что выражает график maintainability - я так и не понял. Со временем технический долг упирается в асимптоту или уходит к розовым и голубым?

    fault tolerance != reliability, пример scalability тоже довольно своеобразный, remove old code - ужасная формулировка, которая приводит к ошибочным выводам.

    Ну и, конечно, весь текст построен на том, что чтобы вы могли сделать архитектуру, кто то другой её уже должен был создать и воплотить.


    1. Koval97
      07.04.2022 12:37
      -1

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

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

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


      1. XaBoK
        07.04.2022 14:14

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

        Для чего то маленького может быть достаточно просто диаграммы классов или схемы данных. Но это вряд ли архитектура, хотя это явно документы проектирования.

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


        1. Koval97
          07.04.2022 23:02

          Архитектура не может быть лаконичной, но может быть излишней и избыточной.

          DirectX, протокол USB, OpenGL с вами сильно поспорят.

          Умные люди целые книги о них написали, так что ещё и все ваши весёлые заявления идут лесом.

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

          Сразу напрашивается мораль из статьи "Теперь я не могу сделать даже маленький сайт":

          Похоже, я слишком много думаю наперёд.

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


  1. kav_k
    07.04.2022 07:50

    ...давайте разберемся, а зачем она собственно то нужна? И на самом деле ответ довольно простой и легко изобразить на следующей картинке...

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


  1. mirudom
    07.04.2022 13:03

    Kecven, а определение то есть, архитектуры?
    Может с какого либо и начать надо?


  1. XaBoK
    07.04.2022 14:28
    +2

    Статья сырая и требует доработки в содержании и изложении. Поэтому пост ушёл в минус. Чего я не пойму, так это зачем молчаливо сливать автору карму? Дайте критику и шанс исправить, а не просто блокируйте.


    1. Kecven Автор
      09.04.2022 13:40

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