Основы архитектуры программного обеспечения: от разработчика до архитектора программного обеспечения

* В части 1 — Основы архитектуры программного обеспечения: что, как и Почему мы обсудили, что такое архитектура программного обеспечения и процесс проектирования. Здесь мы обсудим путь от разработчика до роли архитектора.

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

1. Глубина и широта разработки программного обеспечения

   2. Решение проблем в группе

   * Прежде чем идти дальше, несколько пояснений по теме обсуждения:

* Мы обсуждаем роль архитектора, а не человека с назначением архитектора. Роль может исполнять один или несколько человек. Он может иметь разные обозначения в разных организациях. Также возможно, что разработчик берет на себя роль архитектора по мере необходимости. В любом случае человек, выполняющий роль архитектора, будет работать над принятием решений по архитектуре и дизайну, как описано в Архитектура программного обеспечения. Основы: что, как и Почему.

• Программное решение может иметь веб-портал, мобильное приложение и API в серверной части. Обсуждаемые здесь концепции являются общими и применимы ко всем областям.

Глубина и широта разработки программного обеспечения

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

* Сначала мы разберемся с различными функциями и основными компонентами этих функций в программной инженерии.

* Мы пройдемся по каждому, начиная снизу.

Бизнес-факторы

* Бизнес-факторы — это факты, полученные из трех аспектов:

1. Цель: каждое программное обеспечение пытается решить какую-то проблему в физическом мире или предложить своим пользователям определенные услуги.

   2. Отраслевой фон. Программное обеспечение работает с определенным фоном, таким как требования соответствия, отраслевые тенденции, конкуренция на рынке и т. д.

   3. Коммерческий. Программное обеспечение должно в конечном итоге помочь либо увеличить доход и/или уменьшить затраты, чтобы обеспечить жизнеспособность бизнеса. р>

Управление продуктом/Бизнес-анализ

* Требования к Программному обеспечению формируются на основе ясности из Бизнес-драйверов и других входных данных, таких как исследования пользователей и т. д.

Инженерия

* Инжиниринг — это процесс преобразования требований в реальность, т. е. работающее программное обеспечение.

* Инженерное дело состоит из трех основных компонентов:

1. Архитектура и amp; Дизайн

   * Архитектура и усилитель; Дизайн — это Визуализация того, как Требования будут преобразованы в Рабочее ПО.

   2. Кодовая база

   * Кодовая база — это реализация Требований и Архитектуры & Дизайн.

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

   3. Развертывание

   * Программное обеспечение должно иметь некоторые предпосылки для работы, такие как операционная система, среда выполнения (например, JVM, узел и т. д.), конфигурация и т. д., которые являются его средой. Развертывание позволяет кодовой базе запускаться в Среде и позволяет пользователям использовать Программное обеспечение.

   * Отношения между тремя компонентами можно описать следующим образом:

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

Операции

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

Теперь с этим пониманием мы попытаемся понять путь от разработчика до роли архитектора.

Роль разработчика

• Разработчик в основном сосредоточится на кодовой базе и частях требований, которые имеют отношение к работе.

* Это не означает знаний о других компонентах, таких как архитектура, развертывание и т. д., но основное внимание уделяется реализации проектов и требований.

Роль архитектора

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

* Очевидный вопрос: «Почему?». Итак, давайте пройдемся по каждому из них:

1. Архитектура & Дизайн

* Это просто. Роль архитектора потребует хорошего понимания архитектуры и архитектуры. Разработайте, как описано в разделе Основы архитектуры программного обеспечения: что, как и Почему.

1. Развертывание

* Развертывание является частью реализации архитектуры — см. схему выше.

• Развертывание включает в себя следующее:

  1. Настройка среды
  2. Создание сборки из базы кода
  3. Установка сборки
  4. Настройка конфигураций для целевой среды

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

  * По мере роста сложности и размера программного обеспечения развертывание само по себе становится сложным и очень важным. Ошибки вероятны в процедуре развертывания вручную. Вот почему сегодня все эти четыре аспекта, как правило, полностью или частично автоматизированы (CICD и Infra-as-Code).

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

  3. Операции

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

 
 * Emails are not going out. Someone needs to troubleshoot and isolate the problem from different possibilities: (a) the external email service is down, (b) a logical error in the program (bug) resulting in an error, (c) wrong configuration, etc., and so on.

   
 * First, "Email not going out" needs to be identified, so **monitoring** is required, and then the **ability to troubleshoot** via logs, tracing in the database, etc. is required.

 

• Хорошее понимание проблем операционной деятельности позволит разрабатывать решения для упрощения эксплуатации.

  4. Бизнес-факторы

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

 
 * We need to build a SaaS-based diagramming tool.

   
 * In the beginning, it will be free. Later paid plans will be introduced with feature restrictions on free usage.

   
 * Feature restrictions for users based on their subscription is a fundamental implementation. It will be good if it is designed and implemented from start instead of doing it when the Business wants to introduce paid plans.

   

• Одним из этапов Процесса архитектуры является определение архитектурных характеристик (AC)/нефункциональных требований. Некоторые из этих AC являются производными от бизнес-факторов, таких как требования соответствия, требования масштабирования и т. д.

#### Связь с кодовой базой * По мере того, как внимание перемещается на другие области, связь с кодовой базой может ухудшиться. Но человек в роли архитектора должен по крайней мере быть знаком с кодовой базой и чувствовать себя комфортно. В противном случае цикл обратной связи разорвется.

 

![Engineering broken feedback loop](https://cdn.hackernoon.com/images/f8ChYF2U4MRmYNmy61YoItMITZl2-vid3q8r.png)

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

 

![Association with Codebase in an Architect Role](https://cdn.hackernoon.com/images/f8ChYF2U4MRmYNmy61YoItMITZl2-bxc3qvy.png)

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

Решение проблем в группе

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

* Человеку в роли архитектора может потребоваться взаимодействовать с одним или несколькими из следующих заинтересованных сторон:

* Давайте рассмотрим каждый из них, чтобы понять природу взаимодействия:

* Внешние поставщики

* В настоящее время широко распространена интеграция с внешними поставщиками услуг.

• Каждая интеграция сопряжена с общими проблемами, такими как контракты API, безопасность, обработка ошибок и т. д. Роль архитектора, возможно, придется принимать участие в этих обсуждениях.

  * Клиенты

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

• Операции

* Важно понимать проблемы операционной деятельности, чтобы можно было внести улучшения.

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

  * Новая функция требует загрузки файла.

  * Это потенциальная проблема безопасности с точки зрения Операций, поскольку она может принести что-то вредоносное в Среду.

  * В таких случаях целесообразно сделать Операции частью дизайна.

  * Команда инженеров

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

• Инженерный менеджмент

* Участвовать в планировании и расстановке приоритетов.

• Управление продуктами

* Технические данные для дорожной карты и определения приоритетов.

• Понимание требований и бизнес-факторов.

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

1. Умение слушать и получать отзывы

* На высоком уровне главная цель роли архитектора – преобразовать требования или отзывы в проекты, которые можно реализовать.

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

  2. Четко излагайте/формулируйте взгляды

* Ключ в том, чтобы иметь возможность донести свое мнение до различных типов заинтересованных сторон, например, передача проекта инженеру отличается от объяснения требований безопасности заказчику — первое может потребовать подробного рассмотрения, а второе может потребовать просто предоставления сводки. /достаточно подробностей. Это изменение стиля необходимо, чтобы быть эффективным.

• Здесь может пригодиться использование диаграмм и ведение качественной документации.

  3. Уравновешивание противоречивых потребностей — долгосрочные и краткосрочные

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

• В этом случае у роли архитектора есть несколько вариантов:

  1. Представьте плюсы и минусы и убедите руководство выделить больше времени, чтобы сделать это "правильным образом".

     2. Найдите какой-нибудь способ достичь обеих целей — инженерной правильности и сроков.

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

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

В конце...

• ДОЛЖЕН ли каждый иметь эти способности, чтобы преуспеть в роли архитектора?

* Нет. Конкретные потребности будут меняться в каждом сценарии, поскольку многое также будет зависеть от сложности системы, команды и т. д.

• Какой во всем этом смысл, если это не требуется для выполнения роли архитектора?

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

Поделитесь своим мнением в комментариях.