[Из песочницы] Что нужно знать при разработке своих CMF и CMS. Опыт длиною в 2 года
Мы не будет говорить про разработку ради фана, изучения новых технологий или дипломного проекта, если нет цели дать ему дальнейшее развитие. Мы поговорим про разработку инструментов для коммерческих проектов.
Для каждой компании с web-production естественно формирование набора компонентов, которые часто используются. Иногда это буквально набор компонентов, иногда образцовые проекты (которые в последствии берутся за основу для разработки нового), иногда это эволюционирует в CMS или CMF. Последнее является спасением для компаний, если разработка на популярных CMS по каким-то причинам не подходит. Для разработчика — это возможность сделать что-то крутое, чем можно гордиться, а также увеличить свою зарплату (при условии адекватности работодателя).
Основа
Итак, вы решили создать свой инструмент. Нужно решить 3 основополагающих вопроса:
- Выбор цели. Зачем нужен этот инструмент, какие задачи он должен решать, в какой сфере будет использоваться, для кого предназначен.
- Выбор базовых инструментов. Языки, технологии, архитектура — то, на основе чего будем создавать что-то своё.
- Какие возможности есть, какие ресурсы понадобятся. Даже если это реализация небольшой идеи, должен быть план. Нужно понимать, как вы это будете делать, нужно ли кого-то привлекать, сколько времени вам может понадобиться хотя бы на альфа-версию или первый рабочий прототип.
Советы
Они помогут ответить на 3 вопроса выше.
- Определите аргументы, почему нужно это делать, почему готовые решения не подходят. Если аргументы будут весомыми, это придаст вам уверенности. Если слабыми, это поможет избежать лишней траты времени.
- У вас должны быть реальные задачи, которые действительно нужно решить. Обозначьте их вместе с тем, что могло бы измениться, если решить их. Убедитесь, что есть возможность проверять ваше творение сразу в бою.
- Определите, что вы хотите получить от первой версии. Остальное можно просто записать списком. Не ставьте слишком больших целей для первого релиза. Для больших целей — большие сроки. Позвольте продукту увидеть свет как можно скорее. А уже потом дорабатывать, имея первые результаты и первую обратную связь.
- Как основу выбирайте простой инструмент — язык, базовый фреймворк. С низкой точкой входа, чтобы проще было развивать сам инструмент и проще поддерживать конечные продукты. При этом ему необязательно быть очень популярным, достаточно быть простым. Ещё он должен развиваться. Например, вы выбрали PHP-фреймворк, убедитесь, что разработчики продолжают над ним работать, и готов релиз под последнюю версию PHP.
- Выбирайте инструменты, которые уже хорошо знаете. А если хотите выбрать что-то новое, то сначала это изучите. Некоторые разработчики любят пробовать новое и сразу на серьезном проекте — может это и хорошо, но более непредсказуемо и рискованно в плане переделок из-за нехватки в начале знаний о том, как правильно. Работа с известным инструментом сэкономит время. Идеально, если вы в нем эксперт.
- Уделите большое внимание архитектуре. Делайте её понятной, она должна помогать, а не мешать. Первоначально это зависит от фреймворка, если вы его выбрали как основу. А в последствии — только от вас.
- Сразу подумайте о ведении документации. Определились с целью, планом — зафиксируйте. Придумали архитектуру — опишите. Готов первичный функционал — задокументируйте, что получилось. Это здорово помогает структурировать, выгрузить из головы уже реализованное, станет катализатором для новых идей, откроет глаза на ошибки.
- Если предполагается бэкенд для управления сайтом (обобщенно), сразу возьмите качественный платный шаблон для бэкенда. Его можно выбрать и купить на themeforest или других подобных ресурсах. При выборе подумайте, сможете ли вы его встроить под свои задачи, потому что бывает так — вроде крутой шаблон, а начинаешь использовать под себя, и получается ущербно. Вариант с шаблоном более бюджетный и быстрый. Если есть финансовая возможность, лучше привлечь UI и UX специалистов с опытом в подобных интерфейсах.
- Будьте готовы к постоянной доработке инструмента. Топор нужно точить постоянно в перерывах между рубкой леса. Поэтому во главе проекта должен стоять человек, которому не свойственно надоедание работы над проектом в течение длительного времени.
- Будьте готовы, что понадобится не только программировать. Нужно придумывать, рассказывать остальным, обучать и т.д.
- Расскажите о своей идее руководителю и коллегам, заручитесь их поддержкой.
- Задайтесь вопросами защиты кода, лицензирования и авторских прав. Не нужно сразу их решать, но нужно определить свою позицию.
Мой пример
Рассуждения ниже не претендуют на истину. Это пример хода мыслей, которые привели мои идеи к успеху.
Предпосылки. В компании накопилась приличная база кода и пачка сайтов с кочующим функционалом. Процесс разработки новых сайтов — мучительный поиск и копипаст из прошлых проектов. Оптимизация процесса поможет увеличить скорость разработки типовых проектов. Сейчас имеем 3 простых типовых проекта для сферы автобизнеса (но поэтому специфичных), на которых можно стартануть нашу платформу.
Почему не подходят готовые решения (популярные CMS). Они тяжеловесные, одновременно избыточные и недостаточные для наших задач.
Цель. Нужен инструмент для ускорения разработки корпоративных сайтов для бизнеса. Предназначен для разработчиков. Разработчик берёт в руки CMF, на выходе получает CMS для клиента под его задачи, таким образом наша цель — CMF для разработчика. Продавать CMF как продукт цели не ставим.
Первый релиз. Хочу увидеть через месяц инструмент для развертывания информационных сайтов, с заложенной архитектурой, базовым интерфейсом админ-панели на новом шаблоне (управление пользователями, управлением первыми модулями — инфостраницы, новости, отзывы, меню, заявки, услуги), базовую верстку для этих модулей во фронтенде. Это позволит в 2 раза быстрее делать сайты для автодилеров.
Архитектура. Составные части CMF нужно максимально обособить друг от друга, т.е. организовать некую модульность, поэтому как архитектура больше подойдёт HMVC.
Базовые инструменты. Выберу PHP5, CodeIgniter3, MySQL, Bootstrap3, jQuery, т.к. хорошо их знаю, они помогут мне решить задачи максимально быстро и просто, они имеют низкую точку входа для разработчиков. Будем сразу документировать, для начала подойдёт GoogleDocs. Для бэкенда отобрала 3 шаблона на базе Bootstrap, выберем из них вместе.
Ресурсы для первого релиза. Плановые затраты — 70–100 часов. Чтобы успеть в срок с учётом текущих задач, понадобится помощь одного PHP джуна или мидла.
С таким обоснованием уже можно идти к руководителю и коллегам.
Комментарии (12)
28 февраля 2017 в 20:37
0↑
↓
Определите аргументы, почему нужно это делать, почему готовые решения не подходят. Если аргументы будут весомыми, это придаст вам уверенности. Если слабыми, это поможет избежать лишней траты времени.
Почему не подходят готовые решения (популярные CMS). Они тяжеловесные, одновременно избыточные и недостаточные для наших задач.
Это даже не слабый ответ, это вообще не ответ на самый основной вопрос. Есть конкретнее?28 февраля 2017 в 22:09
0↑
↓
Обычный ответ: кастомизация под конкретные требования сравнима с написанием с нуля.28 февраля 2017 в 23:21
0↑
↓
Это должны быть очень «своеобразные» требования, чтобы не использовать CMF. Либо нехватка мощности/масштабируемости, но там вопрос между чем-то своим и CMS уже не стоит.На том же October CMS можно из админки руками наделать сколько угодно таблиц, контроллеров, видов… Если, конечно, не устраивает самый известный велосипед — MODX
28 февраля 2017 в 22:33
0↑
↓
Да. Коротко не получится, но постараюсь).Контекст моего примера — разработка сайтов для автодилеров. Как правило, они небольшой или средней сложности. Но у этого направления есть свои особенности — набор разделов, модулей (у всех есть модельный ряд, у части есть авто с пробегом), требований дистрибьютора к сайту автодилера. И при этом требования могут сильно отличаться, они просто разные у каждого бренда, модельный ряд по структуре контента тоже сильно разнится.
Чтобы сделать на поп.движках решение, удобное для клиента и удовлетворяющее требованиям бренда, нужно приложить сильно больше усилий. Мне довелось посмотреть, как мучается клиент с сайтами, например, на вордпресе, друпале и самописках, когда им сверху спускают требования, а их или не могут выполнить, либо это стоит клиенту дороже.
Или есть бренды, для которых дистрибьютор предлагает дилерскую платформу, в которой кроме пары страниц и своих контактов дилер поменять ничего не сможет, а ему нужно делать seo и продвигаться, т.к. он в Москве, и там конкуренция.
Таким образом, нужно что-то своё, быстрое, легковесное изначально, легко модифицируемое под бренд путём изменения функционала модулей, на базе чего разработчик может быстро развернуть, натянуть верстку, допрограммировать нужный функционал (он бывает очень непростым, конфигураторы, например).
Это если про контекст примера, с которого всё началось. Сейчас наша CMF подходит под множество отраслей.
28 февраля 2017 в 23:24
0↑
↓
Достаточно много лет назад делали примерно то же самое.
Сделали конструктор конфигураций, выбор, сравнение по характеристикам, сохранение собранной пользователем конфигурации и тд… В-принципе, этот модуль можно прикрутить вообще к абсолютно любой CMS, и разработки собственной не понадобилось1 марта 2017 в 01:09
0↑
↓
Спасибо за подробный ответ, но скорее всего вы просто не знаете существующие инструменты.В плане автодилеров хорошо знаю кейс, буквально недавно приводили успешно работающий сайт клиента под дизайн и верстку дистрибьютера. Абсолютно никаких проблем, CMS Modx. Вышло тоже быстро и легковесно. Конфигураторы любой сложности делаются легко на основе Vue.js.
Почему вам не подошел MODx и Vue? Вордпресс и друпал действительно была бы боль…
28 февраля 2017 в 20:52
0↑
↓
Вопрос: существуют CMS не на ПХП? :)28 февраля 2017 в 23:42 (комментарий был изменён)
0↑
↓
Да, существуют)) Часть написаны/пишутся на C# (asp.net), под IIS сервер. Есть системы на JAVA, там тоже есть ряд апп/веб серверов/фремворков, типа Tomcat, Jetty, Grizzly, Netty, GlassFish, JBoss. А так же варианты и по экзотичней: Ruby, python, perl и т.п.))
Каждый выбирает то, что лучше всего знает. Вот например, я как джавист, цмс творю на Java + Jetty + Postgresql.
В мире шарпа связка обычно Asp.net + IIS + MSSql. Ну, конечно больше всего классического PHP + apache (nginx-fpm) + Mysql.
Если интересны конкретные варианты, то можно поискать на cmsmagazine.ru, там хороший каталог цмс. Например через гугл каким нибудь запросом, типа: site: www.cmsmagazine.ru/catalogue/ «asp.net» вписав соответствующую технологию))
28 февраля 2017 в 22:34
0↑
↓
Если уже был взят Codeigniter, то создание CMF свелось к выбору подходящих готовых решений? Или была непосредственно разработка CMF?28 февраля 2017 в 22:40
0↑
↓
Непосредственно разработка CMF. С проработкой архитектуры, возможности масштабирования, отстройки от задач, которые чаще встают перед командой.
28 февраля 2017 в 23:35
+3↑
↓
Киллер-решение за 100 часов? Я бы глянул, что получилось на выходе. Если в помощь брать джуна, на обучение которого надо тратить время, то посмотреть стало бы еще интереснее. Не примите за наезд, просто пытаюсь понять, может я такой слоупок. На такую фундаментальную штуку, да чтобы еще и с тестами, и все везде хорошо и продуманно, и все фичи желаемые были, я бы часов 800–1000 закинул.1 марта 2017 в 00:05
–1↑
↓
В статье указано, что 100 часов — это «Ресурсы для первого релиза» в условиях совета «Не ставьте слишком больших целей для первого релиза.». В первом релизе было только необходимое на тот момент — абзац «Первый релиз». Я прорабатывала ядро, джун подключился на модулях. Джун работал уже с нами какое-то время, умел пользоваться инструментами, знал фреймворк, поэтому учить уже не пришлось. Плюс, у нас к тому моменту была достаточная база своего кода, поэтому частично использовали наработки.По самому первому релизу уже нет скрина, но одна из первых версий админки выглядела примерно так: скрин. Там было далеко не всё хорошо и правильно.
С тех пор прошло года 2, за всё время развития CMF было потрачено гораздо больше, чем 100 часов. Это процесс непрерывной разработки, который будет продолжаться. Всегда есть, что исправлять и улучшать.