1. Представьте, что на сайте нужно организовать два раздела Новости, например: новости компании и новости отрасли. Как это проще всего сделать?
2. Подумайте, как удобнее работать с системой при наличии 20 тысяч страниц. Создайте их с помощью генерации скриптом и посмотрите, как справляется система.
3. Представьте, что администрированием сайта решили заняться не программисты: верстальщик, веб-дизайнер, администратор, секретарь, директор. Какие сложности у них могут возникнуть при самостоятельном освоении? Как упростить их работу? Как ускорить обучение?
4. Проверьте работу вашей CMS на HTTPS, в некорневой папке на сервере, с PHP 7 версии.
5. Если вы создаете свою CMS на чужом фреймворке, подумайте, что будет, если разработчики прекратят развитие фреймворка? Как сложно будет перейти на другой фреймворк и возможно ли это в принципе? Подумайте, на какой именно фреймворк можно было бы перейти. А что на счет других сторонних компонентов?
6. Как осуществляется переход от сайта к редактированию его страниц в администрировании? Насколько это понятно, быстро и просто?
7. Как много ненужной информации видно на главной странице администрирования?
8. Задумайтесь о версионности вашей системы и возможности миграции базы данных от версии к версии.
9. Главное преимущество хорошей CMS - легкость внедрения сверстанного HTML-шаблона. Можете это обеспечить - замечательно.
10. Не забывайте про документацию. Она может быть ориентирована также на разные типы пользователей: редактор, администратор, разработчик.
11. Ошибки неизбежны. И это нормально. Если вы выкладываете свою CMS для свободного скачивания всем (или вашим клиентам), постарайтесь следовать простому правилу: выкладывать новые версии только со вторника по среду, не выкладывать с 15 декабря по 15 января. Это сильно поможет успеть разобраться с возможными ошибками до выходных или праздников. Правило обосновано статистикой.
12. Главное - качество обслуживания клиента и удовлетворения его потребностей. Качество кода вторично, но не является неважным! А вот над качеством архитектуры крайне важно задуматься на первом этапе разработки CMS.
13. Если вы не собираетесь переплюнуть Вордпресс, Друпал и Джумлу - лучше не делайте свою систему бесплатной или очень дешевой. В глазах клиентов (ваших клиентов или клиентов разработчиков, которые используют вашу систему) это будет выглядеть как «Скупой платит дважды».
14. Справится ли ваша CMS со 100 запросами в секунду на недорогом виртуальном сервере? Что нужно, чтобы справилась?
15. Разработка своих собственных компонент намного эффективнее (в плане дальнейшей поддержки) доработки стандартных компонентов — это единственный правильный выбор при разработке любых нетиповых хотелок заказчика именно потому, что код максимально минифицирован и в нем нет того, что не работает. Для этого ваша CMS должна иметь соответствующую справку, примеры реализации дополнений и удобные инструменты. Не забывайте, что реализация нестандартной функциональности через стандартные компоненты обязательно приводит к разведению болота в коде и затрудняет обновление и дальнейшую стороннюю поддержку системы.
16. Подумайте о миграции с других, например, самых популярных CMS.
17. Не забудьте про обработку ошибок. Хорошо, когда при включенном отображении ошибок, ни на одной странице сайта не видно ошибок. Если ошибки возникают - они должны быть не только осмысленны и неповторимы, но и предоставлять возможность найти в коде CMS место возникновения ошибки. Очень плохой пример (PHP): использование @ вместо isset и проверки на null. Пример еще хуже и популярнее - не использовать даже @.
18. Пишите для России - подумайте об интеграции 1С.
Если есть, чем дополнить советы - пишите в комментарии.
