Быть или не быть?

Очень часто веб-разработчик получая новое задание или заказ становиться перед выбором... Опишу ситуацию -- заказ простой, приложение требуется простое и заказчик утверждает, что изысков не нужно, что это одноразовая работа.

А выбор таков -- Использовать уже готовые решения с минимальными доработками или выполнить задание непосредственно и с нуля (решение на базе фреймверка (без собственных наработок), я назову именно "с нуля").


Конечно, ситуация упрощается, в случае если ваши наработки не подлежат распространению по какой-то причине.

Представим, что мы работаем на конкретной студии, у нас уже есть написанный нами движек на котором студия собирает сайты.

Поступил заказ, на простой сайт, т.е. функционал минимален, но есть и уникальный функционал, например -- зарегистрированный пользователь (работник компании заказчика) заходит и отвечает на ряд вопросов.

И вот, задание получено и нужно принять решение -- проект будет самостоятельным? Т.е. будет написан на чистом от дополнений любимом (предпочитаемом) фреймверке или же расширить набор функционала текущей Системы Управления Контентом, которая уже отлажена в бою и имеет в себе много удобных возможностей и решений.

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

Другая сторона медали написания с нуля -- это возможности.
Если Вы пишете проект с нуля, то как я уже сказал выше, Вы перетащите в проект часть движка -- отдельные расширения фреймверка, помощники для обработки данных etc. И кто знает, взглянув на весь этот набор дополнительного кода к проекту "с нуля", Вам придет в голову идея нового ядра для движка, дополнительного  модуля,возможно еще чего-т.

Согласитесь, выбор не просто.

Первая мысль -- гвозди... экскаватор. Но потом понимаешь, что уже настолько влился в написанную тобою систему, что просто не можешь представить себе -- КАК я буду снова писать на столь ограниченном, хоть и любимом, фреймверке? Даже попытавшись, можешь начать периодически делать ошибки типа "этой фичи здесь же нет, это в двигле...".

Конечно, вполне не плохо если проект действительно одноразовый и у Вас есть желание, возможно, изучить что-то новое, например, новый фреймверк. Так сказать обучение в бою.

---

Суть проблемы я описал, но решать Что выбрать? уже не мне, а Вам. Главное, это --

Нельзя путать привычку и консерватизм отлаженных решений с застоем развития.

Но если Вы решили, что Вам нужна CMS для всех проектов, независимо от типов поставленных задач, что же, тогда Вам придется изрядно поработать  (: .

Если обобщенно и не вдаваться в подробности (всему свое время), то такая Система Управления Контентом, должна быть максимально полностью модульной. Чтобы любой модуль был взаимозаменяем. Это накладывает на плечи разработчика большие требования к качеству кода, к его планированию.
Но суть всегда одна и та же при таких требованиях:

Система должна ничего не уметь делать кроме:

1. Загружать и запускать модули, хотя при этом нужно предусмотреть быструю проверку доступа к модулю, но это уже отдельная песня.
2. Предоставлять API для стандартных базовых классов (Кеш, Конфиги, Валидяция, etc.).
3. Иметь возможности расширять ядро не вмешиваясь в его код.

Все остальное должны взять на себя модули и плагины.

На этом пока все. Новая запись будет посвящена многоязычности сайта.