Что Нужно Знать При Разработке Cmf И Cms. 2 Года Опыта

Если вы разрабатываете сайты с использованием PHP-фреймворков и еще не имеете собственной платформы, то наверняка задумывались об этом.

Это может быть CMF, CMS, конструктор сайтов, набор компонентов – материал подойдет для любого из этих случаев.

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



Что нужно знать при разработке CMF и CMS. 2 года опыта

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

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

Для каждой компании, занимающейся веб-производством, естественно сформировать набор компонентов, которые часто используются.

Иногда это буквально набор компонентов, иногда это образцы конструкций (которые впоследствии берутся за основу при разработке нового), иногда это перерастает в система управления контентом или ЦМФ .

Последнее — спасение для компаний, если разработка на популярных 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 Junior или Middle. С этим обоснованием вы уже можете идти к своему руководителю и коллегам.

Теги: #cmf #CMS #php #коммерческая разработка #советы #оптимизация разработки сайта #CMS #Разработка сайтов


Если вы разрабатываете сайты с использованием PHP-фреймворков и еще не имеете собственной платформы, то наверняка задумывались об этом.

Это может быть CMF, CMS, конструктор сайтов, набор компонентов – материал подойдет для любого из этих случаев.

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



Что нужно знать при разработке CMF и CMS. 2 года опыта

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

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

Для каждой компании, занимающейся веб-производством, естественно сформировать набор компонентов, которые часто используются.

Иногда это буквально набор компонентов, иногда это образцы конструкций (которые впоследствии берутся за основу при разработке нового), иногда это перерастает в система управления контентом или ЦМФ .

Последнее — спасение для компаний, если разработка на популярных 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 Junior или Middle. С этим обоснованием вы уже можете идти к своему руководителю и коллегам.

Теги: #cmf #CMS #php #коммерческая разработка #советы #оптимизация разработки сайта #CMS #Разработка сайтов

Вместе с данным постом часто просматривают: