Duration 10

Определение архитектуры из Википедии:

Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы. Архитектура включает:

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

К вопросам архитектуры так же относятся вопросы технологии разработки и функциональные роли внутри команды. Agile – это тоже часть архитектуры.

Не будут рассматриваться вопросы Enterpise архитектуры (архитектуры предприятия).

Стримы для «играющих» архитекторов, которые работают над личным проектом и планируют его расширение, или участвуют в проектах с проблемами развития.

1. Уровни архитектуры a. Уровень предприятия b. Уровень системы (приложения) c. Уровень кода
2. Основные архитектуры приложений a. Микроядерная b. Плагинная c. Многоуровневая и многослойная d. Сервисная/Микросервисная e. Pipes and filters f. Client/Server g. Peer-to-Peer h. Publisher/Subscriber (реактивные архитектуры) i. Asynchronous Data Replication (отличается от pub/sub тем, что предназначена для синхронизации источников данных) j. Distribution Tree (publisher -> distributor -> consumer) k. Integration Hub (отличается от Data Replication тем, что синхронизация данных идет между системами, а не репликами БД) l. Tuple Space
3. Модель C4
4. Функциональные/нефункциональные требования a. Сбор b. Анализ
5. Качественная оценка архитектуры
6. Монолитность a. Структурная монолитность b. Логическая монолитность c. Архитектурная монолитность
7. Реактивная архитектура
8. Эволюционные архитектуры a. Фитнес функция b. Движение короткими шагами
9. Domain driven design
10. Разбор готовых архитектур

• Требования и повышение требований к продукту
• Растущие темпы разработки;
• Увеличивающаяся сложность процесса разработки;
• Необходимость интеграции всего со всем (готовность к интеграции).

ВАЖНО! Плохой код – не должен быть нормой, архитектура лишь помогает избавиться от плохого кода и ограничить его негативное влияние, а не жить с ним! Хорошая архитектура не компенсирует недостатки «плохих» разработчиков!

Основные проблемы кодовой базы связаны с постепенным загниванием проекта, накоплением технического долга, скатыванием к Big ball of Mud (программная система с нераспознаваемой архитектурой).

Нет точного места, когда код вдруг стал плохим. Постепенные изменения и невозможность отслеживать влияние изменений приводит к ситуации «А кто это сделал?»

Архитектура помогает:

• управлять монолитностью на всех уровнях;
• локализовать и изолировать проблемные места (эффективный root cause analysis)
• блокирует «эффект домино»
• управлять скоростью разработки
• наращивать команду
• прогнозировать развитие системы
• принципы архитектуры помогают принимать решения

Проблема Титаника: можно обладать отличной архитектурой, но все равно пойти на дно из-за внешних изменений.

Обычно о проблемах архитектуры вспоминают слишком поздно. В большинстве проектов по которым я делал аудит были одни и те же проблемы:

1. полный игнор вопросов архитектуры (обычно вспоминают про архитектуру как про палочку-выручалочку когда уже «все плохо»);
2. неформализованные требования и ограничения;
3. отсутствие метрик качества и контроля;
4. приоритет наращивания функциональности (по сути увеличение прибыли, больше возможностей – больше продаж);
5. широкая вариативность повторного использования компонент, переусложненные компоненты с частичным использованием функциональности (одна и та же форма имеет несколько сценариев поведения, определяемых объектами-конфигураторами);
6. недостаток механизмов управления командой (нет разделения ответственности, «мы вам платим, вы нам делаете код»);
7. большое количество «ручного» труда, отсутствие сценариев автоматизации (СI/CD, DevOps);
8. несколько источников «правды» - кто-то пишет в почту, кто-то в мессенджер, кто-то что-то сказал на планерке, вопросы решаются на бегу;
9. отсутствие культуры и технологии разработки (команда преимущественно использует структурный подход к разработке, плохо понимает ООП, не понимает принципы изоляции и публичные интерфейсы, рефакторинг сводится к переименованию методов, а не к «прояснению» логики);
10. не фиксируется технический долг и он обычно уже большой;
11. разработчики плохо представляют что такое архитектура, не умеют мыслить в отрыве от когда, не понимают абстракций, имеют узкую квалификацию (слабое знание инженерных дисциплин);
12. Отсутствие тестирования, рефакторинга и прочих техник;
13. Проблемы при генерации и проверке гипотез (первое решение принимается как правильное).

Порядок улучшения:

• уменьшение технического долга до приемлемого:
  • актуализация «внешних» ресурсов (библиотеки, фреймворки, инфраструктура)
  • первоначальный рефакторинг очистка мусора (ненужные комментарии, заброшенные ветки, актуализация TODO и прочие вещи, чтобы максимально прибраться в проекте);
  • фиксация изменений и требований к проекту;
• определение технологии разработки:
  • определение зон ответственности (желательно выделение направлений разработки);
  • выделение команд (2-3 человека в команде);
  • определение способа взаимодействия внутри команды (SCRUM, KANBAN и прочее определяется здесь);
  • рефакторинг, тестирование и культура разработки;
• специфицирование продукта
  • явное выделение требований и составление спецификаций (главное учет!)
  • определение границ
  • определение вектора развития (нельзя сделать все и сразу, нужно определять цели, а не плыть по течению)
• документирование архитектуры (не обязательно подробно)
• определить вид архитектуры
• определить основные принципы и ответственность компонентов архитектуры
• изоляция и определение промежуточных состояний
• определение конечного прототипа архитектуры
• Моделирование (модель отражает упрощенное представление реальной бизнес задачи и служит для выстраивания аспектов системы)
• Сценарии использования готовой системы
• Валидация (проверка технических и логических моментов на корректность)
• выстраивание процессов
  • инциденты
  • проблемы
  • конфигурация
  • исследования (генерация и проверка гипотез)

Эмпирическое наблюдение: время на «оздоровление» проекта пропорционально времени «загнивания».

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

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

• «ответственная безответственность» - все «топят» за agile чтобы не писать документацию, не делать тщательного анализа, а сразу писать код. При этом нет распределения ролей и обязанностей, непонятно кто за что отвечает и отвечает ли вообще.
• «я босс – ты дурак» - в такой ситуации, даже если определена технология разработки, принципы построения архитектуры и т.д., архитектор принимает «главенство» руководства, а не «архитектуры». В итоге принципы не соблюдаются, проект загнивает.
• «лебедь, рак и щука» - члены команды не могут прийти к общему знаменателю и расставить приоритеты;
• ошибки реализации (недостаточный контроль со стороны архитектора);
• недостаток компетенции.

Обычный процесс это постепенная детализация требований к проекту:

• спецификация – архитектура – логика – структура – код

Для определения архитектуры проекта необходимо выполнить обратный процесс:

• определить модульность на уровне структуры кода (файлы/каталоги)
• выделить модульность на уровне логики (композиция структуры)
• обезличить логику, выделив только основные модули и компоненты

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

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

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