Почему твой код быстро стал нечитаемым. Знакомство с MVVM

Краткое содержание:

Вы начинали с одной кнопки и 50 строк кода. Через месяц — 3000 строк, хаос и страх что-либо править. В этой статье я расскажу, почему так происходит и как избежать этой ловушки.

От счастья к хаосу: история одного плагина

Начинается всё красиво. Ваш первый плагин для Revit — одна кнопка, 50 строк кода. Всё работает, вы довольны.

Проходит месяц, поступают новые требования:

• «Добавьте проверку параметров»
• «Сделайте экспорт в Excel»
• «И аналитику...»

Вы добавляете фичу за фичей. И вот наступает момент, когда вы открываете файл и видите 3000 строк кода.

Где здесь основная логика? Где работа с API? Где экспорт в Excel? Найти баг в таком коде — всё равно что искать иголку в стоге сена. А ещё страшно что-либо править — вдруг всё сломается?

Почему так происходит?

Представьте строительную площадку, где один человек должен:

• Общаться с заказчиком
• Считать нагрузки на конструкции
• Гнуть арматуру
• Заливать бетон
• Составлять смету

Что из этого выйдет? Хаос, ошибки в расчётах, сорванные сроки.

То же самое происходит в коде.

Один файл пытается быть всем сразу: пользовательским интерфейсом, калькулятором, интегратором с Revit API и генератором отчётов. Итог — те самые 3000 строк, в которых невозможно ориентироваться.

Решение: разделить код на специализированные сущности

Классический подход — паттерн MVVM (Model-View-ViewModel) в связке с сервисами. Разберём на аналогии со стройплощадкой:

🏗️ View — Заказчик. Формулирует потребность, но не знает о СНиПах и строительных нормах.

👷 ViewModel — Главный инженер проекта (ГИП). Получает параметры от заказчика, создаёт техническое задание, координирует бригады.

📋 Model — Техническое задание. Структурированные данные: размеры, нагрузки, материалы.

🔧 Service — Специализированные бригады. Каждая решает свою узкую задачу.

Как это работает на практике?

Ситуация: Заказчик (View) говорит: «Мне нужно перекрытие 10×12 метров с нагрузкой 500 кг/м²». (Пользователь ввел эти данные в окне программы)

Главный инженер проекта (ViewModel) действует по плану:

1. Преобразует слова в ТЗ — создаёт структурированные данные о плите перекрытия (SlabModel)
2. SlabModel — это класс, который хранит данные о плите: размеры, нагрузки, материалы.
3. Вызывает инженера-конструктора — передает ему SlabModel и просит рассчитать арматуру на основе данных из этой модели. Получает экземпляр класса SlabReinforcementData.
4. SlabReinforcementData — это класс, который хранит информацию о результатах расчета.
5. Отдаёт арматурщикам информацию о плите перекрытия и результатах расчета — они укладывают арматуру (RebarModellingService)
6. Передаёт бетонщикам информацию о плите перекрытия — они заливают плиту (FloorModellingService)
7. Передает сметчику информацию о плите перекрытия — подготовь ведомость материалов (ExcelExportService)

Ключевые принципы:

• ГИП никогда не видел стройплощадки — он работает с документами
• ГИП преобразовал слова заказчика в стандартизированный документ
• Каждая бригада работает только со своей частью ТЗ

Workflow кода, написанного по архитектуре MVVM

Разделение ответственности

Хороший код — как хорошая стройка: чем чётче разделены ответственности, тем проще масштабироваться и поддерживать проект.

Эпилог

Тот самый файл на 3000 строк всё ещё живёт в нашем проекте. И мы когда-нибудь обязательно до него доберёмся))

--

Понравилась статья? Был похожий опыт с «разрастающимся» кодом? Или остались вопросы? Делитесь в комментариях — обсудим!