Архитектор ПО: зачем он нужен и в чём его проклятие

    Гость нового выпуска подкаста «Сушите вёсла» — архитектор программного обеспечения Егор Тафланиди. Обсуждаем, что это за метафизическая роль такая, какие сложности есть в работе и при чём тут тёмные силы.

    image

    Артём Кулаков и Рома Чорыев — разработчики Redmadrobot. Они записывают ламповые подкасты, где вместе с гостями обсуждают разные стороны создания ИТ-продуктов. Ниже ссылка на новый выпуск и ответы на несколько насущных вопросов.


    Тайминг
    01:40 Егор рассказывает, как стал архитектором
    12:40 Популярные мифы: архитектор — высшая ступень развития разработчика; архитектор знает всё лучше всех и больше всех; архитектор не пишет код (потому что забыл как это делать); архитектор сидит и рисует какие-то схемы
    31:20 Рассуждения о современных языках программирования
    39:10 System/Solution/etc Architect. Что это вообще всё значит?
    47:50 Обсуждение того самого «проклятия»
    50:24 Как стать архитектором (warning: немного шуток)
    55:16 Time management: один рабочий день архитектора — что он делает?
    01:03:39 Какие есть сложность в работе и как их преодолеть
    01:13:49 А что дальше: какие есть векторы развития
    01:26:59 Ответ на вопрос: какой же true way для архитектора?

    Кто такой архитектор ПО?


    Архитектор — специалист, который занимается построением ИТ-систем для решения бизнес-задач. Он хорошо разбирается во всех нюансах проектирования систем.

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

    Архитектор должен разбираться во всём?


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

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

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

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

    Пишет ли архитектор код?


    Если коротко, то некоторые архитекторы кодят. Подробнее об этом — в пятиминутном рассуждении в подкасте, начиная с 22:25. Спойлер: там про идеальный код, проблемы перфекциониста и бизнес-требования.

    Как стать архитектором?


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

    — У нас было так: компания развивалась, росло количество людей и проектов. Качество нужно было поддерживать, поэтому настал момент, когда появилась свободная «ниша ответственности».

    Архитектор — высшая ступень разработчика?


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

    А что за «проклятие»?


    Так объясняет этот феномен Егор:

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

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

    Слушайте подкаст на удобной платформе — SoundCloud, Apple, Google Podcasts.

    Полезные ссылки


    Важные статьи, видео и книги для тех, кто хочет трансформироваться в архитектора:

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

    Software Architecture in Practice, L.Bass — азы бытия архитектором.

    Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives — одна из основных книг, которая наиболее полно раскрывает принципы работы архитектора.

    Release It!: Design and Deploy Production-Ready Software — истории про то, как надо проектировать ПО и что бывает, когда оно спроектировано криво.

    Patterns of Enterprise Application Architecture — мемуары старины Мартина Фаулера о том, как надо проектировать ПО.

    Domain-Driven Design — Tackling Complexity in the Heart of Software E.Evans — про правильное моделирование.

    Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development C. Larman — проеĸтируй @ доĸументируй, %username%.
    Разработĸа требований ĸ программному обеспечению, К.Вигерс — Microsoft пишет про разработĸу требований.


    Обзор паттернов проектирования.

    Приходите обсуждать выпуск в Telegram-чат.
    red_mad_robot
    №1 в разработке цифровых решений для бизнеса

    Comments 3

      0
      Архитектор задействован в разных ситуациях: он общается с заказчиком, решает инженерные проблемы и даже участвует в планировании проекта.

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


      There, I fixed it.

        0
        Нет такой проблемы, которая не решается новым слоем абстракций

        Проблема увеличения когнитивной сложности не решается. Хорошая архитектура не просто решает указанную задачу в краткосрочной перспективе, но и задачу поддержки и развития системы в будущем, если система выживет. Большая разница дорабатывать простую и лаконичную систему или систему раздутую лишними сущностными. Очень жду те времена, когда когнитивную сложность наконец начнут вносить в KPI наравне с масштабируемостью или метриками производительности.
          0
          Это распространенная в среде программистов шутка. Конечно же вы правы и не стоит добавлять абстракции ради абстракций. Да и порой для решениях проблем их добавлять не стоит. Нужно остановиться, подумать и все взвесить.

        Only users with full accounts can post comments. Log in, please.