Теория проекта за 15 минут.

Понимание системы живёт в головах — и уходит вместе с людьми. AskSerega помогает материализовать "Теорию Системы" и передать её команде.

К фреймворкам
▸ Почему это важно

Понимание системы должно жить в проекте, а не в головах людей.

Для бизнеса

Потеря знаний — риск

Экспертиза не уходит вместе с людьми.

  • •Ушёл человек — ушло понимание системы
  • •Онбординг месяцами
  • •Команда зависит от «того самого Серёги»
→ Воспроизводимая экспертиза и быстрее найм
Для разработчика

Понимать проще, чем бороться

Хорошие решения начинаются с понимания.

  • •Неясно, что делает сервис
  • •Legacy страшно менять
  • •Всё связано со всем
→ Roadmap, фреймворки и артефакты для решений
Для инженерной культуры

Понимание — часть разработки

Не только код, а передача теории.

  • •Знание только в головах
  • •Docs без «почему»
  • •Теория не растёт вместе с кодом
→ Общий язык и Theory of the System в процессе
Выбери свою боль↓
▸ Начните с вашей проблемы
UNDRSYS-001
Не понимаем, что делает этот сервис
→ Понять ответственность сервиса, его границы и место в системе
UNDRSYS-002
Каждый разработчик объясняет систему по-разному
→ Сформировать общее инженерное понимание системы
UNDRSYS-003
Слишком сложно понять, как всё работает
→ Построить целостную карту системы
UNDRSYS-004
Непонятно, как течёт информация
→ Понять жизненный цикл данных и событий
UNDRSYS-005
Непонятно, где начинается и заканчивается ответственность сервиса
→ Определить границы системы и ответственности
UNDRSYS-006
Чтобы понять систему — нужно звать «того самого человека»
→ Сделать инженерное знание воспроизводимым
BOUND-001
Всё связано со всем
→ Уменьшить связность системы и понять реальные зависимости
BOUND-002
Не знаем, где разделять систему
→ Найти естественные границы системы и ответственности
BOUND-003
Хотим выделить сервис из монолита
→ Безопасно выделить сервис и снизить связанность
BOUND-004
Непонятно, что должно быть отдельным сервисом
→ Определить правильные границы сервисов
BOUND-005
Сервисы слишком сильно зависят друг от друга
→ Снизить связанность между сервисами
BOUND-006
Архитектура перестала масштабироваться
→ Найти узкие места архитектуры и подготовить систему к развитию
KNOW-001
Новый разработчик долго погружается в проект
→ Сделать устройство системы понятным для нового разработчика
KNOW-002
Никто не помнит, почему приняли это решение
→ Сохранить причины и контекст архитектурных решений
KNOW-003
Знания живут в головах людей
→ Материализовать инженерное понимание системы
KNOW-004
Ушёл разработчик — потеряли контекст
→ Сохранить контекст системы независимо от конкретных людей
KNOW-005
Архитектурные решения невозможно восстановить
→ Сделать архитектурную эволюцию системы прозрачной
KNOW-006
Документация не объясняет «почему»
→ Документировать не только структуру системы, но и причины решений
COMPLEX-001
Боимся менять код — непонятно что сломается
→ Сделать последствия изменений предсказуемыми
COMPLEX-002
Любое изменение тянет за собой ещё десять
→ Найти и уменьшить скрытую связанность системы
COMPLEX-003
Каждое изменение ломает что-то неожиданное
→ Выявить скрытые зависимости и побочные эффекты
COMPLEX-004
Система слишком связана
→ Снизить связанность и усилить границы системы
COMPLEX-005
Код стал слишком сложным для изменений
→ Упростить структуру системы и локализовать сложность
COMPLEX-006
Legacy страшно трогать
→ Безопасно исследовать и постепенно изменять legacy-систему