Хочу опубликовать небольшой сборник советов для современных PHP-разработчиков. Я умышленно не связываю их с теми или иными фреймворками, библиотеками и тп. Надеюсь, что мои советы помогут кому-то лучше понять PHP, научиться лучше его использовать. Некоторые из них могут быть не специфичны для PHP, но для программирования в общем.Быстрый PHP код содержит минимум PHP.
Пожалуй, этот совет подойдет многим разработчикам на интерпритируемых языках. В PHP содержится огромное количество нативных (написанных на Си) функций. Их скорость превышает любой аналог на PHP. Старайтесь использовать их вместо PHP-аналогов.
На самом деле, конечно, сложно держать в голове все встроенные PHP-функции. Я выработал для себя правило: прежде чем написать функцию, попробуй поискать ее в документации. В большинстве случаев находится нативная функция.
Примеры:
1. Надо было разобрать url на компоненты. Регулярными выражениями стараюсь не пользоваться для таких вещей. Функция нашлась быстро: parse_url.
2. Распарсить url функцией parse_url удалось успешно, теперь надо было разобрать GET-параметры из url'а. И для этого нашлась функция: parse_str.
Расширения работают быстрее чем PHP-код.
Для PHP существует репозиторий расширений: PECL. Там можно найти много интересного. Расширения пишутся также на Си и работают шустрее аналогов на PHP. Например, я использую apc и yaml. Думаю, и вы сможете обнаружить там немало интересного для себя.
Осторожно используйте сторонний код.
Одна из самых больших проблемах, которые я встречал в продуктах, реализованных на PHP — это высокая связность со сторонним кодом, которая не позволяет заменить один сторонний инструмент на другой. По сути этот совет связан с общим подходом к минимизации связности, но особо остра проблема именно со сторонними компонентами.
Если вы решили использовать стороннюю библиотеку, то во-первых убедитесь, что в структуре папок вашего проекта существует специальная директория для сторонних инструментов. Не следует смешивать код проекта и код сторонних инструментов.
Далее, создайте свои классы для работы с библиотекой, которые бы проксировали вызовы в библиотеку, но интерфейс этх классов не обязательно должен соответствовать интерфейсу библиотеки. Он должен быть общим и не привязанным к этой конкретной библиотеки, чтобы изменив логику в этих классах, вы могли перейти на другую библиотеку не переписывая сам проект.
Если вы столкнулись со случаем, когда библиотеки должны быть заменяемыми, то тут надо писать интерфейсы, провайдеры или даже абстрактные фабрики.
В любом случае нельзя допускать прямой связи между проектом и сторонним инструментарием, любое другое решение будет выглядеть выгоднее.
PEAR
Используете вы PEAR или нет, в любом случае вы должны знать что это такое. PEAR — это репозиторий PHP-классов для решения многих типовых задач. Расположен он по этому адресу: pear.php.net/packages.php. Я бы не сказал, что классы в PEAR отличаются каким-то особым качеством, или поддержкой, или чем либо еще. По сути это просто полезный репозиторий классов, более чистый чем phpclasses.org. Для установки и удаления PEAR-пакетов в PHP даже есть команда "pear", но с таким же успехом пакеты PEAR также можно просто положить в папку с приложением и использовать.
Используйте PHP 5.3.
Если вы не работаете над проектами, где хостинг выбирают за вас, то обязательно переходите на PHP 5.3.
Самое главное нововведение этой линейки PHP — это анонимные функции. Теперь вместо:
function my_temp_map($x) {
return $x + 1;
}
$result = array_map('my_temp_map', $arr);
Можно написать:
$result = array_map(function($x){ return $x + 1; }, $arr);
Более того, теперь можно объявлять суб-функции и использовать замыкания:
public function myMethod($data) {
$subFunction = function() use ($data) {… };
$x = $subFunction();
}
Кроме анонимных функций добавилось очень много интересного: php.net/ChangeLog-5.php
Далее я пойду больше в специфику.
Не используйте оператор "@".
Оператор "@", используемый для скрытия ошибок при выполнении определенной инструкции плох по двум причинами: во-первых он медленный, а во-вторых привыкание к нему нежелательно, потому как при использовании его к вызовам функций, вы автоматически заблокируете возникновение ошибок в вызываемой функции, что может быть нежелательным.
Часто оператор "@" используется при доступе к ассоциативному массиву в тех случаях, когда нет уверенности в существовании того или иного ключа. В этом случае можно обойтись такой конструкцией:
$x = isset($arr['x'])? $arr['x']: null;
Не используйте cp1251.
Товарищи, которые еще не перешли на utf8! Переходите! Чем раньше тем лучше.
При работе с utf8 понадобится PHP скомпилированный с расширением mbstring (входит в обычный набор при компиляции).
Работайте в режиме E_ALL | E_NOTICE | E_STRICT.
Именно в такой режим следует выставить error_reporting если вы начинаете работать над проектом. Нотисы — это то, что часто игнорирует и в то же время то, что чаще всего содержит ошибки. Если вы обратились к неопределенной переменной, к массиву по несуществующему ключу и тп, то возникнет NOTICE. Если вы не уверены в существовании переменной/ключа в массиве, следует проверять с помощью оператора isset.
Перечитывайте phpmanual.
Команда разработчиков PHP реализовала огромное количество функционала, который можно использовать в вашем проекте. Большая его часть описана в официальной документации, которая постоянно обновляется. Освежайте свои знания, приумножайте их, регулярно пересматривая мануал.
Как минимум надо знать все php.ini настройки и то, на что они влияют.
Развивайтесь.
Читайте код. Да. Читайте код тех инструментов, которые вы используйте. Читайте код фреймворков, на которых разрабатываете. Это очень интересно и полезно. Также вы узнаете, что пишут этот код не боги, а такие же программисты как и вы. А если будете внимательными, то обнаружите массу неоптимальных моментов или ошибок.
Пишите. Пишите свои инструменты, даже если есть готовые если в этом есть нужда, не стройте костыли, чтобы сторонние инструменты подогнать под ваши задачи. Думаете, что фреймворки пишут более опытные люди чем вы? Посмотрите код этих фреймворков.
На этом мои советы заканчиваются, спасибо за внимание.
