Как меняется обучение?

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

Именно поэтому приходится постоянно обновлять программы. По 2-3 раза в год.

Ключевой вопрос: за что именно инженер способен отвечать?

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

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

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

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

Но сейчас добавляю сквозную практику на работающей системе: будем не только проектировать изменения, но и своими руками проводить их через код, проверять и наблюдать последствия.

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

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

А дальше начнем выделять части и менять взаимодействия.

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

• Разнесли данные по отдельным хранилищам. Теперь изменения, которые раньше выполнялись в одной транзакции, могут завершиться только частично.
• Заменили локальный вызов сетевым. Получили тайм-аут. Операция не выполнилась или мы просто не дождались ответа? Можно ли безопасно повторить запрос?
• Перевели обработку на события. Запрос приняли, но пользователь еще не видит результат. Это допустимая задержка, зависшая обработка или потерянное изменение? Как отличить одно от другого?

И вот здесь будем останавливаться и разбираться.

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

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

Transactional Outbox, Saga, идемпотентность, CQRS и остальные темы будут частью этого пути. С конкретной причиной применения и последствиями, которые можно исследовать.

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

• Запросы стали быстрее, но результат теперь появляется с задержкой?
• Компоненты можно выпускать независимо, но восстановление после сбоя стало сложнее?
• Убрали одно узкое место, но получили другое?

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

И после успешной проверки работа не заканчивается.

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

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

В этом смысле обновление интенсива продолжает разговор о профессиональном росте.

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

Мне хочется, чтобы и эту часть работы студенты тоже проходили.

Чтобы за словами "я понимаю эту архитектуру" стояло не только умение ее объяснить, но и конкретный опыт.