Версия РНР 5.0 была выпущена в июле 2004 года. В ней был внедрен целый ряд радикальных усовершенствований, и самым главным среди них, вероятно, стала коренным образом улучшенная поддержка объектно-ориентированного программирования (ООП). Именно это обстоятельство и вызвало повышенный интерес к объектам и методике ООП в среде разработчиков приложений на РНР. На самом деле это был новый этап развития процесса, начавшегося благодаря выпуску версии 4 языка РНР, в которой ООП впервые стало реальностью.
Проблема в том, что РНР - очень простой язык. Он искушает вас по пробовать реализовать свои идеи и радует хорошими результатами. Большую часть написанного кода на РНР можно встроить непосредственно в разметку веб-страниц, потому что для этого в РНР предусмотрена соответствующая поддержка. Введя дополнительные функции (например, код доступа к базе данных) в файлы, которые можно перенести с одной страницы на другую, вы не успеете оглянуться, как получите рабочее веб-приложение.
И, тем не менее, вы уже стоите на пути к краху. Конечно, вы этого не осознаете, потому что ваш сайт выглядит потрясающе. Он прекрасно работает, заказчики довольны, а пользователи тратят деньги.
Трудности возникают, когда вы возвращаетесь к исходному коду, чтобы начать новый этап разработки. Теперь ваша команда увеличилась, пользователей стало больше, бюджет также вырос. Но, если не принять меры, все пойдет прахом. Образно говоря, все выглядит так, как будто ваш проект был отравлен.
Ваш новый программист изо всех сил старается понять код, который вам кажется простым и естественным, хотя, возможно, местами слегка запутанным. И этому новому программисту требуется больше времени, чем вы рассчитывали, чтобы войти в курс дела и стать полноправным членом команды. На простое изменение, которое вы рассчитывали сделать за один день, уходит три дня, потому что вы обнаруживаете, что в результате нужно обновить порядка 20 веб-страниц.
Один из программистов сохраняет свою версию файла поверх тех серьезных изменений, которые вы внесли в тот же код немного раньше. Потеря обнаруживается только через три дня, к тому времени как вы изменили собственную локальную копию файла. Еще один день уходит на то, чтобы разобраться в этом беспорядке, а между тем, без дела сидит третий программист, который также работал с этим файлом.
Ваше веб-приложение пользуется популярностью, и поэтому вам нужно перенести его исходный код на новый сервер. Устанавливать на нем свой проект приходится вручную, и в этот момент вы обнаруживаете, что пути к файлам, имена баз данных и пароли жестко закодированы во многих исходных файлах. Следовательно, вы останавливаете работу своего веб-сайта на время переноса исходного кода, потому что не хотите затереть изменения в конфигурации, которых требует такой перенос. Работа, которую планировалось выполнить за два часа, в итоге растягивается на восемь часов, поскольку обнаружилось, что кто-то умный задействовал модуль ModRewri te веб-сервера Apache, и теперь для нормальной работы веб-приложения требуется, чтобы этот модуль функuионировал на сервере и был правильно настроен.
В конечном счете вы успешно преодолеваете второй этап разработки. И полтора дня все идет хорошо. Первое сообщение об ошибке приходит в тот момент, когда вы собираетесь уходить с работы домой. Еще через минуту звонит заказчик с жалобой. Его сообщение об ошибке напоминает предыдущее, но в результате более тщательного анализа обнаруживается, что это другая ошибка, которая вызывает похожее поведение. Вы вспоминаете о простом изменении в начале данного этапа, которое потребовало серьезно модифицировать остальную часть проекта.
И тогда вы понимаете, что модифицировано было не все. Это произошло либо потому, что некоторые моменты были упущены в самом начале, либо по тому, что изменения в проблемных файлах были затерты в процессе объединения. В страшной спешке вы вносите изменения, необходимые для исправления ошибок. Вы слишком спешите и не тестируете внесенные изменения. Ведь это же простые операции копирования и вставки, что тут может случиться?
Придя на работу на следующее утро, вы выясняете, что модуль корзины для покупок не работал всю ночь. Оказалось, что, внося вчера изменения в последнюю минуту, вы пропустили открывающие кавычки, в результате чего код стал неработоспособным. И пока вы спали, потенциальные клиенты из других часовых поясов бодрствовали и были готовы потратить деньги в вашем интернет магазине. Вы исправляете ошибку, успокаиваете заказчика и мобилизуете команду на "пожарные" работы в течение еще одного дня.
Подобная история о ежедневных буднях программистов может показаться преувеличением. Однако многие проекты на РНР начинались с малого, а затем превращались в настоящих монстров! В данном проекте логика приложения содержится также на уровне представления данных, и поэтому дублирование происходит уже в коде запросов к базе данных, проверке аутентификации, обработке форм, причем этот код копируется с одной страницы на другую. Всякий раз, когда требуется внести коррективы в один из таких блоков кода, это приходится делать везде, где присутствует такой код, иначе неминуемо возникнет ошибка.
Отсутствие документации затрудняет понимание исходного кода, а недостаточность тестирования оставляет скрытые дефекты не обнаруженными вплоть до момента развертывания приложения. Изменение основного направления деятельности заказчика часто означает, что в результате модификации прикладной код меняет свое первоначальное назначение и в конце концов начинает выполнять задачи, для которых он изначально вообще не был предназначен. А поскольку такой код, как правило, разрабатывался и развивался в качестве единой гремучей смеси, в которой было много чего намешано, то очень трудно, или даже невозможно, перестроиться и переписать отдельные его фрагменты, чтобы он соответствовал новой цели.
PHP используется в двух основных областях:
Серверные скрипты
Язык PHP изначально разрабатывался для создания динамического веб-контента и до сих пор лучше других языков подходит для этой задачи. Для генерирования разметки HTML вам понадобится парсер PHP и веб-сервер для отправки закодированных файлов. PHP также отлично генерирует динамический контент через подключение к БД, документы XML, графику, файлы PDF и т. д.
Скрипты командной строки
PHP может выполнять скрипты в режиме командной строки по аналогии с Perl, awk или командной оболочкой Unix. Скрипты командной строки могут использоваться для таких задач системного администрирования, как резервное копирование и разбор журналов, а также для разработки некоторых скриптов в стиле заданий CRON (невизуальных задач PHP).
PHP работает на всех основных операционных системах, от семейства Unix (включая Linux, FreeBSD, Ubuntu, Debian и Solaris) до Windows и macOS. Он может использоваться на всех основных веб-серверах, включая Apache, Nginx и OpenBSD (и это далеко не полный список), и даже в облачных средах, таких как Azure и Amazon.
Сам по себе язык отличается исключительной гибкостью. Например, он не ограничивается выводом только разметки HTML или других текстовых файлов и позволяет генерировать любые форматы документов. В PHP есть встроенная поддержка генерирования файлов PDF и изображений в форматах GIF, JPEG и PNG.
Одной из самых выдающихся особенностей PHP является обширная поддержка БД. Он поддерживает MySQL, PostgreSQL, Oracle, Sybase, MS-SQL, DB2, ODBC-совместимые и многие менее известные БД, а также новые БД в стиле NoSQL (такие, как CouchDB и MongoDB).
PHP упрощает создание веб-страниц с динамическим контентом с использованием информации из БД. Он предоставляет библиотеку кода PHP для решения таких стандартных задач, как абстракция БД, обработка ошибок и т. д. Для этого используется PEAR (PHP extension and application repository) — фреймворк и система распространения повторно используемых компонентов PHP.
