Вперёд, в будущее!
Начало
Да, именно так: я начинал писать основу PHP движка в 2001-ом году.
Тогда всё было проще: каталог inc/, в нём header.php, footer.php, common.php.
Но это было скучно и неинтересно, надо было ещё больше фишек, которые я бы мог предложить заказчикам. Так появился раздел admin/. Но примерно в тоже время появился PHPNuke, это была бомба! Такой уровень кастомизации! Я понял, чтоничего подобного я предложить не смогу, но и по требованиям мой движок былкуда как проще, хотя позволял организовать каталог товаров, список статей, галерею. Несколько лет я дальше двигался по основной своей работе: администрирование Linux-серверов.
Но как-то мне предложили работу в фирме именно PHP-разработчиком. Я ознакомилсяс проектом, и меня порадовали две вещи:
1. Все шаблоны в своём формате.
2. И они вместе с настройками лежат в базе данных.
Это же прекрасно! Какая гибкость! Ну и пусть на открытие заглавной страницы уходит 50+ запросов!С таблиц, в которых и 100 строк бывает редко, MySQL делает выборки мгновенно.
От наследия той работы я до сих пор не могу избавиться: например меню в моейCMS строится именно на основании данных с БД, но есть кэширование. Так же до сих пор поддерживается мной придуманный формат шаблонов, хотя вряд ли когда-нибудь я им воспользуюсь.
Ещё с той работы я привнёс в свою работу Subversion: это было круто! Пара команд - и мой домашний репозиторий с рабочим синхронизирован за бесплатные 60 секунд через 8w180! А когда начальство говорит что я нифига не делал то легко подвести статистику добавленных/изменённых строк! Работал я тогда,как правило,сдельно
Продолжение
Так я "проспал" появление AJAX, появление ООП в PHP, хотя последнее я просто не воспринял: зачем, когда у тебя в inc/ теперь уже не три файла, а пять, но всего пять и всё работает?
И да, примерно в то время благодаря одному из своих друзей я поставил на основной сервер Gentoo. Это было круто! Совсем другой уровень управления сервером! Когда на основном сервере стоит и абсолютно правильно работает Gentoo - на админов всяких Редхатов и Дебианов смотришь известно как :)
А как программист я стагнировал :( Переломным моментом должен был стать сайт для моих друзей с продвинутым каталогом товаров: тогда количество костылей в catalog/index.phpпереполнило все мыслимые пределы. Там на несколько лет появилась строка
$input["list_id"];
И всё. Просто написал! Ничего ничему не присваивается, никак не обрабатывается!
Но я несколько лет не удалял эту строку, она просто была незаметна на фоне огромного спагетти кода подпёртого костылями.
И тут очень хороший человек предлагает для его сайта сделать весьма интересный функционал. Ладно, я готов к новым испытаниям. Я тогда не знал, что такое Битрикс... Специалисты по нему, увидев мой код, могут упасть в обморок: я писал исключительно прямыми запросами к базе данных через $DB->Query. Часто они бывали весьма многострочными, но это всё равно было лучше, чем использовать недоORM Битрикса. И да, сколько вечеров было проведено, пока мы с другим очень хорошим человеком разгребали почему штатная выгрузка с 1С не работает! И тогда был курьёзный случай: я уже в модуль ядра полез, чтобы логирование добавить чтобы узнать на каком именно элементе каталога стопорится выгрузка, коллега подходит и говорит: Игорь, это же нифига не английский!? И тут я понимаю, что это, блин, немецкий: функции и переменные в XML парсере Битрикса на немецком! А я по запарке даже и не заметил! Хоть раз в карьере пригодился язык, который я в школе и институте учил. Проект был выполнен, но сейчас, к сожалению, он оказался никому не нужен :(
Позднее, когда пара людей мне предложили развить интересный проект на Yii1, я понял,как много я упустил за эти годы! Но свою CMS я не трогал особо:и страшно и вроде как не нужно. Проект на Yii1 в итоге не взлетел, но это был бесценный опыт. И когда мне предложили сделать свой, достаточно серьёзныйпроект, с нуля я недолго раздумывал: Yii2. С базой данных у меня не было сомнений: MariaDB, ибо с MySQL я, будучи сисадмином, научился делать EXPLAIN, чтобы запрос вместо трёх минут выполнялся меньше секунды.
Прозрение
И тут я споткнулся об реальность: я же толком никогда ООП не использовал в PHP. Спасибо видеоурокам Дмитрия Елисеева и шаблону приложения от Vova07. За пару месяцев я написал CRUD'ы для админского раздела, разумеется используя миграции и RBAC, дальше самразобрался как сделать REST API, разбил всё на модули и так далее. Но сегодня не об этом.
В своей CMS всё так же несколько файлов в каталоге inc/. Для приличия переименовал вinclude/. Поломал обратную совместимость :( На сервере ln -s ./inc ./include, но даже полному идиоту понятно, что это нереальный костыль :( Собираю и раскидываю функции по include/lib_*, лезть в скрипты, касающиеся каталога, боязно. Но тут опять же спасибо Дмитрию Елисееву: его курс про микрофрэймворк стал определяющим: нафиг свой шаблонизатор, когда есть Twig? Какие ещё отдельные JS скрипты и CSS файлы, когда благодаря laravel-mix можнов пару команд собирать бандл? Причём вместо CSS использовать SASS, который для меня сталнебольшим, но всё же открытием, и я за минут двадцать все стили перевёл на него.
А тесты!.. Это отдельная тема. С начала своей карьеры как сисадмина я видел, что в руководствах часто между make и make install бывает make test. Как долго идёт ./configure с ключами и при этом много что тестируется, какие ещё тесты нужны? Но тут попробовал - и понравилось! Меняю что-то в ключевых классах, запускаю composer test - и как приятно видеть, что они проходят! А если не проходят, то сразу понятно, где я что поломал. К сожалению, связность в моей CMS очень сильная, TDD я попробовал, но этот подход при такой связности скорее замедляет разработку, чем помогает :(
В итоге решил переписать 100500 костылей под нормальную архитектуру.
Решение
Это было непросто. Особенно морально: сисадмин внутри меня даже не говорил - кричал:"Работает? Не трожь! Обратную совместимость поломать решил? Идиот, сам же будешьчинить!". Но жребий был брошен, Рубикон перейдён: начав с самого простого: модуля статей, я в итоге переписал все модули, даже модуль каталога товаров. Да, я кодом недоволен и сейчас: до чистого кода далеко. Но код ради кода - это не то, к чему я стремлюсь: например DI контейнер в такой простой задаче будет перебором. Хотя кроме DI контейнера можно многиепрактики привнести, например, использовать request, response, log, cache, да и сам контейнерпо PSR, но я пока не вижу смысла тащить такие зависимости в проект :)Ведь чем меньше зависимостей тем проект надёжнее. Но для миграций я добавил в проект Phinx, который за собой притянул symfony/console и фреймворк Сakephp. Первый грех было не использовать а с Сake я в итоге взял модули кэширования и логер: зачем в очередной раз писать свои костыли или тянуть зависимости если эти компоненты и так уже в проекте?
Итог
В итоге это был непростой путь, но я доволен результатом. Конечно, впереди ещё многое предстоит сделать, но уже сейчас я готов поделиться своими наработками с сообществом. Жаль, что заказчики не видят разницы между набором костылей и более чистым кодом, в который можно вносить изменения, не опасаясь выбить карту на которой весь костыльный домик держится. Но оно того стоило, однозначно!
Ах, да: https://github.com/crlam0/cms
