1. Введение
Роль архитектора, гибкая архитектура

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

3. Что есть архитектура?
Существенные инженерные решения,
которые формируют систему, где
“существенность” определяется стоимостью
внесения изменений.

4. Пример
● Форма системы (клиент-сервер, вэб, мобильное
приложение, распределенная система и тд)
● Структура системы (компоненты, слои и тд)
● Выбор технологий
● Выбор фреймворков (каркасных решений)
● Выбор подхода и паттернов (к производительности,
масштабируемости и тд.)

5. Платформа для диалога
● Команды разработчиков (настоящих и
будущих)
● Специалистов по БД
● Безопасников
● Специалистов по развертыванию,
админов
● ...

6. Архитектура не популярна
● Грандиозное предварительное
проектирование всего. “Analysis paralysis.”
● “Эстафетное” проектирование. “
● ...это детали реализации”
Попуярность “гибкого” подхода.

7. Architect
Лат. “architectus” - главный строитель.

9. Архитектурные факторы
● Понимать цели системы
● Собирать, уточнять и сопоставлять с
реальностью требования и ограничения
● Преодолевать субъективность

10. Проектирование ПО
● Прийти к пониманию, как вы собираетесь
решить задачу
● Выбор технологии реализации
● Техническая стратегия
● Владение всей картиной системы
целиком

11. Технические риски
● Обнаружение и смягчение рисков
● Взятие на себя ответственности за риски
● “Будет ли архитектура реально
работать?”
● Тестирование идей как можно раньше

12. Развитие архитектуры
● Непрерывное техническое лидерство и
владение архитектурой на протяжении
всей разработки
● “Архитектура это не эстафета.”

13. Программирование
● Практическая вовлеченность в написание
кода
● Анализ кода
● Написание фундаментальных участков
● Чувствовать себя в одной лодке с
программистами
● Постоянное самосовершествование

14. Обеспечение качества
● Выбор и внедрение в команде
стандартов, практик, принципов, методик
● Соблюдение следования выбранному
● Контроль за целостностью всего
решения, соответствия архитектуре

15. Сотрудничество
Сотрудничай или облажайся!
● Привлекай экспертов, если это
необходимо
● Советуйся с командой, собирай обратную
связь

16. Широта взгляда
● Является ли выбранная технология лучшей?
● Какие есть другие варианты как спроектировать и
построить систему?
● Есть ли соответствующее типовое архитектурное
решение (паттерн)?
● Осознаем ли мы компромиссы решения?
● Можем ли мы доказать, что предложенная
архитектура будет работать?

17. Личные качества
● Лидерство
● Понятно излагать
● Убедительность
● Уверенность
● Умение работать в
команде
● Делегирования
● Консультирование
● Наставничество
● Организация
групповой работы
● Политика
● Ответственность
● Позитивность

18. Власть и контроль
● Руководство (guidance)
● Борьба за целостность
● “Сколько контроля необходимо?”

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

20. Elastic Leadership
1. Выживание (в хаосе): более
директивный стиль.
2. Обучение: консультирование и
наставничество
3. Самоорганизация: работа над балансом
группы.

21. Из программиста в архитекторы
Дано не каждому. :)

22. Нужна ли архитектура
при гибком подходе?
XP: Collective Ownership
Самоорганизующиеся команды - это
сложнее, чем кажется.

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

25. слишком много
● нечитаемо длинные документы
● слишком детальная проработка на разных уровнях
абстракции
● сотни нечитаемых диаграм
● все решения даже по кодированию уже приняты
● “analysis paralysis” и затык с обсуждением мелочей
● наступил дедлайн, а вы все еще не приступили к
программированию

26. Столько сколько нужно
Критерии здравого смысла.

27. Литература
● Simon Brown “Software Architecture for
Developers”