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

Что меня сподвигло написать эту статью? Определенный опыт взаимодействия с разного уровня руководителями. Рассмотрим такую ситуацию. У нас есть вакансия, звучит она как Архитектор. И, вроде бы, понимание есть, что должен делать этот человек, но по факту оказывается, ждут “эникейщика”. 

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

И последнее, думаю надо представится. Меня зовут Владимир Воловиков. Работаю в ИТ сфере я уже почти 20-ть лет. В должности Системного архитектора и Программного архитектора, в общей сложности, более пяти лет. Имею четыре международных сертификата. Текущее место моей работы Системный архитектор, Банк ВТБ. 

Три года в одном репозитории

Моя должность Архитектор веб-решений. Старт нового проекта. По сути новый проект - реинкарнация старого. Новый дизайн. Немного новых функций. И что в нем делать архитектору?  Пока не понятно. Давайте заглянем внутрь! 

“Фронт” - это JavaScript-фреймворк Vue. Элементная база - некий распространенный фреймворк. В целом выглядит вполне современно. А что насчет данных? Как делаются запросы? Как данными манипулируют? Vuex? - Отлично! А на модули разбили? Да. Замечательно. А есть документация? Нет. А может быть комментарии к коду?  Тоже нет! А почему у нас страница с расписание движения транспортных средств формируется почти 20 секунд? 20-секунд, Карл!  Нагрузка смешная. Один запрос в секунду, ни пять, ни десять, а один. Один запрос в секунду на сервер и 20 секунд ответа! 

“Бэк” - это PHP и Laravel. Всё предпоследних версий. Отличный фреймворк. Современный PHP. Но почему так плохо и долго работает?  А как это работает? Есть описание API? Нет! Может быть есть описание структуры базы данных или диаграмма классов? Нет. Ну хотя бы описание какое-то бизнес процессов, какие-то бизнес правила, почему так или иначе делалось? Тоже нет!

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

1. Количество “ендпоинтов”, которые использует наше приложение и то, что есть по факту - это две разные вещи. “Фронт” вызывает порядка десяти разных “ендпоинтов”, а в коде их больше пятидесяти 

2. Программный код “сервера” содержит две категории классов: Контроллеры и Модели. Содержимое методов контроллера это десятки, а порой и сотни строк кода. Модели, по большей части, просто набор методов, внутри которых происходит вызов хранимых процедур базы данных

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

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

1. “Бекенд” содержит избыточное количество “ендпоинтов”, потому что он один для нескольких проектов, а сделано это было так, потому что:одни и теже модели (классы с методами вызывающие процедуры БД) используются в разных проектах. И как использовать их в разных проектах, при этом, иметь возможность их редактировать в одном месте, разработчики не знали

2. “Бекенд” содержит только две категории классов, потому что такой путь предлагает “фреймворк” из коробки. Как зарегистрировать другие классы и что в них поместить, в соответствии с какими критериями, программисты не знали.  Со временем программисты менялись и делали также как и было сделано до них. В итоге -  три года в одном репозитории, со всеми вытекающими последствиями. 

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

• Наведем порядок в коде. Опишем правила, по которым мы будем код разносить по разным частям. Введем такие понятия как: HelpersLayer, ServiceLayer, ControllerLayer. Создадим документ, в котором дадим определением этим слоям. Сформируем несколько примеров наглядно демонстрирующих то, как должен выглядеть наш будущий программный код. Очень желательно этот документ завизировать у руководства.

• Введем понятия “Критерии приемки кода”. В отдельном документе опишем их. Настроим систему CI/CD так, чтобы сборка начиналась только после подтверждения ключевыми сотрудниками, а также, чтобы запускались тесты, в том числе и на соответствие критериям. Благо такие сервисы сейчас достаточно хорошо развиты

• Введем правила обязательного документирования кода Добавим автоматическую генерацию REST API (Swagger).

• Из всего списка полученных Моделей и Сервисов выделим те, что могут использоваться в других проектах. Полученный код вынесем в отдельный Git репозиторий и подключим его к основному репозиторию посредством submodule

Взглянем еще раз на то, что мы сделали. Если простыми словами описать проделанную работу, то, просто, навели порядок. Таким образом, удалось решить две из трех основных проблем, выявленных в начале нашей работы. Но что делать с процедурой, которая выполняется 20 секунд? Ответа все еще нет. И сейчас самое время вплотную подойти к этой задаче.

Было двадцать, стало - две

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

• Получить полный список всех Воздушных судов

• По каждому из Воздушных Судов получить

  • Получить список Бортов

  • Получить список Рейсов 

  • Получить список Резервов, если это доступно Пользователю

  • Получить список Технических операций, если это также доступно Пользователю

• Получить дополнительную информацию об Аэропортах

• Обработать все записи.Перевести все время из UTC

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

А что, если мы часть запросов будем исполнять параллельно? Получить список Бортов, получить список рейсов, все это не блокирующий действия. Давайте, попробуем. Итог - 2 секунды. 

Было двадцать, стало - две. Прогресс очень существенный. Но совершенству нет границ. А давайте, попробуем добавить кэширование? В самом деле, если входные параметры одинаковые, то зачем запускать заново всю процедуру расчета?

Подведем итоги

Кто такой Программный архитектор?

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

Чем отличается Программный архитектор от Технического лидера команды (TeamLead)?

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

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

Должен ли уметь программировать Программный архитектор?

Скорее да, чем нет. Если эта роль, и ее совмещает Технический лидер команды, то да. В случае, если этот человек выделенный, например, в случае, если команд уже много, то времени на кодирование уже у этого человека не останется. В этом случае, только функции проверки и скорее всего функции наставничества.  

Какими компетенциями должен обладать Программный архитектор?

Как разработчику баз данных, ему нужно разбираться в 

1. работе различных баз данных, знать их особенности, плюсы, минусы

2. естественно, уметь составлять запросы, оптимизировать их и возможно, уметь писать исполняемые процедуры и триггеры 

Как бэкенд разработчику, ему надо

1. владеть одним, двумя, а лучше тремя разным языкам разработки, возможно с различным уровнем владения

2. понимать в целом, сильные и слабые их стороны

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

Как разработчику фронтенда, пригодятся знания

1. Javascript. Тут без него никак

2. Один, два фреймворка. 

3. несколько паттернов организаций работы с данными

Как архитектору, аналитику

1. уметь внятно и точно выразить свои мысли

2. переложить их на бумагу

3. владеть одной, двумя UML нотациями, например Диаграмма классов (Class Diagram) и Диаграмма деятельности Activity Diagram. Как-то же вам нужно будет общаться коллегами, с руководством. Не покажешь же им программный код верно? 

Как Технический лидер команды

1. Понимать жизненный цикл разработки программного обеспечения

2. Какие роли есть, кто что делает, в какой последовательности

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

4. Опыт работы с Git репозиторием, его настройки, решение конфликтов и т.д.

Как Девопс инженер

1. Опыт настройки CI/CD

Как менеджеру

1. Коммуникационные навыки

А еще есть профстандарт. Официальный документ. Смотреть тут

Сколько лет должно быть практики, чтобы быть Программным архитектором?

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

Стоит ли расти до Программного Архитектора? Стоит ли так строить карьеру?

Если вами движет финансовый интерес, и вы считаете что это ступень, это однозначно повышение финансового состояние, то мой ответ - нет. Не стоит. Действительно, хороший, глубокий разработчик, может получать больше. Архитектор, это практически всегда рост вширь. Это масса “софт” скилов, которые нужно будет развить, причем как это делать, совсем не очевидно. Нельзя открыть книжку или закончить курсы, и вот вы уже прекрасно ладите с людьми, а начальство вас боготворит. У вас просто может не быть таких человеческих характеристик.

Заключение

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

За помощь в подготовке данной статьи автор благодарит Балахчи Анну Георгиевну, Иркутский Государственный Университет, Факультет Бизнес-коммуникаций и информатики, зав.кафедры, кандидат физико-математических наук