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

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

Совершенно бессмысленно создавать кэш для функций, которые редко вызываются в коде. В этом случае затраты на кэширование просто не «окупаются».

Существует два основных подхода к организации кэша: в файле и в памяти.

Читать дальше...

PHP Standards Recommendations — это набор рекомендаций для разработчиков на PHP. Отношение к PSR разное: от полного неприятия, то фанатичной преданности. Сам по себе PSR появился как копирование Java Community Process (ага, опять Java!). Основное назначение PSR в том, чтобы предоставить PHP-разработчикам некие общие концепции, которые уже были проверены и отработаны.

На сегодняшний день существует 20 рекомендаций PSR. Часть из них находится в активном статусе, другие в виде черновиков. Есть «заброшенные» и отмененные рекомендации. В общем «движуха» достаточно активная. Попробуем во всём этом разобраться.

Читать дальше...

Любое веб-приложение начинается с идеи. Скорее даже абстрактной идеи, которая в двух словах рассказывает какую проблему клиента нужно решить. После этого идея начинает уточняться: как решить, каким способом, что для этого требуется? Таким образом формируется начальное техническое задание, где не затрагивая непосредственную реализацию, уточняется круг основных задач. На следующем этапе начинают отрабатываться базовые элементы взаимодействия, например регистрация пользователей или ключевые элементы интерфейса.

Таким образом ТЗ постоянно усложняется до тех пор, пока не станет казаться что все нюансы оговорены и можно приступать к реализации проекта.

От программистов обычно ждут строгого следования ТЗ. Если, не дай бог, к составлению ТЗ привлекают дизайнера, то всё обычно сводится к тому, чтобы соответствовать рисованным макетам, а программирование — ну после как-нибудь прикрутите. Это конечно, колоссальная ошибка, потому что перед тем, как что-то «рисовать» и серьёзно «программировать», необходимо опробовать идею/задачи в черновом варианте. Этот этап называется прототипированием.

Несколько лет назад я делал приватный проект, где было много математики и обработки данных. Поскольку хотелось сразу сделать правильно, то использовал ООП, классы, статические методы и ряд новых функций PHP 5.5. После того, как проект загрузили на «боевой» сервер, всё «разрушилось», поскольку там стояла PHP 5.2, которую (по каким-то особым причинам), нельзя было обновить. Код пришлось переписывать с учётом старой версии. Теперь, если сервер всё-таки обновят до PHP 7.x, код опять придётся переписывать, поскольку между версиями нет полной совместимости.

Не существует идеального и универсального решения для веб-проекта. Они все обязательно окажутся в тупике из-за изначально непродуманной архитектуры или объективных причин, вроде несовместимости между PHP-версиями. Даже если сделать как «по теории», в процессе развития проект окажется неспособным решить какие-то новые задачи, поскольку мы элементарно не можем предсказывать будущее. Единственным способом двигаться дальше будет только революционный подход, который подразумевает полную или частичную потерю совместимости со старым кодом.

Через это прошли все фреймворки, системы, библиотеки (любого ЯП) и т.п., которые продолжают развиваться. По мере роста, вначале идёт эволюционный подход, когда возможностей хватает, но потом резкий скачок к новой версии. Для того, чтобы упростить такие переходы, архитектура приложения должна изначально подразумевать такую «версионность».

При разработке php-проекта часто возникает потребность разделить его на небольшие части — модули. Слово «модули» довольно расплывчато и в разных случаях может трактоваться по своему, но в данном случае речь идёт только о том, что модуль — это некий код, который может представлять собой единую сущность.

Программно модуль может быть набором классов, функций и файлов. Он может содержать html-код, css-стили, js-скрипты, изображения и т.п. То есть не важно как в реальности реализован модуль, главное это то, что мы можем его воспринимать как единое целое.

Когда в проекте много php-классов, то возникает проблема подключения их файлов. Например есть классы Class1 и Class2. Для того, чтобы их использовать, вначале нужно подключить их php-файлы. Само по себе подключение — это обычные require или include, поэтому задача сводится к тому, чтобы указать правильный путь к php-файлу. По мере, того как классов становится всё больше, возникает серьезная проблема с подключением каждого файла класса. В идеале процесс подключения должен быть автоматизирован и в PHP для этого используется механизм автозагрузчика.

Автозагрузчик будет срабатывать каждый раз, когда в коде встретится неизвестный класс. Сам по себе автозагрузчик представляет собой обычную функцию, которая и выполняет подключение файла с помощью require. Функция автозагрузчика должна быть зарегистрирована через специальную функцию spl_autoload_register. При этом функций можно зарегистрировать несколько — PHP последовательно их выполнит пока не подключит файл с нужным классом.

Давайте рассмотрим несколько примеров, чтобы лучше понять как это всё работает (исходные файлы можно скачать в конце статьи).

Пока я не стал баловаться программированием на Javа, особо не задумывался над использованием MVC в PHP. Обычно действуешь по своему опыту или как это принято в php-фреймворке (или CMS, не важно). Тем более почти все фреймворки декларируют свою преданность концепции MVC: дескать вот у нас всё сделано правильно, по теории.

После Java, где объектное программирование возведено почти в абсолют, MVC в PHP выглядит уже достаточно «бледно», пытаясь хоть как-то соответствовать этой концепции. Интересно ещё и то, что php-разработчики Model-View-Controller видят по разному и не всегда верно.