10 правил PHP-мастеров


Содержание материала:

Please verify you are a human

Access to this page has been denied because we believe you are using automation tools to browse the website.

This may happen as a result of the following:

  • Javascript is disabled or blocked by an extension (ad blockers for example)
  • Your browser does not support cookies

Please make sure that Javascript and cookies are enabled on your browser and that you are not blocking them from loading.

Reference ID: #1b4cfb50-019b-11ea-a83e-af2694e60af3

10 принципов мастеров PHP

Данный материал содержит мнения мастеров PHP-разработки по самым разным вопросам. Каждый из них является профессионалом в своей области и делится с нами частью своего знания этого языка.

1. Используйте PHP только тогда, когда это действительно необходимо – Расмус Лердорф

Расмус Лердорф создал PHP в 1995 году и, с тех пор язык распространился в среде веб-разработчиков как лесной пожар, меняя облик Интернет. Расмус, однако, не создавал PHP именно для этой цели. Язык PHP создавался не для решения задач веб-разработки.

Нельзя средствами PHP реализовать все, что угодно. Лердорф — первый, кто скажет вам о том, что PHP — просто один из инструментов в вашем арсенале, что даже PHP имеет свои ограничения.

«Используйте для работы нужные инструменты. Я встречал компании, которые с головой ушли в PHP, применяя его где ни попадя, но PHP никогда не был языком, подходящим для решения любой проблемы. Наиболее подходящая для него ниша — использование в качестве «интерфейсного» скриптового языка для Web».

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

2. Используйте много таблиц в связке «PHP+MySQL» для повышения масштабируемости – Matt Mullenweg

Никому не нужно объяснять, каков его авторитет в среде PHP-разработчиков. Он, вместе с сообществом разработал самую популярную на сегодняшний день систему для ведения блогов — WordPress. После создания движка, Matt и его помощники запустили wordpress.com — бесплатный сайт для блоггинга. На момент написания материала на wordpress.com размещены более 4 миллионов блогов, а их пользователи пишут по 140 тысяч постов ежедневно.

Если кто и знает, как масштабировать вебсайт, то это Matt Mullenweg. В 2006 Matt поднял завесу тайны над структурой базы данных в WordPress и объяснил, почему WordPress MU (многопользовательский) использует отдельные таблицы MySQL под каждый блог вместо того, чтобы использовать одну огромную «монолитную» таблицу для всех блогов.

«Мы тестировали такой подход для многопользовательской системы, но сочли, что его масштабируемость начиная с определенного момента потребует слишком высоких затрат. С монолитной структурой вы упираетесь в технические ограничения вашего «железа». В текущем же варианте пользователи разделены и могут быть легко разведены по разным группам, к примеру на WordPress.com пользователи разделены между 4096 базами данных, что позволяет производить масштабирование очень дешево и эффективно даже при наличии сотен тысяч и миллионов пользователей, при высоком уровне траффика.»

Возможность переноса таблиц позволяет коду и, в конечном счете, блогам, работать намного быстрее и легче масштабироваться. Умело используя кэширование и базы данных, Matt показал, что чрезвычайно популярные сайты вроде Facebook и WordPress.com могут работать на PHP и успешно справляться с невероятным потоком траффика.

3. Никогда не доверяйте своим пользователям – Dave Child

Dave Child — создатель сайта Added Bytes, частью содержимого которого являются великолепные «шпаргалки» по многим языкам программирования. Dave работал во многих компаниях-разработчиках в Великобритании и стал известен и авторитетен в среде программистов.

Dave предлагает вам и некоторые мудрые советы для написания безопасного кода на PHP: не доверяйте вашим пользователям. Они могут вас огорчить.

«Итак, наиболее важное правило веб-разработки, значение которого трудно переоценить: Никогда не доверяйте вашим пользователям. Исходите из допущения, что любая информация, передающаяся от пользователя содержит вредоносный код. Всегда. Это распространяется и на те случаи, когда вы считаете, что провели валидация на стороне клиента, скажем средствами JavaScript. Если вы справитесь с этим — считайте, что вы взяли хороший старт. Если для вас важна безопасность PHP-приложений, то самое важное для вас — применять это простое правило.»

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

4. Делайте ставку на PHP-кэширование – Ben Balbo

Ben Balbo писал для Site Point — очень уважаемого учебного сайта для веб-разработчиков и дизайнеров. Он состоит в комитетах Melbourne PHP User Group и Open Source Developers’ Club и он знает кое-что об этом языке. Неудивительно, учитывая его прошлое, связанное с PHP-разработкой и проведением тренингов в данной области и то, что он предлагает вдумчиво использовать кэширование.

«Если у вас есть нагруженный ресурс с преимущественно статическим контентом, например, блог, управляемый с помощью CMS, потребуется небольшая переделка, но в результате вы получите огромный прирост в производительности при небольших временных затратах. Установка кэширования для более сложных сайтов, которые генерируют различный контент для различных пользователей (например, порталы) потребует большего мастерства и временных затрат, но преимущества очевидны и в этом случае.»

Существует много способов кэширования в PHP:

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

5. Ускоряйте разработку на PHP, используя IDE (интегрированную среду разработки), шаблоны и сниппеты – Chad Kieffer

Когда Chad не занят работой над пользовательскими интерфейсами или администрированием баз данных, он дает экспертные советы со своего блога. Его кругозор очень широк и он часто видит более полную картину, которую не видят другие программисты, особенно когда дело доходит до глобального подхода, который Chad использует при разработке веб-сайтов. Он специализируется на всех аспектах разработки, поэтому любые идеи, возникающие у него при использовании такого подхода, могут оказаться весьма полезными.

Chad уверен, что использование IDE вроде Eclipse PDT (Eclipse’s PHP development package — набор Eclipse для PHP-разработки) с применением шаблонов и сниппетов может значительно ускорить процесс разработки проекта.

«Плотный график, огромные списки «to do» и дедлайны усложняют разработчикам жизнь, не позволяя им ознакомиться с продвинутыми функциями программ, в которых они работают. Это ужасно, поскольку некоторые возможности, вроде шаблонов в Eclipse, могут существенно снизить время кодирования и количество ошибок.»

Здравый смысл говорит о том, что если вы сумеете автоматизировать выполнение задачи, вы завершите проект быстрее. Потратив время на создание шаблонов, которые вы будете использовать снова и снова, вы сэкономите уйму времени при работе с повторяющимися блоками кода.

Используя IDE вроде Eclipse и набор Eclipse для PHP-разработки, вы обнаружите, что постепенно время, затрачиваемое вами на разработку уменьшается. IDE будет автоматически закрывать парные скобки, вы забудете, что такое пропущенная точка с запятой, вы даже сможете отлаживать код в редакторе, без загрузки файлов на сервер.

6. Лучше используйте функции фильтрации в PHP – Joey Sochacki

Хотя имя Joey Sochacki и не столь известно в среде PHP-разработчиков, как имя Matt Mullenweg, он является очень опытным веб-разработчиком и делится опытом, накопленным в процессе работы в своем блоге Devolio.

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

«Фильтрация данных. Всем нам приходится делать это. Большинство, если не все из нас терпеть не могут этого делать. Однако, есть известные немногим функции фильтрации в PHP, которые позволяют нам выполнять любые типы проверок и валидаций. Используя эти функции, мы может производить валидацию и подготовку различных типов данных, адресов url, e-mail и IP-адресов, удалять опасные символы и т.д. с относительной легкостью.»

Фильтрация может быть достаточно замысловатой, но с помощью Joey вы научитесь фильтровать практически все, что угодно, и использовать все преимущества фильтрации средствами PHP.

7. Используйте PHP-фреймворк – Josh Sharp

Всегда велись дебаты относительно того, использовать ли PHP-фреймворк вроде Zend, CakePHP, CodeIgniter, либо вообще не использовать их. У каждого из них есть свои достоинства и недостатки, и многие разработчики имеют на этот счет свое мнение.

Josh Sharp — веб-разработчик, который зарабатывает себе на хлеб с маслом создание сайтов для клиентов. Вот почему есть смысл поверить ему, когда он говорит о том, что использовать фреймворк — отличная идея, так как он помогает экономить время и избегать ошибок при программировании. Почему? Josh уверен, что из-за того, что PHP очень просто научиться.

«Однако легкость освоения PHP — слабость данного языка. Так как практически нет ограничений на структуру кода, то очень легко написать плохой код. Но есть выход — используйте фреймворк.

PHP-фреймворки помогают стандартизировать ваше приложение, и вы можете сэкономить уйму времени при работе над проектом.

8. Не используйте PHP-фреймворк – Расмус Лердорф

В противовес Josh Sharp Расмус, создатель PHP не считает, что фреймворки так уж хороши. Почему? Потому что они работают намного медленнее, чем «чистый» PHP.

Во время презентации на Drupalcon 2008 Расмус сравнивал скорость ответа страницы на PHP с типичным «Hello World» в случае использования чистого PHP и ряда фреймворков. Результаты показали, что фреймворки оказались намного медленнее, чем простой код PHP.

Если вкратце, то Расмус говорит о том, что наибольшая разница в производительности возникает при попытках использовать PHP-фреймворк как альтернативу простому PHP.

[Замечание: Если вам все же нужно использовать фреймворк, то Расмусу больше всего нравится CodeIgniter, так как он, по словам Расмуса «меньше всего похож на фреймворк»]

9. Используйте пакетную обработку – Jack D. Herrington

Jack Herrington — не чужак в мире PHP и веб-разработки. Он автор более 30 статей для престижного сайта IBM developerWorks. Jack также публиковал книги по тематике программирования, вроде «PHP-хаки». Jack — добротный специалист.

Jack D. Herrington рекомендует использовать пакетную обработку и крон для решения тех задач, которые могут быть решены в фоновом режиме. Пользователи в сети не хотят ждать долго. Есть некоторые задачи, решение которых занимает немало времени и их можно производить в фоновом режиме.

Конечно, в отдельных случаях немного проще выделить вспомогательный потока для выполнения небольшой задачи. Но легко увидеть и то, что с помощью обычных инструментов — крона, MySQL, обычного объектно-ориентированного программирования и Pear::DB создание пакетных задач в приложениях на PHP просто реализуется, просто развертывается и просто обслуживается.

«Я использовал оба подхода и я думаю, что крон обладает преимуществом «Keep It Simple, Stupid» (KISS) — «Делай проще, тупица». Он делает обработку в фоне очень простой. Вместо того, чтобы происходило постоянное выполнение нескольких задач в разных потоках, у вас есть простой скрипт, который запускается кроном. Скрипт проверяет, нужно ли что-нибудь выполнять. Если нужно — выполняет и завершается. Нет необходимости беспокоиться об утечках памяти. Не надо волноваться о срывах выполнения процесса и опасности попасть в бесконечный цикл.»

10. Немедленно включите Error Reporting – David Cummings

David Cummings руководит компанией, занимающейся разработкой CMS — систем управления контентом. Его компания завоевала несколько наград и если кто и знает, как разрабатывать PHP-приложения эффективно, то это David.

David написал в статье на SitePoint о двух вещах в PHP, которые он хотел бы знать, когда только начинал. Одна из них: Включите error reporting немедленно. Это сэкономит вам в перспективе чертову уйму времени.

«Это самая первая вещь, о которой я говорю людям, использующим PHP — выставить error reporting на отображение всех ошибок. Зачем? По умолчанию error reporting не установлена так, что вам не будут показываться многие, казалось бы, незначительные ошибки вроде:

— объявление переменной раньше времени,
— ссылка на недоступную в данной части кода переменную и др.

Эти вещи могут показаться незначительными, пока вы не начнете разрабатывать большие объектно-ориентированные приложения с функциями и классами. Очень часто, когда вам показываются не все ошибки, вы убьете не один час, рыская по своим функциям, которые не работаю из-за неправильно написанного имени переменной или невозможности получить к ней доступ.»

Error reporting может значительно помочь вам в случае установки на отображение всех ошибок. Пожалейте волосы на вашей голове и свое драгоценное время — пусть ошибки ищет PHP, а не вы.

5 советов по найму PHP-программиста

Просматривая резюме программистов PHP и собеседуя кандидатов на эту должность, эйчары даже крупных компаний иногда пропускают банальные вещи и тратят кучу времени на незначительные детали. В результате получается так, что человек успешно проходит личное интервью, а к работе оказывается не готовым. При этом вам все равно придется оплатить отработанные часы и потратить время на поиск нового сотрудника. Как с первого раза попасть в «яблочко»? Вам помогут 5 простых советов.

1. Исключите из собеседования на PHP Frontend и Backend Developer вопросы-пожиратели времени

Собеседование теряет смысл за 2-3 первые секунды, если вы:
• перечисляете места работы по резюме разработчика PHP, сверяясь все ли верно;
• задаете вопросы типа «Кто создал PHP и в каком году»;
• спрашиваете, как скоро кандидат готов выйти на работу в случае утверждения его кандидатуры, и не возникнет ли проблем с документами…

Если общая теория и вопросы «за жизнь» отношения к делу, скорее всего, совсем не имеют, то прочие вопросы можно задать в предварительной устной беседе по телефону или скайпу и не тратить на них время на очном собеседовании. В идеале еще до встречи с кандидатом вы должны быть уверены, что возьмете его на работу.

Сосредоточьтесь на профессиональных технических вопросах по теме PHP. Например, «Какой способ проверки существования данных наиболее быстрый» или попросите предложить решение конкретной задачи и т.п. Это поможет выявить истинный уровень кандидата и степень его соответствия вашей должности.

2. Дайте PHP-разработчику тестовое задание

По резюме не определить, как человек справляется с задачами. Для этого существует тестовое задание. Чтобы не отпугнуть кандидата, сделайте его небольшим (время выполнения: 15 минут – 4 часа), но емким. Это поможет увидеть соискателя в работе, оценить качество конечного продукта и степень креативности подхода.

Тестовое задание для PHP Backend Developer и Frontend разработчика дается после ознакомления с резюме, на предварительной беседе или после очной консультации.

3. Отдавайте предпочтение резюме PHP-программистов с нужными вам качествами

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

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

А при очном интервью задайте кандидату 5-6 таких вопросов, чтобы убедиться, что он действительно вам подходит. Помните, неэффективный работник может навредить проекту.

4. Объедините 3 уровня собеседования в 1

В хорошей компании собеседование разработчиков проходит в 3 этапа – через HR-ра, технического специалиста и руководителя. Многие это знают, но применяют правильно не все. И зачастую соискателю приходится 3-4 раза приезжать на собеседование в одну и ту же компанию.

По возможности соберите на консультацию всех 3-х представителей организации. Это поможет оптимально использовать ваши собственные ресурсы и не отпугнуть соискателя многократными очными собеседованиями.

Если в организации существует отдел разработки, то роль HR и технического специалиста может выполнить его руководитель. Инженер программиста PHP и без резюме поймет с полуслова, раскроет его лучше всяких психологических тестов.

5. Указывайте в вакансии реальные версии софта

«PHP 7.1» выглядит гораздо более информативно, чем «PHP 5-7». Хороший такой разбег в последнем случае соберет программистов всех мастей, но вам-то нужна одна.

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

Желаем вам не ошибаться в выборе кандидатов.

Просмотреть резюме Frontend разработчиков и PHP-программистов других направлений можно на нашем сайте.

Видеокурс «PHP-Мастер. От теории до собственной CMS интернет-магазина»

Презентация видеокурса «PHP-Мастер» Андрея Кудлая 20 мин. 25 сек.

  • О видеокурсе
  • Программа курса
  • Особенности

Андрей Кудлай подготовил базовый видеокурс для начинающих верстальщиков, в котором вы узнаете все о языке PhP и научитесь разрабатывать на нем сайты и приложения. Это последовательность уроков, где теория тесно переплетается с практическими занятиями. Подробно описана подготовка и внедрение программных кодов и работа PhP в паре с MySQL.

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

PHP-Мастер. От теории до собственной CMS интернет-магазина

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

В видеокурсе вас ждут уроки:

  • Разработка административной и пользовательской части онлайн-магазина;
  • Реализация личного кабинета посетителя;
  • Подготовка собственной платформы;
  • Подключение нескольких систем платежей;
  • Свыше 30 часов полезного практического видеоконтента.

Изучив видеокурс образовательного проекта Webformyself «PHP-мастер», вы получите исчерпывающие ответы, описывающие всю суть верстки на современных версиях РНР и MySQL, включая ООП. С азов подготовите платформу на основе собственной CMS и сможете зарабатывать на своих знаниях во фрилансе.

Правила освоения PHP новичкам

Давно хотел написать эту статью, поскольку я уже не первый год обучаю PHP начинающих, и давно заметил, что многие делают это неправильно, порой с целым рядом ошибок. Это крайне сильно затрудняет их обучение. А те, кто незнаком с программированием вовсе, в большинстве случаев забрасывают это, думая, что им это не под силу. В связи с этими возникающими проблемами, я и решил написать статью, в которой просто и понятно перечислю все пункты правил освоения PHP для новичков.

Всего будет несколько пунктов, и нарушение каждого из них я регулярно наблюдаю в своей практике:

  1. Не стараться сразу писать сложные проекты и скрипты. Очень часто человек, который ещё даже не знает условного оператора, уже пытается создать социальную сеть. Никаких сложных проектов. Начинать надо с элементарного, затем с очень простого, с простого, после с несложного и так далее. А социальная сеть — это уже достаточно сложный проект, который требует больших знаний в области PHP и MySQL. В своё время я сам себе придумывал задачи и решал их, также нужно поступать и Вам, но делать при этом только то, что Вам сейчас по зубам.
  2. Не используйте готовые скрипты. Я вообще противник готовых скриптов, поскольку там всегда много лишних возможностей, а это уже «свалка«. Но для новичков готовые скрипты просто губительны. Если Вам нужна какая-то гостевая книга, опрос на сайте, поиск по сайту, то пишите это самостоятельно. Безусловно, подобных готовых скриптов тысячи, но даже не смотрите на них. Самый крайний вариант — это просто посмотреть, как он устроен, но писать Вы должны сами и с нуля. Иначе Вы не будете развиваться, и смысла такого программирования нет.
  3. Не бросать освоение PHP на полпути. У многих новичков возникает желание (порой, «с оправданием») отложить изучение на некоторое время. Делать этого нельзя, поскольку примерно за неделю отсутствия практики, Вы откатитесь очень сильно. Я программирую уже много лет, и то, если я давно не работал с каким-то языком, то постепенно его забываю. Но с опытом Вас будет спасать то, что Вы моментально будете вспоминать, стоит Вам только заглянуть в справочник. Новичкам, увы, придётся начинать практически всё сначала.
  4. Не надо просить кого-то что-то Вам написать. Очень часто на форуме новички просят «напишите мне то, напишите мне это«. Хорошо, если его отправят учиться, но бывают и окажут медвежью услугу. Всё, с чем Вам могут помочь — это с алгоритмом. А вот как его реализовать, это Вы обязаны сделать самостоятельно, а постепенно должны сами учиться составлять алгоритмы.

Возможно, есть ещё какие-то правила освоения PHP новичкам, я написал только те, с которыми постоянно вижусь. Но даже если Вы будете соблюдать только эти правила, то уже Ваше обучение будет значительно проще. Добавлю лишь, что это касается абсолютно любого языка программирования, поэтому если Вы вдруг изучаете какой-то другой язык, то там абсолютно те же правила.

Копирование материалов разрешается только с указанием автора (Михаил Русаков) и индексируемой прямой ссылкой на сайт (http://myrusakov.ru)!


Добавляйтесь ко мне в друзья ВКонтакте: http://vk.com/myrusakov.
Если Вы хотите дать оценку мне и моей работе, то напишите её в моей группе: http://vk.com/rusakovmy.

Если Вы не хотите пропустить новые материалы на сайте,
то Вы можете подписаться на обновления: Подписаться на обновления

Если у Вас остались какие-либо вопросы, либо у Вас есть желание высказаться по поводу этой статьи, то Вы можете оставить свой комментарий внизу страницы.

Порекомендуйте эту статью друзьям:

Если Вам понравился сайт, то разместите ссылку на него (у себя на сайте, на форуме, в контакте):

Она выглядит вот так:

  • BB-код ссылки для форумов (например, можете поставить её в подписи):
  • Комментарии ( 7 ):

    Я думаю, что эту статью нужно переместить на 1 или 2 место! Она сейчас на 141 месте и думаю тем, кто будет как я проходить все статьи с первой до последней она уже не будет полезна!

    Можно ли создать сайт на каком-то сайте, а потом пробрести хостинг, домен и зарабатывать на сайте приличные деньги?

    Для сайта уже понадобиться хостинг в любом случае.

    Спасибо! Хорошая статья, буду стараться придерживаться этих правил!

    «Начинать надо с элементарного, затем с очень простого, с простого, после с несложного и так далее.» Вот это я понимаю. Но пока не совсем понимаю что именно отнести к каждой категории. Чтоб это были не упражнения, а именно какой-то законченный проект пусть и совсем маленький, чтоб был азарт получить результат, который можно хотя бы для себя потом применить. Элементарное — это, например, что? Очень простое — что сюда можно отнести? Простое — что сюда входит? Несложное — а сюда? Приведите, пожалуйста, несколько примеров из каждой категории сложности? Просто есть проект на Joomla+SMF его надо будет переписывать с нуля под себя, но специфика требований такая, что я понимаю, что он относится к разделу сложных, как минимум. И чтоб не наделать лишних ляпов, да и потренироваться надо попрактиковаться. Но не могу сообразить что отнести к каждой категории, чтоб опыт накапливался постепенно накладываясь на уже закрепленное, а не раздирал мозг из серии «как бы все это сразу запомнить и ничего не забыть».

    Честно говоря, с 4 пунктом не совсем согласен. Лучше попросить умных людей помочь с реализацией (какие-то тонкости или более современные подходы в разработке подсказать), но алгоритм надо разрабатывать самому с нуля, всегда. Только тогда будет рост и развитие в качестве программиста.

    Я придумываю алгоритмы и сам реализовываю их. Так же не использую готовые скрипты. К тому же нету охоты бросать учёбу и пишу скрипты по нарастающей цепочке.

    Для добавления комментариев надо войти в систему.
    Если Вы ещё не зарегистрированы на сайте, то сначала зарегистрируйтесь.

    Copyright © 2010-2020 Русаков Михаил Юрьевич. Все права защищены.

    hipot

    hipot srew

    Последний раз редактировалось:
    25.11.2010 13:00 (вер.1.06)

    Стандарт написания кода — это очень важно

    Опыт многих проектов показывает, что при использовании стандартов кодирования управление и разработка идет легко и гладко. Но достаточно ли стандарта для успешного проекта? Конечно, нет, но они помогают. А мы должны использовать все инструменты, которые упрощают нам жизнь! Поверьте, многие протесты против стандарта кодирования исходят из чьего-то ущемленного самолюбия. Но для того, чтобы следовать стандартам необходимо минимальное усилие над собой, а также необходимо помнить, что любой проект — это коллективная работа.

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

    Содержание

    Отступы

    Использовать tab вместо пробелов, т.к. обычно редактор настраивается, сколько пробелов проставлять за tab. Делаем отступов столько, сколько необходимо, но не больше. Существует правило о максимуме числа отступов. Если вложенность в коде больше, чем 4 или 5 уровней, то следует задуматься о переработке такого кода. Конечно, это рекомендация, в реальной жизни уменьшить число вложений до 5ти не всегда возможно, поэтому будем надеяться на мудрость программиста при написании кода.

    #2. Соглашения по именованию

    Хорошее именование в коде имеет определяющее значение при отладке, поиске ошибок и дальнейшей работе с кодом.

    Имена файлов

    1. Для файлов допустимы буквенно-числовые символы (нижнего регистра), символы нижнего подчеркивания и тире («-»). Пробелы запрещены. Необходимость верхнего регистра обсуждается в частных случаях.
    2. Если файл содержит любой php-код, то он должен заканчиваться «.php»

    Классы

    1. Желательно использовать namespace-нотацию
    2. Имена классов могут содержать только буквенно-числовые символы. Числа допустимы в именах классов, но не приветствуются. Символы нижнего подчеркивания допустимы в местах разделителей пути — напр. желательно, чтобы имя файла « ClassLib/Db/Table.php » указывало на класс с именем « ClassLib_Db_Table » (namespace-нотация).
    3. Если имя класса состоит из более, чем одного слова, то первая буква каждого слова должна быть заглавной. Последующие заглавные буквы недопустимы, например, имя класса « WorkPDF » — недопустимо, в то время как имя « WorkPdf » допустимо.
    4. Разъяснение 3): столкнувшись с ситуацией, когда необходимо использовать все верхние буквы аббревиатуры в названии, пишем первую прописную, а остальные строчные. Обоснование: Возьмем, к примеру, NetworkABCKey . Обратите внимание, как легко можно неверно понять аббревиатуру ABCK , и не заметить сразу, что далее идет Key . В данном случае, верно назвать NetworkAbcKey . Например: Используем HtmlStatistic вместо HTMLStatistic .

    Интерфейсы (пока бог нас от них уберег, однако:)

    1. Интерфейсы должны следовать той же схеме именования, как и классы (смотрите выше), однако их имя должно заканчиваться словом « Interface », как в следующих примерах: WorkPdf_Interface , ControllerDispatcher_Interface

    Именование функций и методов

    1. Имена функций могут содержать буквенно-числовые символы. Символы нижнего подчеркивания не разрешены. Числа разрешены в именах функций, но не приветствуются.
    2. Имена функций должны всегда начинаться с буквы в верхнем регистре. Когда имя функции состоит из более, чем одного слова, первая буква каждого нового слова должна быть заглавной. Это обычно называется «верблюжьей» («СamelCase») нотацией. Обычно, метод или функция выполняют какое-либо действие, поэтому имя такого метода или функции должно указывать на это действие: CheckForErrors() вместо ErrorCheck() , DumpDataToFile() вместо DataFile() .
    3. Многословность приветствуется. Имена функций должны быть настолько говорящими, насколько это практично для повышения понимаемости кода.
    4. Если необходимо в функции что-то выяснить, то удачно дать ей имя с префиксом Is . Напр. IsAuthorized()
    5. Для объектно-ориентированного программирования принято, чтобы методы доступа имели префикс « Get » или « Set » (если необходимо что-либо вернуть, либо установить)
    6. Функции в глобальной области видимости («плавающие функции») допустимы, но не приветствуются. Рекомендуется обрамлять такие функции в статические классы. Написание статических методов формирует библиотеку классов, которую можно будет повторно использовать.
    7. Если функция является рекурсивной, то у нее должен быть суффикс « _r » (напр. WalkBsp_r() )

    Именование методов в классах

    1. Имена методов, в отличие от функций, могут начинаться с буквы в нижнем регистре. Когда имя метода состоит из более, чем одного слова, первая буква каждого нового слова должна быть заглавной. Это обычно называется «верблюжьей» нотацией.
    2. Для методов, объявленных как private или protected первый символ должен быть нижним подчеркиванием.

    Именование переменных

    1. Имена переменных могут содержать буквенно-числовые символы. Символы нижнего подчеркивания не разрешены (см. п.5). Числа разрешены в именах переменных, но не приветствуются
    2. Как и имена функций (смотрите выше) имена переменных должны начинаться с буквы в нижнем регистре и следовать «верблюжьей» нотации.
    3. Для переменных — членов классов, определенных с помощью префиксов области видимости « private » или « protected », первый символ имени должен быть один символ нижнего подчеркивания. Это единственное допустимое использование символа нижнего подчеркивания в имени. Переменные — члены классов определенные с помощью префикса области видимости « public » никогда не должны начинаться с символа нижнего подчеркивания.
    4. Многословность приветствуется. Имена переменных должны быть настолько говорящими, насколько это практично. Краткие имена переменных, такие как « $i » и « $n » не приветствуются нигде, кроме как в контексте маленьких циклов. Если цикл содержит более 20 строк кода, то переменные для индексов должны иметь более говорящие имена.
    5. Имена переменных, содержащие только нижний регистр и знак подчеркивания, разрешается использовать только в локальных частях кода, содержащего не более 20 строк. В противном случае переменной необходимо давать осмысленное название.
    6. Встроенные переменные PHP true , false и null должны быть написаны в нижнем регистре.
    7. Использование говорящих префиксов/суффиксов — это хорошо: Например, Max — обозначает, что переменная хранит какой-либо максимум, Cnt, Count — обозначает, что переменная хранит кол-во чего-либо. Например: $itemsMax — максимальное значение в массиве; $dateOfSomething — дата какого-либо события; $useHtml, $isHtml — для флагов.

    Префиксы имен переменных для удобочитаемости

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

    1. ’ ar ’ — Массивы
    2. ’ ob ’, ’ o ’ — Объекты
    3. ’ b ’ — тип boolen
    4. ’ g ’ — глобальные переменные
    5. ’ db ’ — дескриптор результата БД (напр. при возврате в bitrix объекта CDBResult )
    6. ’ res ’, ’ rs ’ — ресурс (напр. дескриптор открытого файла)
    7. ’ r ’ — для параметров функции, используемых как ссылка (см. пример). Тогда при написании кода в функции мы наглядно знаем, меняет ли функция переданную переменную.

    Константы

    1. Константы могут содержать буквенно-числовые символы и символы нижнего подчеркивания. Числа разрешены в именах констант.
    2. Имена констант должны быть в верхнем регистре.
    3. Имена констант из нескольких слов пишутся, разделяя каждое слово знаком подчеркивания (напр. EMBED_SURPRESS )
    4. Константы должны быть определены как члены классов с использованием ключевого слова « const ». Определение констант в глобальной области видимости с помощью « define » допустимо, но не рекомендуется:

    #3. Стиль кодирования

    Строковые литералы

    1. Когда строка является литеральной (не содержит подстановок переменных), для ее обрамления должны использоваться апострофы или «одинарные кавычки» ( $a = ‘Example String’; )
    2. Когда строка литералов сама содержит апострофы, разрешается для обрамления строки использовать «двойные кавычки». Это особенно актуально для SQL-запросов:

    Конкатенация строк

    1. Строки должны объединятся с помощью оператора « . ». Пробел должен всегда добавляться до и после оператора « . » для улучшения читабельности: ( $company = ‘Zend’ . ‘Technologies’; )
    2. Когда производится конкатенация строк с помощью оператора « . », разрешается разрывать выражение на несколько строк для улучшения читабельности. В этом случае, каждая следующая строка должна быть дополнена пробелами так, чтобы оператор « . » был выровнен под оператором « = »:

    Массивы с числовыми индексами

    1. Хотя индекс массива может начинаться с отрицательного числа, но это не приветствуется и рекомендуется, чтобы все массивы начинали индексирование с 0 .
    2. Когда определяется индексированный массив с помощью конструкции array , завершающий пробел должен быть добавлен после каждой запятой для улучшения читабельности:
    3. Также разрешается определять многострочные индексированные массивы, используя конструкцию « array ». В этом случае, каждая следующая строка должна быть дополнена пробелами так, чтобы начало каждой строки было выравнено как показано ниже:

    Ассоциативные массивы

    1. Когда определяется ассоциативный массив с помощью конструкции « array », приветствуется разделение выражения на несколько строк. В этом случае, каждая следующая строка должна быть дополнена с помощью пробелов так, чтобы и ключи и значения были выровнены:

    Определение класса

    Классы должны определяться по следующей схеме:

    1. Фигурная скобка всегда пишется на следующей строке под именем класса.
    2. Каждый класс должен иметь блок документации (doc-блок) в соответствии со стандартом PHPDocumentor.
    3. Код внутри класса должен иметь отступ.
    4. Только один класс разрешен внутри одного PHP-файла. Размещение дополнительно кода в файле с классом разрешено, но не приветствуется. В таких файлах, две пустые строки должны разделять класс и дополнительный PHP-код.


    Пример:

    Переменные-члены классов

    Переменные-члены классов должны определяться по следующей схеме:

    1. Имена переменных-членов класса могут именоваться, как обычные переменные (см. именование переменных выше)
    2. Любые переменные, определенные в классе, должны быть определены в начале класса, до определения любого метода.
    3. Ключевое слово var не рекомендуется. Желательно всегда определять область видимости членов, используя ключевое слово private , protected или public .
    4. Доступ к переменным-членам класса напрямую используя префикс public разрешено, но не приветствуется в пользу методов доступа ( set/get )

    Определение функций и методов

    Функции должны определяться по следующей схеме:

    1. Функции должны именоваться согласно правилам именования (см. раздел именование функций и методов)
    2. Функции внутри классов должны всегда определять свою область видимости с помощью одного из префиксов private , protected или public .
    3. Как и у классов, фигурная скобка всегда пишется на следующей строке под именем функции. Пробелы между именем функции и круглой скобкой для аргументов отсутствуют. («one true brace» форма)
    4. Функции в глобальной области видимости крайне не приветствуются.
    5. Аргументы функций со значениями по умолчанию должны находиться в конце списка аргументов.
    6. Передача по ссылке во время вызова запрещена. Передача по ссылке допустима только в определениях функций:
    7. Возвращаемое значение не должно обрамляться в круглые скобки, иначе это ухудшает читабельность, а также может поломать код, если метод позже станет возвращать результат по ссылке.

    Использование функций и методов

    Функции должны определяться по следующей схеме:

    1. Аргументы функции разделяются одним завершающим пробелом после каждой запятой.
    2. Вызовы функций должны быть написаны без отступов между именем функции, открывающей скобкой и первым параметром. Отступы в виде пробела должны присутствовать после каждой запятой в перечислении параметров ( $var = foo($bar, $baz, $quux); )
    3. Передача по ссылке во время вызова запрещена. Смотрите секцию определения функций для правильного способа передачи аргументов функции по ссылке.
    4. Для функций, чьи аргументы допускают массив, вызов функции может включать конструкцию « array » и может быть разделено на несколько строк для улучшения читабельности. В этом случае, применим стандарт описания массивов:

    Управляющие структуры и простановка скобок

    Управляющие структуры включают в себя операторы if , for , while , switch , и др. Ниже приведен пример оформления оператора if , который в этом отношении является самым сложным. Его и рассмотрим, другие пишутся по аналогии. Этот стиль называется «trailing braces», его использовать во всех управляющих конструкциях. Стиль «one true brace» (каждая скобка на новой строке) остается в черном списке, пользоваться им вне декларации классов и функций ПОКА можно, но строго не рекомендуется (см. правила определения функций и методов и правило определения классов).

    1. Управляющие структуры, основанные на конструкциях if и elseif , должны иметь один пробел до открывающей круглой скобки условия, и один пробел после закрывающей круглой скобки.
    2. Внутри выражения условия между круглыми скобками операторы должны разделяться пробелами для читабельности. Внутренние скобки приветствуются для улучшения логической группировки больших условий.
    3. Открывающаяся фигурная скобка пишется на той же строке, что и условие. Закрывающаяся фигурная скобка пишется на отдельной строке. Все содержимое между скобками пишется с отступом в четыре пробела (или один tab).
    4. Для выражения if , включая elseif или else , форматирование должно быть таким, как в следующем примере:
    5. Ключевые слова должны быть строго в нижнем регистре: array, if, foreach, while, true, false, null, new, class, function, .

    PHP допускает написание таких выражений без фигурных скобок при некоторых условиях. Стандарт кодирования не делает различий — для всех if , elseif или else выражений необходимо использовать фигурные скобки. Настойчиво рекомендуется использовать фигурные скобки, даже в том случае, когда их использование не является необходимостью. Использование фигурных скобок увеличивает читабельность кода и уменьшает вероятность логических ошибок при изменении кода.

    Использование комбинации « else if » вместо конструкции elseif допускается.

    Альтернативный синтаксис рекомендуется использовать только в частях, которые используют прерывания на вывод html-кусков (напр. для шаблонов вывода). Просто в отформатированном PHP-коде строго не рекомендуется использовать альтернативный синтаксис, т.к. теряется учет открытых-закрытых скобок (к тому же многие среды разработки позволяют легко найти открывающуюся скобку по закрытой, но не позволяют найти начало if (…): по его окончанию — endif; ). Пример:

    Правила написания switch-конструкции

    1. Управляющие структуры написанные с использованием « switch » конструкции должны иметь один пробел до открывающей круглой скобки условного выражения, и также один пробел после закрывающей круглой скобки.
    2. Все содержимое между фигурными скобками пишется с отступом. Содержимое каждого « case » выражения также должно писаться с отступом
    3. Ключевое слово default никогда не должно опускаться в выражении switch .
    4. ЗАМЕЧАНИЕ: Иногда полезно писать case-выражения, которые передают управление следующему case-выражению, опуская break или return . Для того, чтобы отличать такие случаи от ошибок, каждое case-выражение, где опущен break или return , должно содержать комментарий (напр. « // break intentionally omitted »).

    Тернарный оператор ’?:’

    Проблема обычно заключается в том, что люди пытаются запихать слишком много кода между «?» и » :» . Вот несколько правил:

    1. Условие заключайте в скобки, тем самым отделяя его от остального кода
    2. По возможности действия, производимые по условию, должны быть простыми функциями
    3. Если весь блок ветвления плохо читается, будучи расположен на одной строке, то блоки else размещайте каждый на отдельной строке

    Использование коротких тегов ’ short_open_tag конфигурационного файла php.ini. Для вывода в шаблоне одной переменной или результата выражения удобно пользоваться записью ’ ’ вместо ’ ’. Для длинных выражений (более одного тернарного оператора) использование такой записи практически не оправдано. Пример:

    Пробелы вокруг знаков операций

    Любые операторы / знаки операций (например =, ==, =>, >, и т.п.) обязательно отделяются пробелами с обоих сторон. В арифметических выражениях количество пробелов вокруг знаков операций можно варьировать, чтобы подчеркнуть приоритет операций. Примеры:

    Пробелы вокруг сложных индексных выражений

    В случае, если Вы обращаетесь к элементу массива по индексу и индексное выражение достаточно сложное, отделяйте его пробелами для улучшения удобочитаемости. Если выражение простое — пробелы не обязательны.

    Декларативный блок желательно выравнивать по правому краю

    Данный подход упрощает читаемость и понятность кода. Используем пробелы после знака присвоения для этих целей.

    Каждый оператор должен быть на новой строке

    Необходимо, чтобы в каждой строчке присутствовало только одно выражение.

    Напр. допустимо: Не допустимо:

    Всегда документировать пустое выражение

    Пустые строки для дробления кода на логические блоки

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

    Перед логической секцией рекомендуется вставить комментарий, в котором будет указано назначение этой секции. Удобно в этом случае пользоваться тегом @todo из стандарта PHPDocumentor’a: (см. раздел «Встроенная документация»)

    Подключение файлов: include или require?

    В тех местах, где вы используете подключение файлов других классов вне зависимости от условий, используйте конструкцию require_once() . Если же подключение файлов зависит от каких-либо условий, то следует использовать include_once() . В этом случае вы всегда будете уверены в том, что файлы подключаются только единожды. include_once() и require_once() и являются конструкциями, а не функциями. Вам не обязательно использовать скобки вокруг имени файла, который подключается. Использование include() и require() не рекомендуется.

    Встроенная документация и комментарии

    Комментарии внутри кода классов должны соответствовать синтаксису комментариев PHPDoc, который напоминает Javadoc. За дополнительной информацией о PHPDoc обращайтесь сюда: http://www.phpdoc.org/

    К примеру, редактор Zend 5.51/8.0 очень хорошо работает с подобной документацией, следует впереди определения функции или класса набрать ’ /** ’ и нажать Enter .

    Дополнительные комментарии, кроме тех, что предусмотрены PHPDoc, только приветствуются. Основное правило в данном случае — каждая часть кода повышенной сложности должна быть прокомментирована до того, как вы забыли, как она работает.

    Подходят комментарии в стилях C ( /**/ ) и C++ ( // ). Использование комментариев в стиле Perl/shell ( # ) не рекомендуется.

    1. Все блоки документации («docblocks») должны быть совместимы с форматом phpDocumentor. Описание формата phpDocumentor вне рамок данного докумета. Для дополнительно информации смотрите: http://www.phpdoc.org/
    2. Всем файлам с исходными кодами, рекомендуется содержать «файловые» doc-блоки в начале каждого файла и обязательно наличие «классового» doc-блок непосредственно перед каждым классом. Ниже даны примеры таких doc-блоков.

    Встроенная документация — Файлы

    В каждый файл, содержащий PHP-код, желательно размещать заголовочный блок в начале файла, содержащий как минимум следующие phpDocumentor-теги:

    Встроенная документация — Классы

    Аналогично файлам, однако для класса обязательно: каждый класс должен иметь doc-блок, содержащий как минимум следующие phpDocumentor-теги: @copyright , @version , @link

    Встроенная документация — Функции

    Для функций и методов документация в виде phpDocumentator обязательна. Каждая функция, включая методы объектов, должна иметь doc-блок, содержащий как минимум:

    1. Описание функции
    2. Все аргументы
    3. Все возможные возвращаемые значения
    4. Нет надобности использовать тег « @access », потому что область видимости уже известна из ключевых слов « public », « private » или « protected ». используемых при определении функции.
    5. Если функция/метод может выбрасывать исключение, используйте тег @throw

    #4. Дополнительные частные случаи, на которые следует обратить внимание

    Не следует делать реальную работу в конструкторе

    Напр. если мы хотим открыть соединение c БД, то делаем метод Open(), в котором и совершаем открытие. Причина: конструктор не может вернуть значение (напр. ошибку).

    Короткие методы

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

    Рефакторинг

    Не живите с «разбитыми окнами»!

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

    Старайтесь повторно использовать свой и чужой труд

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

    Do not Repeat Youself — не повторяй самого себя!

    Подумайте о повторном использовании кода. Зачем тратить впустую усилия мысли на одноразовые программы, если в будущем вам может потребоваться что-то подобное снова? Подумайте над обобщением вашего кода. Подумайте над написанием модуля или класса. Подумайте, не предложить ли Ваш код другим.

    Don’t Reinvent Wheel — Не переизобретайте колесо!

    Не переизобретайте колесо — если подобное колесо уже существует, просто адаптируйте его для своих нужд. Вероятно, для решения данной проблемы уже существует стандартный модуль в ядре PHP или API CMS, или модуль, разработанный другими людьми внутри организации. Иногда не составляет труда найти нужный код в интернете.

    Куски кода и ответственность

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

    WebForMyself [WebForMySelf] PHP-Мастер. От теории до собственной CMS интернет-магазина (Андрей Кудлай)

    Bekapon

    Bekapon

    Основная часть курса включает 85 уроков общей продолжительностью почти 30 часов:

    • Часть 1. Написание собственного фреймворка
    • Часть 2. Написание пользовательской части CMS интернет-магазина
    • Часть 3. Написание администраторской части CMS интернет-магазина

    Бонусный блок курса состоит из 6 абсолютно новых актуальных видеокурсов и серий уроков, созданных с полного нуля и нигде не встречавшихся до этого:

    • Бонус 1. Премиум курс по PHP+PHP 7 и MySQL
    • Бонус 2. Премиум курс по ООП PHP
    • Бонус 3. Перенос сайта на хостинг
    • Бонус 4. Подключение платежной системы
    • Бонус 5. Личный кабинет покупателя
    • Бонус 6. Канонические URL

    При этом первых два бонуса являются фундаментальными, новаторскими и исчерпывающими по своему объему, содержанию и структуре видеокурсами, раскрывающих всю суть программирования на актуальных версиях РНР и MySQL, включая основы объектно-ориентированного программирования.

    Даже самый «зеленый» новичок сможет разобраться с курсом и освоить веб-программирование на PHP и MySQL. Все необходимые для этого дополнительные курсы входят бонусами к основному курсу. Поэтому новичкам прямая дорога к бонусной части!

    Правила хорошего тона при объединении php и html кода

    Поставьте оценку
    05.06.2012, 17:10

    Оптимизация кода и правила хорошего тона
    Доброе утро! Изучаю php и сразу пытаюсь делать все грамотно и не плодить лишнего. Так вот.

    Сохранение HTML кода в html файл c использыванием php
    Я создавал регистрацию на php+html+css . Сделал форму (она под спойлером )

    Правила хорошего тона при инициализации компонентов
    Допустим есть форма и я хочу выполнить некоторые действия над группой компонентов в отдельном.

    Правила хорошего тона?
    У меня есть много окон. Экземпляры моделей для них я храню в самом App. Пример: public partial.

    Правила хорошего тона в программировании в VB (+++)
    Господа программисты, давайте обсудим правила хорошего тона программирование в VB. Например у меня.

    Что нужно знать и уметь, чтобы работать PHP-разработчиком

    Первое, с чем сталкивается начинающий — это стереотип о низком качестве языка, написанных на нём программ и самих программистов. Однако если взглянуть на статистику за 2020 год, мы увидим, что PHP регулярно попадает в популярных языков.

    Язык развивается. Появляются новые инструменты и стандарты, с которыми PHP-разработчики создают элегантные, быстрые и надёжные системы. Число проектов растёт, а вместе с ними растёт и потребность в профессионалах. Ниже мы собрали знания, которые помогут разработчику писать красивый и эффективный код и не отставать от мейнстрима.

    PHP для начинающих

    С чего же начать учить PHP? Для новичков отлично подойдут следующие ресурсы с основами:

    • владеть английским на уровне чтения;
    • знать возможности PHP 7;
    • иметь навыки HTML/CSS хотя бы на базовом уровне. Помогут разобраться: справочник по HTML, справочник по CSS;
    • следовать стандартам и оформлению кода (, ). Поможет разобраться: PHP Standarts Recommendation;
    • иметь опыт работы с системой контроля версий Git и знать GitFlow: Помогут разобраться: Pro Git Скотта Чакона и Бена Страуба, Git Flow, статья «Удачная модель ветвления» на «Хабре»;
    • уметь работать с менеджером зависимостей Composer. Поможет разобраться: getcomposer;
    • понимать принципы работы протокола HTTP(S);
    • иметь опыт работы с Linux через консоль;
    • уметь настраивать (Nginx, Apache);
    • знать Docker и Vagrant. Помогут разобраться: статья «Полное практическое руководство по Docker: с нуля до кластера на AWS» на «Хабре»;
    • иметь опыт работы с (Yii, Laravel, Symfony, Slim Framework);
    • иметь опыт работы с инструментами развертывания. Помогут разобраться: проект Deployer и введение в работу с ним на «Хабре»;
    • иметь опыт работы с RDBMS/NoSQL (MySQL, PostgreSQL, MongoDB, Redis);
    • иметь представление о работе с очередями (Redis, RabbitMQ ). Помогут разобраться: Очереди сообщений на RuHigload, «Сервер очередей» на «Хабре»;
    • уметь организовывать обработку задач в фоновом режиме (supervisord, cron, systemd );
    • уметь работать с кэшем;
    • иметь опыт проектирования REST API. Помогут разобраться: статья «Разработка web API» и «Архитектура REST» на «Хабре»;
    • уметь документировать API (API Blueprint, Swagger);
    • знать SemVer;
    • уметь ООП;
    • понимать и грамотно применять принципы SOLID. Помогут разобраться: статья «Шпаргалка по с примерами на PHP» и SOLID на Хабре, статья From stupid to SOLID code;
    • понимать и грамотно применять принципы GRASP. Помогут разобраться: ООП для ООП: GRASP;
    • иметь представление о других общих принципах: CQS, DRY, YAGNI, KISS и так далее. Помогут разобраться: This is not the DRY you are looking for, «Три ключевых принципа ПО, которые вы должны понимать» на «Хабре», separation;
    • понимать механизм Dependency Injection и иметь опыт работы с Dependency Injection Container. Помогут разобраться: «Инверсии зависимостей управления впрыском» на «Хабре»;
    • понимать MVC и иметь представление о других архитектурах UI. Помогут разобраться: «Шпаргалка по для проектирования » на «Хабре»;
    • иметь представление о Hexagonal/Onion Architecture, CQRS. Помогут разобраться: «Чистая архитектура», «Гексагональная архитектура» и «Основы CQRS» на «Хабре»;
    • понимать и грамотно применять паттерны GoF (Adapter, Decorator, Visitor, Composite ). Помогут разобраться: «Шпаргалка по шаблонам проектирования» на «Хабре», Design patterns for humans;
    • понимать и грамотно применять Patterns of Enterprise Application Architecture (ActiveRecord, DataMapper, UnitOfWork, Repository, ValueObject, Domain Model );
    • знать что такое refactoring и уметь применять его;
    • поддерживать чистоту в коде и понимать, зачем это нужно. Поможет разобраться: «Чистый код»;
    • уметь разбираться в чужом коде и облагораживать его;
    • знать свои инструменты и уметь самостоятельно в них разбираться;
    • уметь находить простые и оптимальные решения сложных задач.

    С чего может начать новичок:

    Курсы, блоги и статьи про web, ООП и разработку в целом:

    Литература для изучения

    Наша команда собрала лучшие книги по PHP-программированию для начинающих:

    Добро пожаловать

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


    Переводы

    Руководство PHP: Правильный путь уже (или вскоре будет) переведено на множество различных языков:

    Дисклеймер

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

    Это живой документ и он продолжит обновляться более полезной информацией и примерами по мере их появления.

    Как внести вклад

    Помогите сделать этот сайт лучшим ресурсом для начинающих PHP программистов! Помочь используя GitHub

    Расскажите о нас

    Руководство PHP: Правильный путь содержит веб-баннеры, которые вы можете использовать на своём сайте. Окажите поддержку, показав начинающим PHP-разработчикам где они могут найти полезную информацию!

    Начало

    Использование стабильной версии (7.2)

    Если вы только начинаете работу с PHP, убедитесь в том, что вы используете текущую стабильную версию PHP 7.2. За последние несколько лет PHP добился больших успехов, добавив новые возможности.

    Наиболее часто в ближайшем будущем вы будете видеть, что используются версии PHP 5.x, с последней 5.6. Но вы должны попробовать использовать последнюю стабильную версию, если это возможно. Не дайте скромной разнице между числами 5.2 и 5.6 ввести вас в заблуждение, эта разница представляет важные изменения. Если вам нужна функция или пример её использования, вы всегда можете найти документацию на php.net.

    Встроенный веб-сервер

    Вы можете начать изучение PHP без необходимости в установке и конфигурировании полноценного веб-сервера (необходим PHP 5.4 или новее). Для запуска сервера вам необходимо выполнить следующую команду из терминала в корневой папке веб-проекта:

    Установка на Mac

    OSX поставляется с предзапакованным PHP, но, в лучшем случае, он немного отстает от стабильной версии. Lion поставляется с PHP 5.3.6 и Mountain Lion имеет 5.3.10.

    Для обновления PHP в OSX вы можете установить его с помощью нескольких пакетных менеджеров, наиболее рекомендуемый из которых php-osx by Liip.

    Другой вариант, скомпилировать самостоятельно, в этом случае убедитесь, что у вас установлен либо Xcode, либо его аналог от Apple “CLI для Xcode”, который можно загрузить с Apple Mac Developer Center.

    В качестве полного набора «всё-в-одном», который включает PHP, веб-сервер Apache и СУБД MySQL, и всё это с хорошим управлением через GUI, попробуйте MAMP.

    Установка в Windows

    PHP для Windows можно получить несколькими путями. Вы можете загрузить установочные файлы и, до недавнего времени, вы могли использовать ‘.msi’ установщик. Начиная с PHP версии 5.3.0 установщик не поддерживается.

    Для изучения и локальной разработки вы можете использовать встроенный в PHP 5.4+ веб-сервер, о конфигурации которого можно не беспокоиться. Если вы предпочитаете сервера «всё-в-одном», которые включают в себя полноценный веб-сервер и MySQL, тогда можете воспользоваться такими инструментами, как Web Platform Installer, Zend Server CE, XAMPP или WAMP, которые помогут быстро развернуть окружение для разработки в Windows. Но, стоит сказать, что эти инструменты будут отличаться от продакшна, так что будьте осторожны и учитывайте эти различия, если вы работаете на Windows и деплоите на Linux.

    Если вам нужно запустить конечную систему на Windows, то IIS7 даст вам лучшую стабильность и производительность. Вы можете использовать phpmanager (плагин для IIS7) для легкого конфигурирования и управления PHP. IIS7 поставляется с встроенным FastCGI, вам нужно просто настроить PHP в качестве обработчика. Для получения помощи и дополнительной информации посетите iis.net.

    Vagrant

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

    Если вы разрабатываете на Windows и деплоите на Linux (или что-либо отличающееся от Windows) или разрабатываете в команде, вы должны рассмотреть возможность использования виртуальной машины. Это звучит сложно, но, используя Vagrant, вы можете установить простую виртуальную машину всего лишь в несколько шагов. Они могут быть как выполнены вручную, так и с помощью специализированного софта, например, Puppet или Chef, который автоматизирует эту задачу. Использование этого софта гарантирует использование одинаковой конфигурации для нескольких машин, что избавляет вас от необходимости поддержки сложных списков установки. Вы также можете удалить вашу машину, и пересоздать её без большого количества ручных шагов, что делает создание «свежей» виртуалки очень простым.

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

    Стандарты написания кода

    Сообщество PHP является очень большим и разнообразным, сочетая в себе бесчисленное количество библиотек, фреймворков, и различных компонентов. Для PHP разработчика это обычная практика — выбрать несколько из них и соединить в одном проекте. Очень важно придерживаться общих стандартов написания кода (так точно, насколько это возможно) в своём PHP коде, чтобы позволить разработчикам сочетать и использовать различные библиотеки для своих проектов.

    Группа Совместимости Фреймворков предложила и одобрила ряд стилевых рекомендаций, известных как PSR-0, PSR-1 и PSR-2. Не дайте веселым именам смутить вас, эти рекомендации представляют собой набор правил, которых начинают придерживаться такие проекты, как Drupal, Zend, Symfony, CakePHP, phpBB, AWS SDK, FuelPHP, Lithium и другие. Вы можете использовать их при работе над собственным проектом, или в дальнейшем использовать ваш собственный стиль.

    В идеале, вы должны писать PHP код, придерживаясь известных стандартов. Это может быть любая комбинация PSR-ов, или один из стандартов кода, сделанных PEAR или Zend. Это позволит другим разработчикам легко читать и работать с вашим кодом, и приложения, которые используют компоненты, смогут сохранить структуру приложения, даже работая с огромным количеством стороннего кода.

    Вы можете использовать PHP_CodeSniffer чтобы проверить код на соответствие одной из этих рекомендаций, а также плагин для текстовых редакторов, таких как, к примеру, Sublime Text 2 чтобы получить отчёт в реальном времени.

    Используйте PHP Coding Standards Fixer, созданный Фабиеном Потенсьером, для автоматического исправления синтаксиса вашего кода так, чтобы он соответствовал этим стандартам, что спасет вас от исправления каждой проблемы вручную.

    Английский язык является наиболее предпочтительным для всех символических имен и инфраструктуры кода. Комментарии могут быть написаны на любом языке, который будет легко читаем текущими и будущими разработчиками, которым предстоит работать над кодом.

    Основные моменты языка

    Парадигмы программирования

    PHP представляет собой гибкий, динамичный язык, который поддерживает несколько техник программирования. Он значительно развился в течение последних нескольких лет: добавлена мощная объектно-ориентированная модель в PHP 5.0 (2004), анонимные функции (замыкания) и пространства имен в PHP 5.3 (2009), а также трейты в PHP 5.4 (2012).

    Объектно-ориентированное программирование

    PHP реализует очень большой набор особенностей объектно-ориентированного программирования, включая поддержку классов, абстрактных классов, интерфейсов, наследования, конструкторов, клонирования, исключений и т.д.

    Функциональное программирование

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

    Рекурсия — это особенность, которая позволяет функции вызывать саму себя, это поддерживается языком, но бо́льшая часть кода PHP фокусируется на итерации.

    Анонимные функции (замыкания) поддерживаются PHP начиная с версии 5.3 (2009).

    В PHP 5.4 добавлена возможность связывать замыкание с областью видимости объекта, а также улучшена поддержка callables (всё, что может быть вызвано), так что они могут быть использованы наравне с анонимными функциями практически во всех случаях.

    Meta Programming

    PHP поддерживает несколько форм метапрограммирования, что реализуется с помощью таких механизмов, как Reflection API и Магические Методы. Доступно много Магических Методов, например: __get() , __set() , __clone() , __toString() , __invoke() , и т.д., которые позволяют отслеживать поведение внутри класса. Разработчики Ruby часто говорят, что PHP не хватает method_missing , но он доступен, как __call() и __callStatic() .

    Пространства имен

    Как было сказано выше, сообщество PHP состоит из множества разработчиков, создающих очень много кода. Это значит, что одна библиотека PHP может иметь такое же название класса, как и другая. Когда обе библиотеки используются в одном пространстве имен, они конфликтуют и возникают проблемы.

    Пространства имен решают эту проблему. Как описано в руководстве PHP, пространства имен можно сравнить с папками операционной системы, которые являются пространствами имен файлов; два файла с одинаковым именем могут сосуществовать в разных директориях. Подобно этому, два PHP класса с одинаковым названием могут существовать в разных пространствах имен PHP.

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

    Один из рекомендуемых способов использования пространств имен описан в PSR-4, который призван обеспечить стандарты для описания файлов, классов и пространств имен, что позволяет создавать подключаемый (plug-and-play) код.

    Стандартная Библиотека PHP (SPL)

    Стандартная библиотека PHP (SPL) поставляется вместе с PHP и предоставляет набор классов и интерфейсов. Она состоит в основном из часто используемых классов структур данных (стек, очередь, куча, и т.д.), а также итераторов, которые предназначены для прохождения через эти структуры данных или ваши собственные классы, которые реализуют интерфейсы SPL.

    Интерфейс командной строки

    Главная цель, с которой был создан PHP — это разработка веб-приложений, но он также полезен при написания кода для интерфейса командной строки (CLI). PHP программы командной строки могут помочь вам автоматизировать такие общие задачи, как тестирование, развертывание и администрирование приложения.

    CLI PHP программы очень мощные, потому что вы можете использовать код вашего приложения напрямую, без нужды в создании и обеспечении безопасности веб-интерфейса (GUI) для него. Только убедитесь, что вы не используете для ваших скриптов (CLI) корень вашего веб-сервера.

    Попробуйте запустить PHP из консоли:

    Опция -i выдаст вам конфигурацию вашего PHP, подобно функции phpinfo .

    Опция -a предоставляет доступ к интерактивной оболочке, подобно ruby IRB или интерактивной оболочки python. Также существует целый ряд других полезных опций командной строки.

    Давайте напишем простую «Привет, $name» программу CLI. Чтобы это сделать, создайте файл с именем hello.php , как показано ниже.

    PHP устанавливает две специальные переменные, основанных на аргументах, с которыми запущен ваш скрипт. $argc — это переменная с числовым значением, которая содержит количество переданных аргументов, $argv — это массив, содержащий значение каждого аргумента. Первый аргумент — всегда название вашего PHP скрипта, в этом случае hello.php .

    Выражение exit() используется с ненулевым числом, чтобы дать оболочке понять, что команда не удалась. Часто используемые коды завершения можно найти здесь

    Для запуска сценария, указанного выше, наберите в командной строке:

    XDebug

    Один из самых полезных инструментов в разработке программного обеспечения — хороший отладчик. Он позволяет вам отследить исполнение вашего кода и контролировать содержимое вашего стека. XDebug — это PHP отладчик, который может использоваться различными IDE, чтобы дать вам возможность устанавливать Брейкпоинты (точки отладки кода) и контролировать стек. Он также позволяет использовать такие инструменты, как PHPUnit и KCacheGrind, для покрытия кода тестами и его профилирования.

    Если вы оказываетесь в безвыходном положении при использовании var_dump/print_r, и у вас не получается найти решение, то возможно вам поможет использование отладчика.

    Установка XDebug может оказаться сложной, но одна из самых полезных его функций это «Удаленная отладка» — если вы разрабатываете код локально и затем тестируете его в локальной машине или на другом сервере, Удаленная Отладка — это возможность, которую вы захотите сразу же включить.

    Стандартно, вы отредактируете ваш Apache VHost или .htaccess файл со следующими значениями:

    “remote_host” и “remote_port” будут указывать на ваш локальный компьютер и порт, который вы указали в вашей IDE для прослушивания. Дальше достаточно включить режим «ожидания соединений» в вашей IDE, и загрузить URL:

    Ваша IDE теперь будет перехватывать текущее состояние, позволяя вам устанавливать брейкпоинты и исследовать значения в памяти по мере выполнения скрипта.

    Менеджер зависимостей

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

    В настоящее время существует две основные системы управления пакетами для PHP — Composer и PEAR. Какая из них подходит именно вам? Ответ — обе.

    • Используйте Composer для управления зависимостями одного проекта.
    • Используйте PEAR для управления зависимостями всех проектов во всей вашей системе.

    В общем, пакеты Composer будут доступны только в проектах, для которых вы явно укажете его использование, тогда как пакеты PEAR будут доступны во всех ваших PHP проектах. PEAR, на первый взгляд, может показаться более простым подходом, но есть преимущества в использовании подхода «проект-к-проекту» для зависимостей.

    Composer и Packagist

    Composer является блестящим менеджером зависимостей для PHP. Укажите список зависимостей вашего проекта в файле composer.json и, с помощью нескольких простых команд, Composer автоматически скачает зависимости вашего проекта и установит для вас автозагрузку.

    На данный момент существует много PHP библиотек, которые совместимы с Composer, готовых для использования в вашем проекте. Список этих «пакетов» есть на Packagist, официальном репозитории для Composer-совместимых PHP библиотек.

    Как установить Composer

    Вы можете установить Composer локально (в вашей текущей рабочей директории; хотя это не рекомендуется) или глобально (например /usr/local/bin). Предположим, вы хотите установить Composer локально. Из корневой директории вашего проекта выполните:

    Это позволит загрузить файл composer.phar (бинарный PHP-архив). Вы можете запустить его, используя php для управления зависимостями вашего проекта. Обратите внимание: Если вы скачаете код напрямую в ваш интерпретатор, пожалуйста, сперва прочитайте код онлайн, для подтверждения его безопасности.

    Как установить Composer (вручную)

    Ручная установка Composer — это продвинутая техника; однако, существуют причины, по которым разработчик может предпочесть именно этот метод использованию интерактивной установки. Интерактивная установка проверяет настройки PHP, чтобы подтвердить, что:

    • Используется необходимая версия PHP
    • Файлы .phar могут быть верно выполнены
    • Определенные права на каталог достаточны
    • Не установлены конфликтные расширения
    • Установлены необходимые настройки php.ini

    В случае, если ни одно из этих условий не соблюдено, вы должны принять решение стоит ли идти на такой компромисс. Ниже описано, как установить Composer вручную:

    Путь $HOME/local/bin (или другой каталог, выбранный вами) должен находиться в вашей переменной окружения $PATH . Это позволит быть доступной команде composer .

    Если вы прочтете документацию Composer, которая гласит, что нужно запускать Composer с помощью команды php composer.phar install , вы можете заменить эту команду на:

    Как объявить и установить зависимости

    Composer продолжает следить за зависимостями вашего проекта в файле composer.json . Вы можете управлять им вручную, если вам нравится, или же использовать сам Composer. Команда php composer.phar require добавляет зависимость в проект и, если в каталоге нет файла composer.json , он будет создан. Далее мы рассмотрим пример, который добавляет Twig, как зависимость вашего проекта. Запустите это в корневой директории вашего проекта, куда вы загружали composer.phar :

    Аналогично команда php composer.phar init проведет вас через создание полного файла composer.json для вашего проекта. Есть и другой путь, когда вы создадите файл composer.json вы можете сказать Composer, чтобы он скачал все ваши зависимости в папку vendors/ . Это также применимо для проектов, которые вы загрузили и которые предоставляют файл composer.json :

    Затем добавьте этот код в основной PHP-файл вашего приложения; это укажет PHP использовать автозагрузчик Composer для зависимостей вашего проекта.

    Теперь вы можете использовать зависимости вашего проекта и они будут автоматически загружаться (по требованию).

    Обновление зависимостей

    Composer создает файл composer.lock который хранит точную версию каждого пакета, который он загрузил во время первого запуска php composer.phar install . Если вы поделились проектом с другими разработчиками и файл composer.lock является частью него, то при запуске php composer.phar install они получат ту же версию, что и вы. Чтобы обновить ваши зависимости запустите php composer.phar update .

    Очень удобно гибко указывать требуемые версии. Если вы нуждаетесь в версии

    1.8, что значит “всё что новее 1.8.0, но меньше 2.0.x-dev”. Вы также можете использовать шаблон * , например 1.8.* . Теперь команда Composer php composer.phar update обновит все ваши зависимости до новейших версий, которые соответствуют указанным ограничениям.

    Проверка ваших зависимостей на безопасность

    Security Advisories Checker является веб-сервисом и инструментом командной строки, оба из которых изучают ваш файл composer.lock и сообщают, если есть необходимость в обновлении какой-либо из ваших зависимостей.

    Другим ветераном среди пакетных менеджеров, которым наслаждаются многие PHP-разработчики, является PEAR. Он работает практически так же, как и Composer, но имеет несколько важных отличий.

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

    PEAR устанавливает пакеты глобально, что означает то, что после установки, они доступны всем проектам на этом сервере. Это может быть полезно, если много проектов строятся на тех же пакетах с той же версией, но может привести к проблемам, если проекты разрабатывались для разных версий.

    Как установить PEAR

    Вы можете установить PEAR, загрузив установщик phar и выполнив его. Документация PEAR содержит подробную инструкцию по установке для каждой операционной системы.

    Если вы используете Linux, вы также можете посмотреть наличие PEAR в пакетном менеджере вашего дистрибутива. Debian и Ubuntu, к примеру, содержат информацию о пакете php-pear в пакетном менеджере apt.


    Как установить пакет

    Если пакет существует в списке пакетов PEAR, вы можете установить его, указав официальное название:

    Если пакет выложен на другом канале, вам нужно сначало сделать discover этого канала и затем указать его во время установки. Подробнее об этом в использование каналов.

    Обработка зависимостей PEAR с Composer

    Если вы уже используете Composer и желаете установить какой-то код из PEAR, вы можете использовать Composer для обработки зависимостей PEAR. Этот пример установит код из pear2.php.net :

    Первый раздел «repositories» даст понять Composer, что он должен сделать “initialise” (или “discover” в терминологии PEAR) репозиторий pear. Затем секция require укажет именам пакетов префикс, как ниже:

    Префикс “pear” жестко ограничен, чтобы избежать любых конфликтов, так как каналы Pear могут быть схожи с другими поставщиками пакетов например, вместо короткого имени (или полного URL) может быть использовано для объявления в каком канале находится пакет.

    Когда код будет установлен он будет доступен в вашей папке vendor и автоматически доступен через автозагрузчик (файл Autoload) Composer.

    Чтобы использовать этот пакет PEAR просто объявите как ниже:

    Практики написания кода

    Основы

    PHP — это обширный язык, который позволяет разработчикам всех уровней писать код не только быстро, но и эффективно. В любом случае, изучая язык, мы нередко забываем основы, которые мы изучали изначально (или бегло просмотрели), в пользу коротких путей и/или вредных привычек. Чтобы помочь в борьбе с этой общей проблемой, эта секция предназначена для напоминания разработчикам основ практик написания кода PHP.

    Дата и время

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

    Для начала работы с DateTime, сконвертируйте «сырую» строку даты и времени в объект с помощью фабричного метода createFromFormat() или выполните new \DateTime , чтобы получить текущую дату и время. Используйте метод format() для конвертирования DateTime обратно в строку для вывода.

    Вычисления с DateTime возможны с использованием класса DateInterval. У класса DateTime есть методы add() и sub() , которые принимают DateInterval, как аргумент. Не пишите код, который ожидает одинаковое число секунд каждый день, перевод часов и смена часовых поясов разрушат это предположение. Вместо этого используйте интервалы дат. Для расчета разницы между датами используйте метод diff() . Он вернет новый объект DateInterval, который очень легко отобразить.

    С объектами DateTime, вы можете использовать стандартные методы сравнения:

    И последний пример для демонстрации класса DatePeriod. Он используется для перебора повторяющихся событий. Класс может принимать два объекта DateTime, начало и конец, и интервал, для которого он вернет все события между ними.

    Design Patterns

    При построении приложения полезно использовать в коде шаблоны, а также придерживаться некоторых стандартов для всей структуры проекта. Использование шаблонов полезно, потому что оно упрощает управление кодом, а также позволяет другим разработчикам быстро понять, как всё взаимодействует друг с другом.

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

    Исключения

    Исключения — это неотъемлемая часть большинства популярных языков программирования, но зачастую PHP разработчики не уделяют им должного внимания. Языки, подобные Ruby, очень подробно обрабатывают исключения, поэтому, если что-то идёт не верно, например: не удался HTTP запрос, запрос к базе данных происходит неправильно или если запрошенное изображение не было найдено, Ruby (или используемые гемы) выбросит исключение на экран, помогающее понять где вы допустили ошибку.

    PHP сам по себе довольно слаб в плане этого и вызов file_get_contents() , как правило, даст вам только FALSE и предупреждение. Многие устаревшие PHP-фреймворки, как CodeIgniter, просто вернут false, добавят сообщение в свой собственный журнал и, может быть, дадут вам использовать метод, как $this->upload->get_error() , чтобы посмотреть, что пошло не так. Проблема в том, что вы должны искать ошибку и проверять документацию, чтобы понять, какой ошибочный метод существует в этом классе, вместо того, чтобы сделать это всё более очевидным.

    Еще одна проблема в том, что классы автоматически выдают ошибку на экран и закрывают процесс. Когда вы делаете это, вы не даете другому разработчику динамически обработать эту ошибку. Исключения должны быть выброшены, чтобы дать разработчику знать об ошибке и выбрать, как её обработать. Например:

    Исключения SPL

    Универсальный класс Exception предоставляет очень мало отладочного контекста для разработчика; как бы то ни было, для того чтобы исправить это, можно создать специализированный класс, который будет расширять возможности универсального класса Exception :

    Это означает, что вы можете добавить несколько блоков отлова и обрабатывать разные исключения по-разному. Это может привести к созданию множества изменённых Исключений, некоторые из которых можно было бы избежать, используя Исключения SPL, предоставляемые расширением SPL.

    Например, если вы используете магический метод __call() и вами был вызван неизвестный метод, то вместо выбрасывания стандартного исключения, которое очень расплывчато, или вместо создания своего исключения, вы можете просто использовать throw new BadFunctionCallException; .

    Базы данных

    Скорее всего, ваш PHP код будет использовать базу данных для сохранения информации. Существует несколько вариантов для подключения и взаимодействия с базой данных. Рекомендуемым вариантом до PHP 5.1.0 было использование нативных (родных) драйверов, таких как mysql, mysqli, pgsql, etc.

    Встроенные драйвера замечательны, если вы используете ОДНУ базу данных в ваших приложениях, но если, например, вы используете MySQL и немного MSSQL, или вам нужно подключиться в базе данных Oracle, тогда вы не сможете использовать те же драйвера. Вам нужно будет изучить новый API для каждой базы данных — и это может оказаться нерациональным.

    Обратите внимание, что расширение mysql для PHP больше не поддерживается, и его официальным статусом, начиная с PHP версии 5.4.0, является «Устарело в связи с длительным сроком использования». Это значит, что оно будет удалено в течение нескольких следующих релизов, так что в PHP 5.6 (или в версиях, следующих за 5.5) оно вполне может пропасть. Если вы используете mysql_connect() и mysql_query() в своих приложениях, тогда вам придется столкнуться с переписыванием кода, поэтому лучшим вариантом сейчас является использование в приложениях mysqli или PDO вместо mysql, прежде чем вы в дальнейшем столкнётесь с нерабочими приложениями. Если вы начинаете изучение баз данных с нуля, тогда полностью откажитесь от использования расширения mysql — используйте Расширение MySQLi или PDO.

    PDO — это абстрактная библиотека для подключения к базе данных, встроенная в PHP с версии 5.1.0, которая обеспечивает единый интерфейс для взаимодействия с большим количеством различных баз данных. PDO не будет переводить ваши SQL запросы или эмулировать отсутствующие возможности; он чист для подключения к нескольким типам баз данных с тем же API.

    Более важно, что PDO позволяет вам безопасно вводить пользовательские данные (например идентификатор) в ваши SQL запросы, без беспокойства о SQL-инъекциях. Это возможно благодаря использованию PDO выражений и связывания (bound) параметров.

    Предположим, что PHP скрипт получает числовой идентификатор в качестве параметра из запроса. Этот идентификатор должен быть использован для получения пользовательских записей из базы данных. Ниже приведён неправильный способ реализации этого:

    Это ужасный код. Вы вставляете необработанные параметры в SQL запрос. Это приведёт к взлому. Просто представьте, что взломщик сделает запрос http://domain.com/? >, который присвоит переменной $_GET[‘id’] значение 1;DELETE FROM users и приведёт к удалению всех ваших пользователей! Вместо этого, вы должны очистить ввод идентификатора с помощью связывания параметров PDO.

    Это правильный код. Он использует связанный параметр в выражении PDO. Это позволяет избежать ввода некоректного ID перед тем, как передать запрос в базу данных, тем самым предотвращая потенциальные SQL-инъекции.

    Вы также должны понимать, если подключение не закрыто должным образом, то оно использует много ресурсов, которые тратятся впустую, впрочем это больше относится к другим языкам. Используя PDO, вы можете неявно закрывать подключение уничтожив объект — все ссылки на него будут удалены, т.е. установлены в NULL. Если не сделать этого явно, PHP закроет подключение за вас, когда выполнение скрипта завершится, если только вы не используете постоянные подключения.

    Уровни абстракции

    Многие фреймворки предоставляют собственный уровень абстракции, который может строиться на основе PDO. Такая фактическая абстракция баз данных позволяет оборачивать запросы на PHP в методы, которые отсутствуют в одной системе баз данных, но работают в другой. Это, конечно, добавит небольшие накладные расходы, но если вы строите портативные приложения, которым необходима работа с MySQL, PostgreSQL и SQLite, тогда, для чистоты кода, минимальными накладными расходами можно пренебречь.

    Некоторые уровни абстракции построены с использованием PSR-0 стандарта, поэтому могут быть установлены в любое приложение:

    Безопасность

    Безопасность веб-приложений

    Есть плохие люди, которые могут и хотят взломать ваши веб-приложения. Важно принять необходимые меры предосторожности, чтобы укрепить безопасность вашего приложения. К счастью, прекрасные люди в The Open Web Application Security Project (OWASP) составили полный список известных проблем безопасности и методов защиты от них. Это должно быть прочитано любым разработчиком, заботящимся о безопасности.

    Хэширование паролей

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

    Очень важно правильно хэшировать пароль перед его сохранением. Хэширование пароля является необратитым, односторонняя функция применяется на пользовательских паролях. Она возвращает строку определенной длины, которую невозможно расшифровать. Это значит, что вы можете сравнить один хэш с другим, чтобы понять, что они пришли из одной и той же исходной строки, но вы не можете определить оригинальную строку. Если ваши пароли не захэшированы, и доступ к базе данных получен третьй стороной, то ваши пользовательские аккаунты теперь скомпрометированы. Некоторые пользователи (к сожалению) могут использовать один и тот же пароль для разных сервисов. Как бы то ни было, очень важно серьезно относиться к безопасности.

    Хэширование паролей с функцией password_hash

    В PHP 5.5 была представлена функция password_hash . Сейчас она использует BCrypt, сильнейший алгоритм, поддерживаемый PHP. Она будет обновлена в будущем, для поддержки бОльшего числа алгоритмов, по мере необходимости. Библиотека password_compat была создана для обратной совместимости с PHP >= 5.3.7.

    Ниже мы хэшируем строку и далее сверяем её с новой строкой. Поскольку наши две исходные строки отличаются (‘secret-password’ и ‘bad-password’) эта авторизация будет неудачной.

    Фильтрация данных

    Никогда не доверяйте пользовательскому вводу, который передаётся вашему PHP коду. Всегда проверяйте и очищайте пользовательский ввод перед его использованием в коде. Функции filter_var и filter_input помогут очистить переменные, а также проверить соответствие введённых данных некоторому формату (например, адрес электронной почты).

    Пользовательский ввод может быть различным: $_GET и $_POST , данные введённые в форму, некоторые значения в суперглобальной переменной $_SERVER и тело HTTP запроса, открытое с помощью fopen(‘php://input’, ‘r’) . Запомните, что пользовательский ввод не ограничивается данными формы, отправленной пользователем. Отправляемые и загружаемые файлы, значения сессий, данные cookie и данные сторонних веб-сервисов также приравниваются к пользовательскому вводу.

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

    Данные могут быть отфильтрованы по-разному, в зависимости от их назначения. Например, когда нефильтрованные данные, введённые пользоватем, передаются в HTML код страницы, он может выполнить HTML и JavaScript на вашем сайте! Этот тип атаки известен, как Cross-Site-Scripting (XSS) и может иметь очень серьёзные последствия. Один из способов избежать XSS заключается в очистке ввода от всех HTML тэгов (их удалением, или заменой на HTML символы) с помощью функции strip_tags или экранирование символов в равносильные им HTML сущности с функцией htmlentities или htmlspecialchars .

    Другой пример, передача данных для выполнения командной строкой. Это может быть крайне опасно (и, как правило — это плохая идея), но вы можете использовать встроенную функцию escapeshellarg для очистки аргументов командной строки.

    Последний пример, принимает пользовательский ввод, чтобы определить, какой файл загружать из файловой системы. Это может быть использовано для изменения имени файла на путь файла. Вам нужно убрать “/”, “../”, нулевые байты или другие символы из пути файла, так чтобы скрипт не мог загружать скрытые, непубличные или конфиденциальные файлы.

    Санитизация

    Санитизация удаляет (или экранирует) неправильные или небезопасные символы из пользовательского ввода.

    Например, вам необходимо нормализовать пользовательский ввод перед подключением ввода в HTML или его вставкой в сырой SQL запрос. Когда вы используете связанные параметры с PDO, они будут очищать ввод за вас.

    Иногда требуется разрешить некоторые безопасные HTML тэги в вводе, когда он подключается в HTML страницу. Это очень трудно сделать и многие избегают этого, используя ограниченное форматирование, как например Markdown или BBCode, либо библиотеки с белым списком, как HTML Purifier, существующие по этой причине.

    Валидация

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

    Конфигурационные файлы

    Когда вы создаёте файлы конфигурации для ваших приложений, рекомендуется использование одного из следующих способов:

    • Рекомендуется хранить вашу конфигурационную информацию там, где к ней не может быть получен доступ напрямую, а доступ к ней осуществлялся через файловую систему.
    • Если вы вынуждены хранить конфигурационные файлы в корневом каталоге, именуйте файл с расширением .php . Это гарантирует, что, если к скрипту обратятся напрямую, он не будет выведен, как обычный текст.
    • Информация в файлах конфигурации, должна быть защищена соответственно, либо с помощью шифрования или системных прав группы/пользователя файла.

    Использование глобальных переменных

    Примечание: С появлением PHP 5.4 директива register_globals была удалена и больше не может быть использована. Это касается тех, кому нужно обновить старое приложение.

    Включенный параметр конфигурации register_globals делает несколько типов переменных (в том числе из $_POST , $_GET и $_REQUEST ) глобальными, доступными в глобальной области видимости вашего приложение. Это может легко привести к проблемам с безопасностью, поскольку ваше приложение не сможет эффективно определить откуда пришли данные.

    Например : $_GET[‘foo’] будет доступна через $foo , которая может заместить переменную, которая не была объявлена. Если вы используете PHP register_globals off (выключена).

    Сообщения об ошибках

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

    Разработка

    Для того, чтобы видеть все возможные ошибки во время разработки, настройте следующие параметры в вашем php.ini :

    Установка значения в -1 покажет каждую возможную ошибку, даже если новые уровни и константы будут добавлены в новых версиях PHP. Константа E_ALL ведёт себя так-же в PHP 5.4. — php.net

    Константа уровня ошибок E_STRICT была введена в 5.3.0 и не является частью E_ALL , как бы то ни было, она стала частью E_ALL в 5.4.0 Что это значит? Для вывода всех возможных ошибок в версии 5.3 вам нужно использовать либо -1 либо E_ALL | E_STRICT .

    Вывод всех ошибок разными версиями PHP

    • -1 or E_ALL
    • 5.3 -1 or E_ALL | E_STRICT
    • > 5.3 -1 or E_ALL

    Продакшн

    Чтобы спрятать все ошибки вашей среды во время продакшна, настройте ваш php.ini следующим образом:

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

    Тестирование

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

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

    Тесто-ориентированная разработка

    Разработка через тестирование (TDD) представляет собой процесс разработки программного обеспечения, который опирается на повторении очень короткого цикла разработки: сперва, разработчик пишет автоматизированные тесты, которые определяют желаемое улучшение или новую функцию, далее производит код, который успешно пройдет этот тест и наконец производит рефактор кода для соответствия стандартам. Kent Beck, человек которому приписывают статус разработчика или “переоткрывателя” техники, TDD предлагает простую конструкцию, а также вселяет уверенность.

    Существует несколько различных типов тестирования, которые вы можете сделать для вашего приложения.

    Модульное тестирование (Unit Testing)

    Модульное тестирование — это подход к программированию, который позволяет удостовериться, что функции, классы и методы работают, как ожидается с момента начала и до конца разработки. Проверяя значения, которые приходят и выходят из различных функций и методов, вы можете быть уверены, что внутренняя логика работает правильно. Используя Внедрение Зависимостей и внедрение классов «макетов» и заглушек, вы можете убедиться, что зависимости используются правильно для большего покрытия тестами.

    При создании класса или функции, вы должны создать модульный тест для каждого возможного поведения. На базовом уровне, вы должны убедиться, что ваш код выдаёт ошибку, если вы отсылаете неправильные аргументы и работает, если вы отсылаете правильные аргументы, соответственно. Это поможет убедиться в том, что изменения, которые вы сделаете относительно этого класса или функции позднее не помешают старым работать как ожидалось. Единственная альтернатива этому var_dump() в test.php, который не является способом создания приложений — больших или маленьких.

    Ещё одно использование модульных тестов — вклад в open source. Если вы можете писать тесты, которые показывают сломанную функциональность, тогда почините её, и покажите, что тест пройден, патчи имеют больше шансов быть принятыми. Если вы запускаете проект, который допускает Pull Request, тогда вы должны указать это в качестве требования.

    PHPUnit является фреймворком тестирования стандарта де-факто для написания модульных тестов в PHP приложениях, но также существует несколько альтернатив.

    Интеграционное тестирование

    Интеграционное тестирование (иногда называется Интеграция и Тестирование, с аббревиатурой “I&T”) это фаза в тестирование програмнного обеспечения, в котором отдельные модули, комбинируются и тестируются, как группа. Это происходит после модульного тестирования и перед валидационным тестированием. Integration testing takes as its input modules that have been unit tested, groups them in larger aggregates, applies tests defined in an integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.

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

    Функциональное тестирование

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

    Инструменты функционального тестирование

    • Selenium
    • Mink
    • Codeception это фреймворк для тестирования (всё-в-одном), включающий инструменты подтверждающего тестирования

    Поведенческо-ориентированная разработка

    Существует две разновидности Поведенческо-ориентированной разработки (BDD): SpecBDD и StoryBDD. SpecBDD концентрируется на техническом поведении или коде, в то время как StoryBDD концентрируется на деле, будущем поведении или взаимодействии. PHP имеет фреймворки для обоих типов BDD.

    Используя StoryBDD, вы пишите читаемые людьми истории, которые объясняют поведение вашего приложения. Эти истории могут быть запущены, как актуальные тесты для вашего приложения. Фреймворк, используемый в PHP приложениях для StoryBDD — Behat, который вдохновлён проектом для Ruby Cucumber и реализует Gherkin DSL для объяснения особенностей поведения.

    Вместе со SpecBDD, вы пишите спецификацию, которая объясняет, как ваш код должен себя вести. Вместо тестирования функции или метода, вы объясняете, как эта функция или метод должен себя вести. PHP предлагает фреймворк PHPSpec для данных целей. Этот фреймворк вдохновлён проектом RSpec для Ruby.

    Инструменты

    • Behat, StoryBDD фреймворк для PHP, вдохновлённый проектом для Ruby Cucumber;
    • PHPSpec, SpecBDD фреймворк для PHP, вдохновлённый проектом для Ruby RSpec;
    • Codeception это фреймворк для тестирования (всё-в-одном), использующий принципы BDD;

    Дополнительные инструменты тестирования

    Помимо индивидуального тестирования и поведенческо-ориентированных фрэймворков, существует ряд общих фреймворков и вспомогательных библиотек, полезных для любого предпочтительного подхода.

    Инструменты

    • Selenium автоматизационный инструмент для браузера интегрируемый с PHPUnit
    • Mockery Mock Object Framework интегрируемый с PHPUnit или PHPSpec

    Сервера и развертывание

    PHP приложения могут быть развернуты и запущены на продакшн веб-сервере рядом способов.

    Платформа, как сервис (PaaS)

    PaaS предоставляет системную и сетевую архитектуры, необходимые для запуска PHP приложений в веб. Это означает, как минимум, отсутствие настройки для запуска PHP приложений или PHP фреймворков.

    В недавнее время PaaS стал очень популярным методом для развертывания, хостирования и расширения PHP приложений всех размеров. Вы можете найти список провайдеров PHP PaaS в нашей ресурсной секции.

    Виртуальный или выделенный сервер

    Если вы знакомы с администрированием системы, или заинтересованы в его изучении, виртуальный или выделенный сервер даст вам полный контроль над средой продакшна вашего приложения.

    nginx и PHP-FPM

    PHP, через встроенный в него менеджер процессов FastCGI (FPM), очень хорошо сочетается с nginx, который является легковесным и высокопроизводительным веб-сервером. Он использует меньше памяти, чем Apache и может лучше обрабатывать конкурентные запросы. Это особенно важно на виртуальном сервере, для которого может быть критичен объем используемой памяти.

    Apache и PHP

    PHP и Apache имеют длинную совместную историю. Apache широконастраиваемый и имеет большое количество доступных модулей для расширения функциональности. Это очень популярный выбор для виртуальных хостингов и лёгкой установки PHP фреймворков и приложений с открытым исходным кодом, как WordPress. К сожалению, Apache использует больше ресурсов, чем nginx, и не может выдержать столько же посетителей одновременно.

    Apache имеет несколько возможных конфигураций для запуска PHP. Самая популярная и лёгкая для установки prefork MPM вместе с mod_php5. Хотя это не самое эффективное в отношении памяти решение, оно очень просто для установки и использования. Наверное, это лучшее решение, если вы не хотите углубляться в серверное администратирование. Если вы хотите использовать mod_php5, вы обязаны использовать prefork MPM.

    Если вы хотите получить больше производительности и стабильности с Apache, тогда вы можете взглянуть на ту же FPM систему, как в nginx и запустить worker MPM или event MPM, используя mod_fastcgi или mod_fcgid. Эта конфигурация позволит получить существенную экономию в памяти и будет намного быстрее, но потребует больше работы для установки.

    Виртуальный хостинг

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

    Построение и развёртывание вашего приложения

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

    Среди задач, которые вы, возможно, захотите автоматизировать:

    • Управление зависимостями
    • Компиляция, минификация файлов (assets)
    • Запуск тестов
    • Создание документации
    • Запаковка
    • Развёртывание

    Создание инструментов автоматизации

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

    Существует большое количество инструментов с открытым исходным кодом, которые могут помочь вам автоматизировать процесс постройки, некоторые написаны на PHP, другие на других языках. Это не должно удерживать вас от их использования, если они лучше подходят под задачу. Вот несколько примеров:

    Phing самый простой путь, чтобы начать автоматическую развёртку в мире PHP. С Phing вы можете контролировать ваш процесс запаковки, развёртки или тестирования с помощью простого построечного XML файла. Phing (который базируется на Apache Ant) предоставляет богатый набор задач, часто необходимых для установки или обновления веб приложения, и может быть расширен дополнительными нестандартными задачами, написанными на PHP.

    Capistrano — система для начинающих-профессиональных разработчиков для исполнения команд в структуризованном, воспроизводимом пути на одной или многих удалённых машинах. Предварительно он настроен для развёртки приложений Ruby on Rails. Как бы то ни было люди успешно развёртывают и PHP приложения с ним. Успех использования Capistrano зависит на умении работы с Ruby и Rake.

    Сообщение в блоге Dave Gardner PHP Deployment with Capistrano является хорошей отправной точкой для PHP разработчиков, заинтересованных в Capistrano.

    Chef является нечто большим, чем просто фрэймворк развёртки. Это очень мощный интеграционный фрэймворк, основанный на Ruby, который не просто развёртывает ваше приложение, но и может построить всё серверное окружение или виртуальный сервер.

    Ресурсы о Chef для PHP разработчиков:

    Для дальнейшего изучения:

    Непрерывная интеграция

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

    Существуют разные пути, для осуществления непрерывной интеграции для PHP. Недавно Travis CI закончил великолепную работу по созданию непрерывной интеграции, реально даже для маленьких проектов. Travis CI — сервис непрерывной интеграции для сообщества с открытым исходным кодом. Оно интегрируется с GitHub и предлагает первоклассную поддержку для многих языков, включая PHP.

    Для дальнейшего изучения:

    Кэширование

    PHP очень быстр сам по себе, но такие ресурсоёмкие операции, как установка удалённого подключения и, к примеру, загрузка файлов, могут привести к существенному падению скорости работы приложения. К счастью, есть различные инструменты, позволяющие поднять скорость определённых частей вашего приложения, или уменьшить количество запусков этих «тяжёлых» задач.

    Кэширование байткода

    Во время исполнения PHP файла, на низком уровне он сперва компилируется в байткод (или опкод) и только потом исполняется байткод. Если PHP файл не изменён, то байткод будет всегда одинаков. Это значит, что шаг компиляции — пустая трата процессорных ресурсов.

    И тут настает время кэширования байткода. Оно предотвращает избыточные компиляции, сохраняя в памяти байткод и переиспользуя его в последовательных вызовах. Установка подобного кэширования — вопрос пары минут, а скорость вашего приложения поднимется существенно. Поэтому нет причин не использовать кэширование.

    Начиная с PHP 5.5 появилось встроенное расширение для кэширования байткод — OPcache. Оно также доступно в виде отдельного расширения для ранних версий.

    Популярные системы подобного кэширования:

    • APC (PHP 5.4 и более ранние)
    • XCache
    • Zend Optimizer+ (часть Zend Server)
    • WinCache (расширение для MS Windows Server)

    Кэширование объектов

    Бывают моменты, когда вам необходимо кэшировать определённые объекты в вашем коде, такие как данные, которые неразумно получать ещё раз из базы данных, когда результат вряд ли изменится. Вы можете использовать ПО для кэширования чтобы сохранить эти кусочки данных в памяти, что позволит чрезвычайно быстро обратиться к ним позже. Если вы сохраните эти объекты в хранилище данных и после получите их и выдадите напрямую из кэша для некоторых запросов, вы можете получить существенное улучшение производительности и уменьшение нагрузки на сервер базы данных.

    Множество популярных решений для кэширования байткода также дают вам кэшировать данные, поэтому нет причин, чтобы не воспользоваться ими. APC, XCache и WinCache предоставляют API для сохранения данных из вашего PHP кода в свой кэш в памяти.

    Самыми популярными системами кэширования объектов являются APC и memcached. APC — идеальный выбор для кэширования объектов, он включает простой API для добавления данных в кэш память и при этом очень просто устанавливается и используется. Единственное существующее ограничение APC состоит в том, что он привязан к серверу на котором установлен. Memcached, напротив, устанавливается как отдельный сервис, и к нему можно получить доступ по сети, что позволяет хранить объекты в очень быстром централизованном хранилище данных и множество других систем могут получать эти данные из него.

    Учтите, если PHP запущен как (Fast-)CGI приложение внутри вашего веб-сервера, то каждый PHP процесс будет иметь собственный кэш, например, APC данные не будут расшарены между вашими процессами. В этом случае имеет смысл подумать об использовании вместо него memcached, так как он не ограничен процессом PHP.

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

    Пример использования APC:

    Подробнее о популярных системах кэширования объектов:

    Топ-пост этого месяца:  Директива register_globals. Проблемы и решения.
    Добавить комментарий