Введение в архитектурные стримы

preview

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

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

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

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

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

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

Темы будущих стримов

Duration: 10

  • Уровни архитектуры
    • Уровень предприятия
    • Уровень системы (приложения)
    • Уровень кода

  • Основные архитектуры приложений

    • Микроядерная
    • Плагинная
    • Многоуровневая и многослойная
    • Сервисная/Микросервисная
    • Pipes and filters
    • Client/Server
    • Peer-to-Peer
    • Publisher/Subscriber (реактивные архитектуры)
    • Asynchronous Data Replication (отличается от pub/sub тем, что предназначена для синхронизации источников данных)
    • Distribution Tree (publisher -> distributor -> consumer)
    • Integration Hub (отличается от Data Replication тем, что синхронизация данных идет между системами, а не репликами БД)

    • Tuple Space

  • Модель C4

  • Функциональные/нефункциональные требования
    • Сбор
    • Анализ
  • Качественная оценка архитектуры
  • Монолитность
    • Структурная монолитность
    • Логическая монолитность
    • Архитектурная монолитность
  • Реактивная архитектура
  • Эволюционные архитектуры Фитнес функция Движение короткими шагами
  • Domain driven design
  • Разбор готовых архитектур

Зачем все это надо

Duration: 10

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

Почему с хорошей архитектурой не страшен плохой код

Duration: 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 и прочее определяется здесь);
    • рефакторинг, тестирование и культура разработки;
  • специфицирование продукта
    • явное выделение требований и составление спецификаций (главное учет!)
    • определение границ
    • определение вектора развития (нельзя сделать все и сразу, нужно определять цели, а не плыть по течению)
  • документирование архитектуры (не обязательно подробно)
  • определить вид архитектуры
  • определить основные принципы и ответственность компонентов архитектуры
  • изоляция и определение промежуточных состояний
  • определение конечного прототипа архитектуры
  • Моделирование (модель отражает упрощенное представление реальной бизнес задачи и служит для выстраивания аспектов системы)
  • Сценарии использования готовой системы
  • Валидация (проверка технических и логических моментов на корректность)
  • выстраивание процессов
    • инциденты
    • проблемы
    • конфигурация
    • исследования (генерация и проверка гипотез)

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

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

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

Почему бывает "хотели как лучше, а получилось как всегда"

Duration: 10

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

Как понять "какая архитектура у проекта"

Duration: 10

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

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

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

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

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