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

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

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

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

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

В чём мой опыт по теме
Более 2-х лет назад я села за CMF. Через 2 месяца вяло-текущих работ был сделан первый сайт на его базе. Идея окупила себя уже в первом квартале. Подключила коллег, которые ускорили развитие. Через 8 месяцев среднее количество сайтов в квартал стало в 2-3 раза больше, чем раньше, при том же количестве рук и лучшем качестве. Попутно внедрили документирование и обучение клиентов. Это если очень кратко.

Основа


Итак, вы решили создать свой инструмент. Нужно решить 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 джуна или мидла.

С таким обоснованием уже можно идти к руководителю и коллегам.
Поделиться публикацией

Комментарии 31

    0
    Определите аргументы, почему нужно это делать, почему готовые решения не подходят. Если аргументы будут весомыми, это придаст вам уверенности. Если слабыми, это поможет избежать лишней траты времени.
    Почему не подходят готовые решения (популярные CMS). Они тяжеловесные, одновременно избыточные и недостаточные для наших задач.
    Это даже не слабый ответ, это вообще не ответ на самый основной вопрос. Есть конкретнее?
      +1
      Обычный ответ: кастомизация под конкретные требования сравнима с написанием с нуля.
        +2
        Это должны быть очень «своеобразные» требования, чтобы не использовать CMF. Либо нехватка мощности/масштабируемости, но там вопрос между чем-то своим и CMS уже не стоит.

        На том же October CMS можно из админки руками наделать сколько угодно таблиц, контроллеров, видов… Если, конечно, не устраивает самый известный велосипед — MODX
          0

          1) в статье поднят вопрос скорее писать CMF самим или использовать готовый.
          2) CMS и CMF разные вещи

        0
        Да. Коротко не получится, но постараюсь).

        Контекст моего примера — разработка сайтов для автодилеров. Как правило, они небольшой или средней сложности. Но у этого направления есть свои особенности — набор разделов, модулей (у всех есть модельный ряд, у части есть авто с пробегом), требований дистрибьютора к сайту автодилера. И при этом требования могут сильно отличаться, они просто разные у каждого бренда, модельный ряд по структуре контента тоже сильно разнится.

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

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

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

        Это если про контекст примера, с которого всё началось. Сейчас наша CMF подходит под множество отраслей.
          0
          Достаточно много лет назад делали примерно то же самое.
          Сделали конструктор конфигураций, выбор, сравнение по характеристикам, сохранение собранной пользователем конфигурации и тд… В-принципе, этот модуль можно прикрутить вообще к абсолютно любой CMS, и разработки собственной не понадобилось
            +2
            Спасибо за подробный ответ, но скорее всего вы просто не знаете существующие инструменты.

            В плане автодилеров хорошо знаю кейс, буквально недавно приводили успешно работающий сайт клиента под дизайн и верстку дистрибьютера. Абсолютно никаких проблем, CMS Modx. Вышло тоже быстро и легковесно. Конфигураторы любой сложности делаются легко на основе Vue.js.

            Почему вам не подошел MODx и Vue? Вордпресс и друпал действительно была бы боль…
              0
              На тот момент на Modx довелось поработать, Vue ещё не был в поле моего зрения. Но суть не в этом. После рассмотрения нескольких фреймворков и CMS я остановилась на том, что для меня быстрее и лучше всего решит мою задачу. У меня были проекты на фреймворке, 3 года опыта работы на нём на тот момент, сформировалась большая база кода.
              Наверняка, на большинстве инструментов можно сделать хороший кейс, если компания на этих инструментах специализируется. В мой пример вы можете подставить любые технологии, если для вас они подходят лучше всего.
                0
                Дык любой велосипед по сути и рождается от незнания разработчиком аналогичных готовых решений. Во первых все знать невозможно, а во вторых скорость разработки велосипеда зачастую намного выше, чем поиск и освоение чужих наработок.
                  0
                  При работе с MODx часть разработчиков запихивает товары в текстовые страницы с кучей разных чанков под нужные шаблоны (вместо того чтобы запилить отдельный модуль), отчего большие магазины просто падают, к тому же если не чистить кэш хотя бы раз в месяц, то сайт тоже упадет без видимой на то причины. Это я правда про EVO, с REVO не работал)

                  Но, в целом, CMF MODx очень даже понравился. Сейчас работаю на студийной CMS самописной и тоже встал вопрос о том, куда и как расти.
              +1
              Вопрос: существуют CMS не на ПХП? :)
                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, там хороший каталог цмс. Например через гугл каким нибудь запросом, типа: <a href=«https://www.google.com.ua/search?q=site%3Awww.cmsmagazine.ru%2Fcatalogue%2F+»asp.net"">site:www.cmsmagazine.ru/catalogue/ «asp.net» вписав соответствующую технологию))
                  0
                  >> цмс творю на Java + Jetty + Postgresql
                  jetty — контейнер сервлетов + веб-сервер… неужели код вашей цмс завязан на реализацию jetty и не переносим в другие контейнеры?
                    0
                    Действительно. Может ещё код вашей цмс и на postgresql завязан и не переносим на другие субд?
                      0
                      Не кидайте сильно помидорами, но да)) Код нашего сервиса на текущий момент завязан на embedded Jetty, который стартует наш лаунчер. В дальнейшем рассматривается вариант переписать имплемента́цию веб сервера на Netty, но пока это преждевременная оптимизация.
                      И для DAO мы используем MyBatis, поэтому переносимости на другие базы нет)) Запросы пишутся с использованием конкретных вкусняшек Postgresql (рекурсивные запросы, возврат Id, явные вызовы сиквенсов, процедуры, планируем постепенно переписать код на использование upsert и т.п)
                      Так как наша система позиционируется как PaaS, и как коробочная версия не планируется распространятся, система точилась под конкретные решения, в виде java приложения запускаемого на отдельных серверах с возможность горизонтального маштабирования
                        0

                        Но только с вертикально масштабируемой СУБД? Или шардинг тоже предусмотрен?

                          0
                          На текущий момент под сайт идет собственная база (схема). Т.е. можно горизонтально масштабироваться как по воркерам, так и по инстансам субд. Если нагрузка на конкретный сайт уже будет требовать шардинг, то ничего не помешает поставить пару реплик Postgresql в режиме чтения и через pgbouncer раскидать запросы. Исходя из профиля нагрузки (много чтения, мало записи) тут есть хороший простор для вариантов работы со слейвами.
                0
                Если уже был взят Codeigniter, то создание CMF свелось к выбору подходящих готовых решений? Или была непосредственно разработка CMF?
                  +1
                  Непосредственно разработка CMF. С проработкой архитектуры, возможности масштабирования, отстройки от задач, которые чаще встают перед командой.
                  +4
                  Киллер-решение за 100 часов? Я бы глянул, что получилось на выходе. Если в помощь брать джуна, на обучение которого надо тратить время, то посмотреть стало бы еще интереснее. Не примите за наезд, просто пытаюсь понять, может я такой слоупок. На такую фундаментальную штуку, да чтобы еще и с тестами, и все везде хорошо и продуманно, и все фичи желаемые были, я бы часов 800-1000 закинул.
                    0
                    В статье указано, что 100 часов — это «Ресурсы для первого релиза» в условиях совета «Не ставьте слишком больших целей для первого релиза.». В первом релизе было только необходимое на тот момент — абзац «Первый релиз». Я прорабатывала ядро, джун подключился на модулях. Джун работал уже с нами какое-то время, умел пользоваться инструментами, знал фреймворк, поэтому учить уже не пришлось. Плюс, у нас к тому моменту была достаточная база своего кода, поэтому частично использовали наработки.

                    По самому первому релизу уже нет скрина, но одна из первых версий админки выглядела примерно так: скрин. Там было далеко не всё хорошо и правильно.
                    С тех пор прошло года 2, за всё время развития CMF было потрачено гораздо больше, чем 100 часов. Это процесс непрерывной разработки, который будет продолжаться. Всегда есть, что исправлять и улучшать.
                    0
                    Есть ли демо-версия или github?
                      0
                      У проекта закрытый код, в общий доступ не выкладываем, сам по себе инструмент не планируем распространять. Демо версии отдельно нет, потому что для клиентов в продажах работает лучше всего — это показать уже готовый сайт реального клиента, который максимально близок — им важен не инструмент, а конечный результат, который решает задачу бизнеса.

                      Думала в будущей статье рассказать про то, как мы сделали модуль SEO, благодаря которому наши сайты проходят аудит у конкурентов. Там без демо не обойтись и техническое решение частично нужно показать. Тема интересна?
                    +1
                    Как основу выбирайте простой инструмент — язык, базовый фреймворк. С низкой точкой входа, чтобы проще было развивать сам инструмент и проще поддерживать конечные продукты. При этом ему необязательно быть очень популярным, достаточно быть простым. Ещё он должен развиваться

                    Вас не смущает тот факт что Codeigniter не особо развивается в последнее время, а его архитектура не использует принципы SOLID что способствует проблемам тестирования, масштабируемости, автодополнения в IDE?
                      0
                      Да, он развивается не так интерсивно, как Yii или Laravel. Но развивается. Вот репо 4 версии: https://github.com/bcit-ci/CodeIgniter4. Новость о выходе релиза Pre-Alpha 1 http://blog.newmythmedia.com/blog/show/2016-06-25_Getting_Started_With_CodeIgniter_4_Pre-Alpha_1, вторая фаза почти завершена. С архитектурой у меня и коллег проблем не было. Тестами пользовалась ещё когда была вторая версия. Масштабируем его активно, пример — модульность, HMVC, можно брать и прикручивать либы из других фреймворков, если нужно. С автокомплитом решили тоже ещё со второй версии, работали в нетбинсе, сейчас в phpstorm.
                      0
                      Готов первичный функционал — задокументируйте, что получилось.

                      Вопрос автору, есть ли какие-то инструменты или чеклист, или может быть онлайн сервис, чтобы задокументировать готовый функционал так, чтобы его мог прочитать другой человек (или я в будущем). Может какие-то графические инструменты…
                        0
                        Из онлайн сервисов могу порекомендовать Read the Docs, и как средство документирования — Генератор документации Sphinx. Если нравится формат wiki, то посмотрите DokuWiki. Может кто-то в комментариях что-то ещё добавит.

                        Мы у себя используем Sphinx, но не на Read the Docs, а отдельно на нашем сервере. Ещё сделали к нему веб-морду, чтобы с редактором могли работать не только разработчики, но и все сотрудники.
                          0
                          Если речь про документацию REST API, то обычно Swagger'а достаточно. Для чего-то минимально сложного можно в PlantUML диаграмки нарисовать и в с проектом репу запушить
                          0
                          Отличные советы, испытали все на шкуре https://yupe.ru
                          Если продукт планируется делать Open Source и для использования другими — можно еще столько же пунктов написать -)
                            0

                            Имхо, работая в веб-студии пиля однотипные "сайтики" для заказчиков, вполне себе можно запилить свою CMF и продолжить на этой CMF "клепать сайты". Сам работал в веб-студии, сам принял участие в разработке CMF которая является по сей день основной в компании.
                            Из плюсов такого подхода можно отметить следующее:
                            1) падаванов научить одной штуке проще, чем 100500 штукам которые представлены на рынке
                            2) лично я не встречал хороших CMF (ну, мб они есть, но я не видел)
                            3) потенциально безопаснее (security through obscurity), но это очень спорный вопрос
                            4) полная свобода действий, ты можешь запилить что угодно, и маловероятно что это сломается с очередным апдейтом "движка", как это бывает в случае использования стороннего ПО.
                            Минусы конечно тоже есть у этого… Очень часто "свои поделки" не следуют новомодным стандартам и тенденциям (то, о чем я выше написал, к примеру, врядли заработает на PHP7). Нет большого комьюнити которое может указать на недостатки, отправить ПР с фиксом, или что-то подобное. Ну и имеет место быть проблема связанная тем, что мол приходит в компанию человек новый, говорит мол "я знаю симфони, ларавель, юи, там все классно, няшно, бла-бла-бла", а у вас какая-то поделка, и разработчику приходится тратить энное колво времени на изучение этой системы.
                            Итого, в каких-то случаях плюсы перевешивают, в каких-то — минусы.

                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                            Самое читаемое