Что нужно знать при разработке своих CMF и CMS. Опыт длиною в 2 года

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

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

Для каждой компании с web-production естественно формирование набора компонентов, которые часто используются. Иногда это буквально набор компонентов, иногда образцовые проекты (которые в последствии берутся за основу для разработки нового), иногда это эволюционирует в CMS ^[1] или CMF ^[2]. Последнее является спасением для компаний, если разработка на популярных CMS по каким-то причинам не подходит. Для разработчика — это возможность сделать что-то крутое, чем можно гордиться, а также увеличить свою зарплату (при условии адекватности работодателя).

Основа

Итак, вы решили создать свой инструмент. Нужно решить 3 основополагающих вопроса:

1. Выбор цели. Зачем нужен этот инструмент, какие задачи он должен решать, в какой сфере будет использоваться, для кого предназначен.
2. Выбор базовых инструментов. Языки, технологии, архитектура — то, на основе чего будем создавать что-то своё.
3. Какие возможности есть, какие ресурсы понадобятся. Даже если это реализация небольшой идеи, должен быть план. Нужно понимать, как вы это будете делать, нужно ли кого-то привлекать, сколько времени вам может понадобиться хотя бы на альфа-версию или первый рабочий прототип.

Советы

Они помогут ответить на 3 вопроса выше.

1. Определите аргументы, почему нужно это делать, почему готовые решения не подходят. Если аргументы будут весомыми, это придаст вам уверенности. Если слабыми, это поможет избежать лишней траты времени.
2. У вас должны быть реальные задачи, которые действительно нужно решить. Обозначьте их вместе с тем, что могло бы измениться, если решить их. Убедитесь, что есть возможность проверять ваше творение сразу в бою.
3. Определите, что вы хотите получить от первой версии. Остальное можно просто записать списком. Не ставьте слишком больших целей для первого релиза. Для больших целей — большие сроки. Позвольте продукту увидеть свет как можно скорее. А уже потом дорабатывать, имея первые результаты и первую обратную связь.
4. Как основу выбирайте простой инструмент — язык, базовый фреймворк. С низкой точкой входа, чтобы проще было развивать сам инструмент и проще поддерживать конечные продукты. При этом ему необязательно быть очень популярным, достаточно быть простым. Ещё он должен развиваться. Например, вы выбрали PHP-фреймворк, убедитесь, что разработчики продолжают над ним работать, и готов релиз под последнюю версию PHP.
5. Выбирайте инструменты, которые уже хорошо знаете. А если хотите выбрать что-то новое, то сначала это изучите. Некоторые разработчики любят пробовать новое и сразу на серьезном проекте — может это и хорошо, но более непредсказуемо и рискованно в плане переделок из-за нехватки в начале знаний о том, как правильно. Работа с известным инструментом сэкономит время. Идеально, если вы в нем эксперт.
6. Уделите большое внимание архитектуре. Делайте её понятной, она должна помогать, а не мешать. Первоначально это зависит от фреймворка, если вы его выбрали как основу. А в последствии — только от вас.
7. Сразу подумайте о ведении документации. Определились с целью, планом — зафиксируйте. Придумали архитектуру — опишите. Готов первичный функционал — задокументируйте, что получилось. Это здорово помогает структурировать, выгрузить из головы уже реализованное, станет катализатором для новых идей, откроет глаза на ошибки.
8. Если предполагается бэкенд для управления сайтом (обобщенно), сразу возьмите качественный платный шаблон для бэкенда. Его можно выбрать и купить на themeforest или других подобных ресурсах. При выборе подумайте, сможете ли вы его встроить под свои задачи, потому что бывает так — вроде крутой шаблон, а начинаешь использовать под себя, и получается ущербно. Вариант с шаблоном более бюджетный и быстрый. Если есть финансовая возможность, лучше привлечь UI и UX специалистов с опытом в подобных интерфейсах.
9. Будьте готовы к постоянной доработке инструмента. Топор нужно точить постоянно в перерывах между рубкой леса. Поэтому во главе проекта должен стоять человек, которому не свойственно надоедание работы над проектом в течение длительного времени.
10. Будьте готовы, что понадобится не только программировать. Нужно придумывать, рассказывать остальным, обучать и т.д.
11. Расскажите о своей идее руководителю и коллегам, заручитесь их поддержкой.
12. Задайтесь вопросами защиты кода, лицензирования и авторских прав. Не нужно сразу их решать, но нужно определить свою позицию.

Мой пример

Рассуждения ниже не претендуют на истину. Это пример хода мыслей, которые привели мои идеи к успеху.

Предпосылки. В компании накопилась приличная база кода и пачка сайтов с кочующим функционалом. Процесс разработки новых сайтов — мучительный поиск и копипаст из прошлых проектов. Оптимизация процесса поможет увеличить скорость разработки типовых проектов. Сейчас имеем 3 простых типовых проекта для сферы автобизнеса (но поэтому специфичных), на которых можно стартануть нашу платформу.

Почему не подходят готовые решения (популярные CMS). Они тяжеловесные, одновременно избыточные и недостаточные для наших задач.

Цель. Нужен инструмент для ускорения разработки корпоративных сайтов для бизнеса. Предназначен для разработчиков. Разработчик берёт в руки CMF, на выходе получает CMS для клиента под его задачи, таким образом наша цель — CMF для разработчика. Продавать CMF как продукт цели не ставим.

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

Архитектура. Составные части CMF нужно максимально обособить друг от друга, т.е. организовать некую модульность, поэтому как архитектура больше подойдёт HMVC.

Базовые инструменты. Выберу PHP5, CodeIgniter3, MySQL, Bootstrap3, jQuery, т.к. хорошо их знаю, они помогут мне решить задачи максимально быстро и просто, они имеют низкую точку входа для разработчиков. Будем сразу документировать, для начала подойдёт GoogleDocs. Для бэкенда отобрала 3 шаблона на базе Bootstrap, выберем из них вместе.

Ресурсы для первого релиза. Плановые затраты — 70-100 часов. Чтобы успеть в срок с учётом текущих задач, понадобится помощь одного PHP джуна или мидла.

С таким обоснованием уже можно идти к руководителю и коллегам.

Автор: lencom

Источник ^[3]