Роли команды в разработке программного обеспечения

CCA Эпизод 2 - Роли в разработке программного обеспечения - Атака клонов

Архитектурные роли

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

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

Архитектор решений
Облачный архитектор
Системный архитектор
Архитектор предприятия
Архитектор программного обеспечения
Сервисный архитектор
Архитектор данных
Архитектор кода

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

1. Системный архитектор

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

Разница в архитектуре системы и программного обеспечения?
Архитектура составных компонентов: Эпизод 1 - Архитектура программного обеспечения - Призрачная угроза в сторонуdatascience.com

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

Divide et impera - Гай Юлий Цезарь

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

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

2. Архитектор программного обеспечения

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

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

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

3. Разработчик

Разработчик отвечает за две вещи и также должен в совершенстве владеть как дизайном, так и реализацией.

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

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

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

4. Программист

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

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

Состав команды

Квалифицированные члены команды всегда должны выполнять следующие роли, независимо от размера проекта:

Архитектор программного обеспечения
Разработчик

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

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

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

Заключение

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

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