MOSP_ Architectural design

Раздел: Architectural design –

Denis

Цитата: “I liked that you described different aspects of your projects like how you interact with the customer, the experiment design, and how the system works. I was confused by slide 30. It is not clear how different component groups interact.”

1. Что именно «не так» с текущим оформлением Slide 30

1. Отсутствие явных связей (стрелок) между группами компонентов
   На слайде видно три «плавающие» прямоугольные области (dashed boxes) с надписями «Universal code for experiments», «Model training» (оранжевый фон) и «For Analyst». Параллельно справа расположена группа «Tests». Тем не менее из рисунка неясно:
   • Как данные из «Universal code for experiments» попадают в «Model training»
     Ментора смущает: мы видим, что первые три блока (Data Structures, Base Model, Data Preprocessor) вынесены в одну зону, а следующие три (Data, RubertModel, Experiment) – в другую, но никакой «линии» между ними нет. Создаётся впечатление, будто эти компоненты существуют отдельно, не обмениваются информацией.
   • Как «For Analyst» (нижняя группа) получает результат
     Сценарий «For Analyst» (который, судя по подписи, – это некий интерфейс или ячейка для аналитика) показан «отдельно» внизу, но не ясно, откуда именно он берёт модель, логи или метрики. Есть ли связь с «Model training»? Если да – где она?
   • Как группа «Tests» связана с остальными двумя «ядрами» (universal code и model training)
     Тесты (Sanity 1, Sanity 2, Reproducibility 1–3) лежат в от­дельной правой колонке, никак не привязаны к конкретным компонентам (например, к Base Model или RubertModel). Неясно, какие тесты покрывают какая подсистема: проверяют ли тесты только «Universal code», или они запускаются поверх «Model training», или одновременно над всеми компонентами?
   • Не очевидна иерархия и модель взаимодействия
     На слайде отсутствует поясняющая визуализация: «сначала выполняются базовые утилиты, затем запускается модель, потом аналитик получает результат, а тесты при этом могут обращаться ко всему стеку». В результате человек, впервые смотрящий на этот слайд, не понимает, где начинается «поток данных», где он заканчивается и на каком этапе что проверяется.
2. Неполное разграничение зон ответственности
   Пока мы «угруппировали» компоненты лишь цветом и расположением, но не дали «легенду», поясняющую, что именно входит в каждую группу. Например:
   • Что именно лежит в «Universal code for experiments» помимо названий классов? Это утилиты для подготовки любых моделей (ловушка: Base Model, Data Preprocessor и Data Structures могут быть не только «для экспериментов», но и для «продукционно­го» конвейера).
   • Разница между «Model training» и «For Analyst» названа «Model training» vs «For Analyst», но не объяснено, почему именно отдельный компонент «For Analyst» (может, это просто «обёртка» над Experiment?).
   • Не показано, какие именно зависимости есть у RubertModel от Base Model или Data Structures.
3. Отсутствие текстовой инструкции/антито пояснения
   У автора слайда есть буллет «The orange highlighted group of components differs in the content code depending on the model», но он никак не развёрнут. На диаграмме (уровень Level 2) нет поясняющего списка: «Вот последовательность, как вызываются классы, вот в чём логика переключения, вот на какие методы опирается каждый модуль». Поэтому кажется, что компоненты «просто лежат» рядом друг с другом.

Из-за этих пробелов у менторa сложилось впечатление, что «разные группы компонентов функционируют отдельно, и неясно, как данные или управление передаются между ними».

ИТОГО:

• Добавить стрелки (flow arrows) между «Universal code», «Model training», «For Analyst» и «Tests».
• Дать легенду/описание каждому «box», поясняющую «роль» (универсальный код, тренировка модели, аналитический интерфейс, тестирование).
• Пронумеровать шаги (Step 1–4), чтобы был понятен порядок выполнения и взаимодействия.
• Расширить текстовые буллеты слева, чтобы каждое упоминание качества (maintainability, reusability, testability) сразу ссылалось на конкретные компоненты/стрелки.
• Явно показать, к каким компонентам «прицеплены» тесты, чтобы стало очевидно, что никакая часть кода не остаётся «без присмотра».
• Добавить изменения в архитектуру с учетом появления бэкенда и фронтенда для интерфейса