Структура, высеченная в камне

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

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

Сначала я вижу общую картину — модули системы, названия которых указывают на их функциональную роль или служат заголовком соответствующего поддомена. На уровне модулей я вижу пакеты (или пространства имен), названия которых дают мне четкое представление о их содержимом и позволяют получить базовое представление о внутреннем устройстве модуля. Далее я вижу отдельно взятые компоненты, классы, записи и т.п. Их имена также должны являться отражением содержания и/или намерения. И так вплоть до названий переменных. Всё это должно задавать невидимый вектор, интуитивно направляющий исследователя вашего кода к тому, что он ищет или хочет понять. Всё должно работать, как содержание книги: если мне нужны детали, я перейду в нужный подраздел, но одного содержания мне должно быть достаточно, чтобы понять, о чем книга или глава.

Не меньшую роль в повествовании играет граф зависимостей. Он ярко иллюстрирует все недочеты существующей структуры. Постройте граф зависимостей для своих модулей, пакетов или компонентов; проследите все взаимосвязи и оцените, насколько они логичны и корректны. Здесь также желательно спускаться сверху вниз, углубляясь в контекст по мере необходимости.

Что задаёт структуру проекта и что она отражает?

При изменении любого аспекта из этого списка должна меняться и структура проекта. Настолько масштабно, насколько было исходное воздействие. Если вы этого регулярно не делаете, вы нарушаете конструкцию своего сооружения. Можете воспринимать это так, как если бы из основания вашей постройки вынули несколько кирпичей. Сколько еще нужно вынуть кирпичей, чтобы всё начало рушиться?

Точно так же, как мы осуществляем рефакторинг кода, мы должны делать и рефакторинг структуры — реструктуризацию. В противном случае внешняя оболочка и содержимое очень быстро разъедутся, и развитие проекта будет усложняться пропорционально этому разрыву. В какой-то момент уровень входа разработчиков в проект станет слишком высоким, появятся "незаменимые" сотрудники, на которых держится всё. Это путь в один конец, и он достаточно печальный.

Структура проекта не высечена в камне, это такой же код, который должен подвергаться рефакторингу!

Кстати, залогом успеха в этом деле является унификация, стандартизация и тоталитарный контроль. Все эти вещи очень хорошо поддаются автоматизации и тестированию.

P.s. Если вам интересна данная тематика, присоединяйтесь к моей новостной ленте в Telegram или здесь. Буду рад поделиться опытом. ;-)