Рассуждения о задачах разработчика

В сложных проектах, одной из ключевых долгосрочных целей становится выявление трёх множеств задач:

1. Актуальные задачи (#1)
2. Актуальные задачи, которые стоит решить (#2)
3. Актуальные задачи, от которых стоит отказаться (#3)

Выявление происходит в результате трёх процессов:

1. Формирования множества #1, в результате всё большего проникновения в суть проблемы и отбора задач
2. Формирования множества #2 на базе множества #1, в результате выбора наиболее привлекательных задач
3. Формирование множества #3 из множества #2, путём отбрасывания задач, решение которых бесполезно или контрполезно.

Например, мы ставим задачу увеличения продаж.

Далее выявляются 2 варианта решения:

• повышение цены — упор на элитность
• понижение цены — упор на доступность

Эти варианты являются самостоятельными задачами (X и Y).

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

Решая задачу X, мы делаем контрполезной задачу Y

Проект создания удобного фреймворка и CMS — сложный проект.

Множество #1 весьма велико: конфигурации, роутинг, парсинг, безопасность, валидация, система пользователей, механизмы расширений, кеширование и многое другое. Рассмотрим задачу «Поддержка множества сайтов одной копией CMS». Сокращённо — мультисайтовая CMS.

Эта задача является актуальной — она даёт определённые преимущества.

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

Создатели Bitrix выбрали усложнение из-за своей системы продаж: каждая копия CMS оплачивается отдельно. Действительно, конечные цены, различающиеся в разы, — немалый аргумент в пользу выбора мультисайтовой CMS. Но что если вы создаёте свободное ПО или ведёте иную маркетологическую политику?

Не окажется ли, что для вашего проекта убытки от решения этой задачи перевесят выгоду?

К какому множеству мы отнесём задачу «Поддержки множества сайтов (приложений) одной копией фреймворка»?

Сокращённо — мультисайтовый фреймворк.

Эта задача является актуальной — она даёт определённые преимущества.

Сокращение количества файлов. Общая точка конфигурации для всех наших сайтов на хостинге. Аргументы За весьма весомы.

Однако, и тут есть подводные камни. Непопулярная деталь: нам гораздо сильнее нужна общая точка конфигурации между приложением и CMS. А этот принцип противоречит обозначенному.

Другие контраргументы:

• при повреждении директории фреймворка «полетят» все сайты, а не один
• вопросы конфигурирования резко усложняются
• пути становятся неопределёнными (в отличие от их определённости в схеме: один сайт / один фреймворк / общая корневая директория), работа с ними становится непрозрачной
• количество общих модулей будет быстро возрастать, приводя к значительным затруднениям в разработке и поддержке

Не окажется ли, что для вашего проекта выгоднее отказаться от концепции мультисайтового фреймворка?

Автор: Клешнин Иван