8 самых необходимых инструментов контроля качества PHP-кода PHP


Оглавление (нажмите, чтобы открыть):

Форум PHP программистов ► Клиентская сторона ► Оцените

Пейджер выключен!

Профиль
Группа: Пользователь
Сообщений: 28
Пользователь №: 28131
На форуме:
Карма:

Оцените новую социальную сеть для программистов : expertjournal.ru

Разработан механизм оценки «качества» PHP кода.

Статический анализатор вычисляет около сотни характеристик кода, на основе которых вычисляется индекс качества исходника.

Т.е. добавляете исходник и получаете индекс качества кода и ценные комментарии, выдаваемые системой.

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

Подробнее см. на сайте.

Ваши комментарии помогут нам понять к каком направлении развиваться дальше, приветствуется конструктивная критика, спасибо за внимание.

ExpJ
Свои наработки давать другим, или это будет сборище бесплатных скриптов — быдлокодеров? А если мой идеальный код начнут тролить? Открой «Мой мир» или «Вконтакте», в случае оценки не 5, сразу ссоры, грубости, наезды. Вот и получается, все анкеты имеют оценки 5-5-5-5-5-5-5-5-5-5-5.

И не рано ли давать рекламу имея нулевое наполнение?

denash
Другие люди оценивают.

Цитата (denash @ 31.05.2011 — 21:48)
Всё облазил, так и не нашёл, как код онлайн оценить

В системе есть два вида исходников: 1) внутренние т.е. контент исходника загружается на expertjournal 2) внешние, на expertjournal.ru загружается только ссылка и описание (такой вид полезен в случае если, например, исходник не может быть загружен из соображений об авторском праве)

Для того что бы добавить внешний исходник регистрироваться не обязательно, зайдите по ссылке http://expertjournal.ru/ru/source, заполните форму. Там надо добавить описание и указать http:// ссылку на архив с исходником.

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

Подробнее алгоритм оценки качества кода описан тут http://expertjournal.ru/ru/article/view/id/12

Цитата (inpost @ 31.05.2011 — 21:55)
ExpJ
Свои наработки давать другим, или это будет сборище бесплатных скриптов — быдлокодеров? А если мой идеальный код начнут тролить? Открой «Мой мир» или «Вконтакте», в случае оценки не 5, сразу ссоры, грубости, наезды. Вот и получается, все анкеты имеют оценки 5-5-5-5-5-5-5-5-5-5-5.

И не рано ли давать рекламу имея нулевое наполнение?

denash
Другие люди оценивают.

На сайте будут следующие виды контента: исходники, блоги, критерии качества кода, портфолио экспертов и компаний.

Т.е. будет сборник скриптов с открытым исходным кодом с единым рейтингом их «качества».

Т.е. быдло код тоже будет, но он будет иметь маленький «индекс качества» и соответственно будет на последних страницах рейтинга. А автор быдло кода будет иметь низкий «индекс квалификации».

На счет оскоблений: матерные и оскорбительные сообщения будут строго модерироваться, вплоть до публикации после проверки модератором.

На счет рано или нет дали рекламу: надеемся что не рано

Цитата (inpost @ 1.06.2011 — 06:00)
ExpJ
А кто же этот «индекс квалификации» устанавливает? Разве не общественное мнение?

ExpJ
Ну так я уже ответил: «Открой «Мой мир» или «Вконтакте», в случае оценки не 5, сразу ссоры, грубости, наезды. Вот и получается, все анкеты имеют оценки 5-5-5-5-5-5-5-5-5-5-5″. Вообщем если я плохой человек, полная редиска, все мои идеальные скрипты будут иметь балы 1-2-1-1, хотя скрипт будет идеален, а любимец публики, какой-нибудь Попов, будет иметь 5-5-5-5-5 с нулевым опытом, лишь потому что, он клёвый парень, или эта молодая девушка такая няшечка с 3-4 размером груди.
Ты просил оценить, так вот, для меня всё это — полный ужас, мне не нравится вся такая система, она вызывает у меня отвращение. Ещё один сервис, где нет правде и справедливости, а так как это одно из основных вещей сети, то — негативная оценка сервиса.

Ну это ИМХО, ничего более.

Цитата (inpost @ 1.06.2011 — 06:25)
ExpJ
Ну так я уже ответил: «Открой «Мой мир» или «Вконтакте», в случае оценки не 5, сразу ссоры, грубости, наезды. Вот и получается, все анкеты имеют оценки 5-5-5-5-5-5-5-5-5-5-5″. Вообщем если я плохой человек, полная редиска, все мои идеальные скрипты будут иметь балы 1-2-1-1, хотя скрипт будет идеален, а любимец публики, какой-нибудь Попов, будет иметь 5-5-5-5-5 с нулевым опытом, лишь потому что, он клёвый парень, или эта молодая девушка такая няшечка с 3-4 размером груди.
Ты просил оценить, так вот, для меня всё это — полный ужас, мне не нравится вся такая система, она вызывает у меня отвращение. Ещё один сервис, где нет правде и справедливости, а так как это одно из основных вещей сети, то — негативная оценка сервиса.

Ну это ИМХО, ничего более.

Вы наверное не очень внимательно ознакомились с сервисом.

Дело в том что «индекс качества кода» для исходника вычисляется не только с помощью голосования, а и с помощью внутреннего механизма оценки качества кода. Этот механизм состоит в следующем:

Для каждого исходника вычисляется около сотни различных характеристик кода, эти характеристики сравниваются с эталонными значениями. На основе этого вычисляется индекс качества исходника. Из индексов качества исходников вычисляется индекс квалификации их авторов (экспертов).

Поэтому если вы просто добавите исходник то голосования ждать не нужно, система автоматически вычислит его индекс качества и еще комментарии выдаст, типа этих http://expertjournal.ru/ru/source/view/id/718 http://expertjournal.ru/ru/source/response/id/718

Так вот для доктрины индекс качества получился 81, а для смешанного плохо структурированного быдло кода с кучей глобальных переменных у меня получалось меньше 10. Так что на качественном уровне алгоритм вполне работает.

Таким образом система лишена описанного вами недостатка и груди большого размера мало помогут в повышении «индекса качества исходника».

На счет отвращения, правды и справедливости — это просто ваше личное мнение. Лично мне сервис нравится.

Цитата (tatti @ 1.06.2011 — 07:21)
Идея на мой взгляд мягко-говоря не революционная. НО если есть деньги на поддержку и раскрутку + желание этим заниматься так почему-бы и нет? в конце концов это однозначно на пользу не обществу так вам

Опыт бесценен — это точно.

Не могли бы вы прислать ссылки на аналоги? Лично я ничего похожего не находил.

Цитата (Basili4 @ 1.06.2011 — 18:12)
Идея реса прям мне понравилась. Но я думаю ваш рес станет аналогом говнокода. Что в принципе не плохо.
Цитата
На каком основании вы так думаете? Есть какие то серьезные причины?

Причины банальны. Дело в том, что профессиональные программисты не станут пользоваться этим сервисом.
Допустим я программист с опытом и стажем.
1. Мне не нужно такое сомнительное портфолио, ибо давно есть проработанное свое.
2. Я не понимаю, кто и с какой квалификацией будет меня оценивать. Если это Пупкин из общественности, который научился привет мир писать, на кой мне его оценка
3. Критерии автоматической оценки вообще не ясны. Как можно автоматом оценить красоту алгоритмов? А стиль, уж поверь, у профессионалов, вполне на высоте. Причем часто у каждого свой.
3. Банально лень, и так все нормально и дел по горло.
4. И т.д. и т.п. и пр. пр.

Соответственно в таком сервисе заинтересованы исключительно начинающие программисты . А процент говнокодеров (ввиду малого опыта) среди них стремительно близится к 100.

От того я полностью разделяю точку зрения Basili4‘а. Задумка неплохая, но вряд ли осуществима в том русле, в котором планируется.
Для начинающих будет место где порезвиться, сколь либо серьёзно отнестись к такого рода ресурсу трудно. Я допустим с бооольшим сомнением отнесусь как к чистоте оценки, так и к репозитарию.

Basili4:
Интуиция иногда нас подводит. Мир намного шире, чем кажется.

Абсолютно верно пишите.

Т.е. все упирается в совершенство алгоритма оценки. На то она и голова на плечах что бы со временем совершенствовать этот алгоритм.

А на счет портфолио, если оценка будет адекватной то почему же не будут и серьезные программисты пользоваться. К примеру, в западных университетах пользуется популярностью индекс цитируемости ученого, между прочим имеет большой вес при устройстве на работу. Вот см. http://expertjournal.ru/ru/article/view/id/17

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

На счет автоматической оценки качества кода вот см. здесь http://expertjournal.ru/ru/article/view/id/12
В данный момент алгоритм возможно не совершенен, но в каком то приближении нормально работает. Вот см. http://expertjournal.ru/ru/source
Доктрина же хорошая ORM. Со временем будем алгоритм совершенствовать.

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

Цитата
Самая лучшая ORM для PHP.

Странная оценка. Хотя учитывая то, что представлен только один скрипт наверное так и есть. Нужно только у точнить — «из представленных».

Ну а в принципе, почему бы нет. Если верить в идею и работать с ней, все должно получиться.
Остается пожелать удачи.

Как улучшить производительность PHP для веб-приложений

Программистам очень нравится последняя версия PHP — одного из наиболее быстрых языков сценариев. В этом можно убедиться, прочитав, например, статью « Сравнение производительности PHP 7.0 и HHVM » на Хабрахабре или статью на английском языке “ PHP 7 vs HHVM – Which One Should You Use? ”

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

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

Краткая история PHP

PHP — это язык сценариев, изобретенный Расмусом Лердорфом ( Rasmus Lerdorf ) в 1995 году. Первоначально этот язык разработчики написали для себя. Поэтому язык получил соответствующее название PHP как аббревиатуру от “ Personal Home Page” — «Личная Домашняя Страница».

В ходе дальнейшей работы над языком Лердорф существенно расширил функциональность PHP, поэтому считается, что PHP теперь является рекурсивной аббревиатурой от “PHP: Hypertext Preprocessor” — « PHP : Гипертекстовый Препроцессор».

За последние два десятилетия группа разработчиков PHP улучшила производительность PHP в следующих направлениях:


1. Прежде всего, в 1999 году появился новый PHP -движок Zend Engine;

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

3. В 2004 году был выпущен PHP 5. Кроме прочего — обновилось ядро Zend (Zend Engine 2), что существенно увеличило эффективность этого интерпретатора;

4. В 2015 году появился обновленный PHP 7.0 с улучшенным движком Zend Engine и уменьшенным потребления памяти ;

5. В момент написания статьи доступна новейшая версия PHP 7.1 от декабря 2020 года. Веб-сайт классов PHP содержит подробное описание всех изменений, внесенных между PHP 5 и PHP 7.1 (также в Википедии ).

Что такое действительно хорошая производительность PHP ?

Следует иметь ввиду, что производительность и скорость — не являются синонимами. Оптимальная производительность балансирует между скоростью, безошибочностью и масштабируемостью. Например, при написании веб-приложения придется выбирать между двумя приоритетами:

1) приоритетом скорости , написав скрипт, который заранее загружает все в память;

2) приоритетом масштабируемости со скриптом, который загружает данные блоками.

На следующем рисунке 1 показан теоретический компромисс между скоростью и масштабируемостью.

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

Рис. 1. Теоретический компромисс между скоростью и масштабируемостью

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

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

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

Когда следует начинать оптимизировать PHP -код?

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

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

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

Советы по оптимизации PHP -скриптов

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

1. Используйте готовые функции PHP

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

2. Используйте JSON вместо XML

Функции PHP json_encode() и json_decode() просто невероятно быстры. Поэтому использование JSON предпочтительнее использования XML.

Если вам все же приходится разбираться с XML, лучше использовать шаблонные регулярные выражения, чем манипуляции с DOM.

3. Используйте методы кэширования

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

Кэширование байт-кода с помощью APC или OPcache сильно экономит время выполнения скомпилированного сценария.

4. Уберите лишние вычисления

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

5. Используйте isset()

Проводите сравнения с помощью пар count () , strlen() и sizeof() , isset() . Это быстрый и простой способ поиска значений, больше нуля.

6. Отключите ненужные классы

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

7. Отключите отладочные сообщения

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

8. Закрывайте соединения с базой данных

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

9. Ограничьте обращения к базе данных

Старайтесь использовать совокупности запросов к базе данных. Это сокращает количество обращений к базе данных, приложение будет работать быстрее.

10. Используйте строковые функции Str

str_replace быстрее, чем preg_replace , а strtr в четыре раза быстрее, чем str_replace .

11. Используйте одинарные кавычки

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

12. Используйте три знака равенства

Поскольку « = = =» проверяет величины только одного типа, это делает оператор сравнения « = = =» более быстрым, чем оператор « = =» .

Узкие места производительности PHP

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

1. Сеть

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

2. Центральный процессор

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

3. Совместно используемая память

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

4. Файловая система

Файловая система со временем становится фрагментированной. Поэтому используйте файловый кэш RAM, который ускорит доступ к диску, если этот кэш достаточного размера.

5. Управление процессами

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

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

6. Другие серверы

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

Еще советы по улучшению производительности PHP


1. Используйте расширение ядра Zend OPCache

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

Zend OPCache — это расширение, которое сохраняет скомпилированный код в памяти. Это позволяет PHP в следующий раз при выполнении кода проверять разметки времени и размеры файла, чтобы определить, были ли части исходного файла изменены. Если таких изменений не было, то будет запущен сохраненный код.

Более подробную информацию можно получить в статье на Хабрахабре « PHP Performance Series: Caching Techniques »

На рисунке 2 показано различие во времени выполнения и использовании памяти между PHP-приложением, выполняемым: 1) без кэша; 2) с OPcache; 3) с eAccelerator (другой инструмент PHP-кэширования).

Правый график показывает время выполнения в миллисекундах ( Execution Time (ms) ), левый — использование памяти в мегабайтах ( Memory usage (mb) ). Столбики синего цвета соответствуют отсутствию кэширования , красного — кэшированию OPcache , зеленого — кэшированию eAccelerator.

Из рисунка 2 следует, что кэширование OPcache снижает как время выполнения, так и использование памяти примерно в два раза по сравнению с отсутствием кэширования. Кэширование eAccelerator немного уступает кэшированию OPcache.

Рис. 2. Столбиковые диаграммы различия во времени выполнения и использовании памяти между PHP-приложением, выполняемым без кэширования, с OPcache и с eAccelerator

2. Выявите задержки базы данных

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

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

Как узнать, какие из запросов выполняются дольше всего? Более подробно см. статью на Хабрахабре « Как выявить медленные SQL запросы? », URL: https://habrahabr.ru/post/31072/

3. Очистите файловую систему

Проанализируйте файловую систему на неэффективность, то есть удостоверьтесь, что файловая система не используется для хранения сессий. Самое главное — внимательно следите за функциями статистики файлов: file_exists(), filesize() и filetime(). Попадание этих функций внутрь цикла приводит к проблемам с производительностью.

4. Тщательно контролируйте показ API

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

5. Профилируйте PHP

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

Xdebug рассматривается в статье на Хабрахабре « Introducing xdebug »

Необходимо уметь контролировать производительность PHP

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

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

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

Перспективы улучшения производительности PHP

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

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

Контроль типа

PHP 5 предоставляет возможность использовать контроль типов. На данный момент функции имеют возможность заставлять параметры быть либо объектами (путем указания имени класса в прототипе функции), либо интерфейсами, либо массивами (начиная с PHP 5.1), или колбеком с типом callable (начиная с PHP 5.4). Однако, если NULL использовался как значение параметра по умолчанию, то это будет также допустимо в качестве аргумента для последующего вызова.

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

Контроль типа не может быть использован со скалярными типами, такими как int или string . Ресурсы и Трейты также недопустимы.

Пример #1 Пример контроля типов

// Тестовый класс
class MyClass
<
/**
* Тестовая функция
*
* Первый параметр должен быть объектом типа OtherClass
*/
public function test ( OtherClass $otherclass ) <
echo $otherclass -> var ;
>

/**
* Другая тестовая функция
*
* Первый параметр должен быть массивом
*/
public function test_array (array $input_array ) <
print_r ( $input_array );
>

/**
* Первый параметр должен быть итератором
*/
public function test_interface ( Traversable $iterator ) <
echo get_class ( $iterator );
>

/**
* Первый параметр должен быть типа callable
*/
public function test_callable (callable $callback , $data ) <
call_user_func ( $callback , $data );
>
>

// Другой тестовый класс
class OtherClass <
public $var = ‘Hello World’ ;
>
?>

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

// Экземпляры каждого класса
$myclass = new MyClass ;
$otherclass = new OtherClass ;

// Ошибка: Аргумент 1 должен быть экземпляром класса OtherClass
$myclass -> test ( ‘hello’ );

// Ошибка: Аргумент 1 должен быть экземпляром класса OtherClass
$foo = new stdClass ;
$myclass -> test ( $foo );

// Ошибка: Аргумент 1 не должен быть null
$myclass -> test ( null );

// Работает: Выводит Hello World
$myclass -> test ( $otherclass );

// Ошибка: Аргумент 1 должен быть массив
$myclass -> test_array ( ‘a string’ );

// Работает: Выводит массив
$myclass -> test_array (array( ‘a’ , ‘b’ , ‘c’ ));

// Работает: Выводит ArrayObject
$myclass -> test_interface (new ArrayObject (array()));

// Работает: Выводит int(1)
$myclass -> test_callable ( ‘var_dump’ , 1 );
?>

Также, контроль типов работает и с функциями:

// Пример класса
class MyClass <
public $var = ‘Hello World’ ;
>

/**
* Тестовая функция
*
* Первый параметр должен быть объект класса MyClass
*/
function myFunction ( MyClass $foo ) <
echo $foo -> var ;
>

// Это работает
$myclass = new MyClass ;
myFunction ( $myclass );
?>

Контроль типов допускает значения NULL:

/* Прием значения NULL */
function test ( stdClass $obj = NULL ) <

Как оценить качество кода (если вы не разработчик)

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

Как же понять насколько хорош тот код, с которым вы имеете дело?

Оценка качества кода

Есть ресурсы, которые помогают проводить анализ. Например:

  • phpcodechecker.com для php
  • Markup Validation Service для HTML
  • CSS Validation Service для CSS
  • Браузерные расширения для разработчиков — Firefox, Chrome и Opera предлагают полезные инструменты, в т. ч. быстрые ссылки на валидаторы

Также можно воспользоваться автоматизированными средствами проверки кода:

Проверка кода — один из способов контроля качества ПО наряду с разными видами тестирования и проверки на соответствия требованиям в спецификации.

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

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


Еще один параметр, на который можно ориентироваться — выбор инструментов разработки. Современные фреймворки, например Laravel для php, Angular.js и React.js на JavaScript, JSONModel и MagicalRecord для iOS, и т.д. Выбирая библиотеки и языки, мы предлагаем клиентам проверенные, но современные варианты, которые лучше всего подходят для решения конкретных задач.

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

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

Оценка качества ПО

Для определения качества программного обеспечения используются стандарты ISO (ISO/IEC 25010:2011 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models), учитывающие следующие факторы:

  1. Фунцкиональность:
    • Работоспособность
    • Соответствие стандартам
    • Функциональная совместимость
    • Безопасность
    • Точность
  2. Надежность:
    • Завершенность
    • Возможности восстановления
    • Устойчивость к ошибкам
  3. Удобство использования:
    • Простота обучения
    • Интуитивность
    • Дружественность к пользователю
  4. Эффективность:
    • Эффективное использование времени
    • Эффективное использование ресурсов
  5. Поддержка / Обслуживание:
    • Стабильность
    • Возможность анализа
    • Управляемость
    • Изменяемость
  6. Переносимость:
    • Простота установки
    • Заменяемость
    • Совместимость

Оценивая качество приложения, обратите внимание на следующие факторы:

  • Соответствие спецификации (SRS)
  • Отсутствие багов (ошибок)
  • Стабильная работа при высоких нагрузках
  • Отсутствие уязвимостей
  • Скорость работы

Как проверить соответствие указанным критериям?

  • Провести тестирование (можно разработать свои тесты или нанять стороннего эксперта). Если приложение работает стабильно, нет критичных ошибок — значит, его можно считать качественным.
  • Второй подход требует анализа кода. Это нужно в случае замены разработчика на проекте. Например, готовое ПО передаётся вашей команде на поддержку. Мы всегда заботимся о том, чтобы с нашим кодом команде заказчика работать было легко и удобно.

В конце концов, ключевой параметр при оценке качества — соответствие требованиям и стабильная, безошибочная работа приложения.

Проверка качества программного кода с помощью PHPmetrics

физико-математические науки

  • Белоножкин Антон Валерьевич , студент
  • Волгоградский государственный технический университет
  • Рыбанов Александр Александрович , кандидат наук, доцент, заведующий кафедрой
  • Волжский политехнический институт (филиал) Волгоградский государственный технический университет
  • Похожие материалы

    Введение

    Разработанный проект необходимо протестировать на качество кода, при наличии недостатков устранить проблемы. Так как система представляет собой веб-страницу, необходимо протестировать корректность верстки и совместимость с различными версиями браузеров.[1,2,4] Для серверной и клиентской части нужно замерить использование ресурсов системой.

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

    • Сложность кода. Характеристика, от которой напрямую зависит сложность поддержки кода. Она зависит от количества вложенных операторов ветвления и циклов. Чем индекс ниже, тем лучше, и тем легче в будущем будет менять структуру кода. Цикломатическая сложность, по сути показывает количество всевозможных путей, по которым можно пройти логику скрипта. Чем больше путей, тем выше сложность файла[7,8].
    • Дубликаты. Метрику можно означить в процентах как соотношение строк дубликатов к всем строкам кода.
    • Комментирование. Данная характеристика показывает, насколько код описан и от комментирован.

    Код проекта состоит из PHP, JavaScript и HTML/CSS составляющих. Метрики можно вычислить для языков программирования PHP и JavaScript. Так как объем JavaScript кода незначителен, будут вычислены метрики для PHP.[9,10]

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

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

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

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

    После загрузки проекта в данную систему был получен отчет (рис. 1).

    Рисунок 1. Отчет PhpMetrics до оптимизации.

    В отчете на рисунке 1 PhpMetrics построил график с цифровым кодированием, который обозначает сложность и количество файлов в проекте (пункт Evaluation), и график цикломатической сложности (Lcom / CyclomaticComplexity).

    На графике Evaluation каждый круг обозначает файл, его размер – количество строк кода (чем больше строк, тем больше круг), его цвет – цикломатическую сложность (сложный файл имеет красный цвет, несложный – зеленый).

    На графике Lcom / CyclomaticComplexity каждая точка обозначает определенный класс. На оси Y обозначена цикломатическая сложность, на оси X – зависимость классов друг от друга.

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

    Также, с помощью PhpMetrics была построена следующая сводка (рис. 2)

    Рисунок 2. Сводка метрик PhpMetrics.

    Наиболее важные параметры в сводке, представленной на рисунке 2:

    • LOC (LinesOfCode) – количество строк кода
    • LLOC (LinesOfLogicalCode) – количество логических строк кода
    • CommW (CommentaryWeight) – процент откомментированных строк кода
    • CC (CyclomaticComplexity) – цикломатическая сложность
    • Vocabulary (HalsteadVocabulary) – метрика кода, вычисляется как сумма количества операторов и операндов

    Выбранная стратегия оптимизации кода:

    1. Поиск и отключение неиспользуемых библиотек или их компонентов. Для этого необходимо построить дерево зависимости классов и посмотреть, какие из них остаются неиспользованными.
    2. Упрощение сложных классов и методов путем разбиения их на более малые и простые части. Сложные классы неудобны для дальнейшей поддержки и модификации, такие классы необходимо разбить на подклассы. Большие методы также нужно разделить на подметоды.
    3. Уменьшение числа строк кода путем совершенствования конструкций в коде. Например, использование switch вместо if/elseif, не объявлять отдельно константы, если они используются единожды, не создавать блок else, если в блоке if есть return и тому подобные мелкие оптимизации.

    В итоге, после проведения оптимизации по выбранной стратегии, снова был построен отчет в PhpMetrics. (рис. 3)

    Рисунок 3. Отчет PhpMetrics после оптимизации.

    На рисунке 3 явно видно, что в блоке Evaluation стало намного меньше больших и сложных с точки зрения программного кода файлов (рис. 4).

    Рисунок 4. Результат оптимизации. Evaluation.

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

    Рисунок 5. Результат оптимизации. Lcom / CyclomaticComplexity.

    На рисунке 5 можно увидеть, что цикломатическая сложность и зависимость классов значительно снизилась.

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

    Список литературы

    1. Азаров А.В., Рыбанов А.А. Автоматизированная система расчета метрических характеристик физической схемы базы данных с целью оценки трудоемкости процесса проектирования//Современная техника и технологии. 2014. № 5 (33). С. 39.
    2. Кузьмин А.А., Рыбанов А.А. исследование методов количественной оценки схем реляционных баз данных//Успехи современного естествознания. 2011. № 7. С. 137-138.

    3. Морозов А.О., Рыбанов А.А. Разработка автоматизированной системы расчета метрических характеристик mysql базы данных на основе концептуального графа физической схемы//NovaInfo.Ru. 2015. Т. 2. № 34. С. 34-48.
    4. Рыбанов А.А. Анализ базовых возможностей программных продуктов для исследования метрических характеристик баз данных//NovaInfo.Ru. 2015. Т. 2. № 33. С. 20-28.
    5. Рыбанов А.А. Оценка сложности физической схемы реляционной базы данных//Современная техника и технологии. 2014. № 9 (37). С. 26-30.
    6. Мейер, Бертран. Объектно-ориентированное конструирование программных систем / Б. Мейер. – М. : Издательско-торговый дом «Русская редакция», 2005.
    7. Фаулер, Мартин. Рефакторинг. Улучшение существующего кода / М. Фаулер. – СПб. : Символ–Плюс, 2003.
    8. Спольски, Джоэл. Джоэл о программировании / Д. Спольски. – СПб. : Символ–Плюс, 2006.
    9. Макконнелл, С. Совершенный код. Мастер-класс / С. Макконнелл. – М. : Издательско-торговый дом «Русская редакция»; СПб. : Питер, 2005.

    Электронное периодическое издание зарегистрировано в Федеральной службе по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзор), свидетельство о регистрации СМИ — ЭЛ № ФС77-41429 от 23.07.2010 г.

    Соучредители СМИ: Долганов А.А., Майоров Е.В.

    Как настроить VS Code для разработки на PHP

    Создание удобного рабочего окружения.

    Содержание

    Visual Studio Code – популярный бесплатный редактор кода. Может с легкостью конкурировать с PhpStorm, ведь он бесплатный и с открытым исходным кодом

    Так может выглядеть интерфейс редактора после установки расширений

    Основные возможности

    • отладчик кода
    • встроенный терминал
    • удобные инструменты для работы с Git
    • подсветка синтаксиса для множества популярных языков и файловых форматов
    • удобная навигация
    • встроенный предпросмотр Markdown
    • умное автодополнение
    • встроенный пакетный менеджер

    VS Code имеет большое количество расширений для разработчика. Для установки нового пакета зайдите во вкладку “Extensions”, введите название пакета в строке поиска, нажмите кнопку “Install”.

    EditorConfig for VS Code

    EditorConfig — это конфигурационный файл и набор расширений к большому количеству редакторов кода. Он подхватывает настройки из файла .editorconfig , который, как правило, размещается в корне проекта. Расширение автоматически настроит отступы и перевод строк единообразно для всех разработчиков, использующих его. PHP код чаще всего выполняется на *nix системах, поэтому необходимо использовать стандарт.

    Ниже приводится пример файла .editorconfig , который используется в Laravel:

    PHP Intelliphense

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

    Чтобы подсказки не дублировались необходимо отключить встроенную в редактор поддержку кода для PHP: Extensions -> Search @builtin php -> PHP Language Features -> Disable

    PHP Debug

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

    Чтобы воспользоваться PHP Debug, необходимо установить сам XDebug, без него расширение для редактора работать не будет. Установив расширение, необходимо добавить конфигурацию для PHP в разделе Debug . После выбора языка в корне проекта будет создан файл .vscode/launch.json с задачами для Дебаггера. Расширение создаст файл со стандартными параметрами.

    Для того, чтобы XDebug общался с нашим дебаггером, необходимо добавить настройки в файл конфигурации php. Чтобы найти этот файл выполните в терминале команду php —ini или запустите веб-сервер с кодом phpinfo() .

    В Linux PHP подгружает не только основной файл, но и файл из этой директории. Например, на Ubuntu путь к директории конфигурационных файлов для PHP может быть таким — /etc/php/7.3/cli/conf.d/ . В ней создаём файл с необходимыми правами (требуются root права):

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

    PHP Sniffer

    В языках программирования есть понятие стиль кодирования. Но не все разработчики знают об этом. Программа, которая отвечает за проверку на соответствие стандартам, называется линтер. В PHP приняты стандарты под названием PSR. Нас интересуют стандарты PSR-1 и PSR-12. Именно эти два стандарта касаются кодирования и правил оформления.

    В PHP в качестве линтера используется PHP_CodeSniffer. Для его работы необходимо установить глобально сам линтер composer global require «squizlabs/php_codesniffer=*» и расширение PHP Sniffer.

    Проверьте, что линтер установился:

    Выполнить проверку кода в терминале можно с помощью команды phpcs , явно указав стандарт, который мы хотим использовать, и путь для проверки:

    Semicolon Insertion Shortcut

    PHP требует разделять инструкции с помощью точки запятой. Расшрение Semicolon Insertion Shortcut добавляет необходимый символ в конец строки с помощью шортката. Если при нажатии [Ctrl] + ; символ не вставляется, то необходимо проверить список горячих клавиш и при необходимости назначить комбинацию вручную: File -> Preferences -> Keyboard Shortcuts

    Extra

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

    GitLens — в VS Code уже встроена поддержка Git. Но когда базовых возможностей становится недостаточно, на помощь может придти Gitlens. Например, одна из полезных фич — git blame на текущей строке.

    Indent Rainbow — разноцветные отступы в коде. Подсвечивает некорректный отступ. Можно вместо радуги установить оттенки серого.

    Settings Sync — плагин, позволяющий синхронизировать настройки редактора между разными компьютерами. В качестве облачного хранилища используется Github Gists. Все настройки можно скачать, указав нужный файл синхронизации.

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

    Статический и динамический анализ php-кода

    Автоматический анализ кода ( static code analysis ) очень полезен на больших проектах и он часто встраивается в серверы непрерывной интеграции. Некоторые IDE уже поставляются с простыми аналитическими инструментами, но первые всё-таки предпочтительней, потому что туда смотрит вся комманда. Всё что этот софт делает это периодически смотрит в систему версионирования (SVN) и строит график качества (и например запускает юнит-тесты). По сути это аналог комплекса упражнений для человека, поддерживающих хорошее здоровье и бъющих тревогу если возникает рак спагетти-кода.

    Самые известные CI-серверы:

    • Hudson и его бесплатный двойник Jenkins (на java, много модулей) → есть шаблон
    • CruiseContro l
    • Atlassian Bamboo
    • Jetbrains TeamCity
    • BuildBot
    • Xinc
    • Arbit (включает в себя project management и bugtracker)

    Статический анализ кода и его метрики

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

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

    Размерные метрики

    Метрики наследования

    Метрики сложности


    • CF — фактор связанности двух классов (т.е. один класс вызывает или использует методы/свойства другого класса) = число вызовов / максимальное число вызовов (значение от 0 до 1)
    • CALLS — число вызовов методов
    • FANOUT- число (вызываемых ) классов → (fin+fout)2 * len
    • Структурная сложность = CALLS 2
    • Сложность данных SC = IOvar / (CALLS +1)
    • Цикломатическая сложность CC = число решений / число строк (Java = 0.2, C++ = 0.25). Разные научные определения (Halstead, McCabe, McClure)
    • Системная сложность: SYSC = SC + SD

    Некоторые программы ещё измеряют степень безопасности через число точек прямого входа, т.е. использования параметров GET, POST, SESSION, FILE.

    Инструменты

    Для php таких аналитических программ относительно мало — есть консольные узкоспециализированные программки:

    • Depend — использует некоторые приведённые выше метрики для анализа сложности pdepend —overview-pyram >pdepend —jdepend-xml=out.xml my_project_namedependencies.php out.xml -o out3.svg
    • Mess detector — ищет неиспользуемый код и сложные выражения phpmd my_project_name text phpmd.xml
    • Code sniffer — проверяет названия методов и переменных согласно правилам из XML-файла настроек phpcs —standard=CodeREview —report-source my_project_name
    • Dead code detector ищет невызываемый код
    • Copy-paste detector
    • phploc — оценивает размер
      phploc my_project_name
    • PHPLint — проверяет синтаксис и генерирует документацию
    • Analzer for Type Mismatches — ищет возможные ошибки с несовместимостью типов

    Ещё есть чуть более общие PMD (на java) и phpsat, специализированные RIPS, RATS (как вариант Fortify360 + Jenkins), Yasca, Pixy и агрегаторы всего что только можно — PHPUnit, PHPLint, Sonar

    Динамический анализ кода

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

    • Покрытие кода тестами (Statement, Branch, Path coverage)
    • Граф скорости загрузки и использования памяти в зависимости от методов

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

    В интернете очень много устаревшей информации, которая приводит к заблуждению, распространению неверных решений и написанию плохого кода у начинающих 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:

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

    30+ лучших приемов PHP для начинающих

    Дата публикации: 2010-04-14

    От Автора: PHP – самый широко используемый в Сети язык программирования. Представляем тридцать с небольшим лучших приемов для новичков, желающих приобрести основные навыки — php для начинающих.

    1. Подружитесь со справочником по PHP

    Если вы новичок в PHP, значит, пришло время познакомиться с внушающим почтение справочником PHP. Справочник по PHP невероятно исчерпывающий и содержит действительно полезные комментарии к каждой статье. Перед тем, как задавать вопросы или пытаться самостоятельно разрешить проблему, сэкономьте время и просто возьмите курс на справочник. Ответы на ваши вопросы уже удобно разместились в полезной статье на сайте PHP.net.
    В данном случае мы Вам рекомендуем поискать самостоятельно справочники на русском языке, лучше php для начинающих. Будем рады, если Вы дадите ссылке на полезные справочники в комментариях к статье (Просто учитывайте, что это перевод статьи).

    2. Включите отчет об ошибках

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

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

    3. Попробуйте IDE

    IDE (Integrated Development Environments/интегрированные среды разработки) – полезные инструменты для любого разработчика. Хотя они подойдут не для каждого, IDE определенно имеют свое значение. IDE обеспечивают такие инструменты, как:

    Как создать сайт самому?

    Какие технологии и знания необходимы сегодня, чтобы создавать сайты самостоятельно? Узнайте на интенсиве!

    Code completion (подсказки идентификаторов в редакторе кода)

    Предупреждения об ошибках

    Рефакторинг кода (переделка кода)

    А также большое количество других возможностей. Существует множество отличных IDE, поддерживающих PHP.

    4. Попробуйте PHP-frameworks

    Вы можете многое узнать о PHP, просто экспериментируя с PHP-фреймворками. Такие фреймворки, как CakePHP или CodeIgniter, позволяют быстро создавать приложения PHP, даже если вы в нем не эксперт. В каком-то смысле они – дополнительные подпорки, которые показывают вам, каким образом должно выглядеть приложение PHP, и демонстрируют полезные концепции программирования (вроде отделения логики от дизайна и т.д.).

    Возражение: лично я не советую новичкам пользоваться фреймворками. Сначала выучите основы.

    5. Научитесь DRY

    DRY – аббревиатура от Don’t Repeat Yourself, (Не Повторяйтесь), и это – полезная концепция программирования, без разницы на каком языке. DRY-программирование, как предполагается названием, гарантирует, что вы не пишете избыточного кода. Вот пример от Reinhold Weber:

    теперь применением к нему подход DRY:

    Более подробно о концепции DRY можно прочесть здесь и здесь.

    6. Делайте отступы и используйте пробелы в коде для читаемости

    Если вы не используете отступы и пробелы в коде, то результат выглядит, как картина Джексона Поллака (Jackson Pollack). Обеспечьте читаемость своего кода и нормальный поиск, потому что почти наверняка в будущем вы будете делать в нем изменения. IDE и современные текстовые редакторы могут автоматически делать отступы в коде.

    7. Делайте код многоуровневым

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

    8. Всегда используйте

    Часто программисты пытаются использовать сокращения в операторах PHP. Вот как это обычно делается:

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

    9. Используйте содержательные, последовательные названия

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

    10. Комментируйте, комментируйте, комментируйте

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

    11. Установите MAMP/WAMP

    MySQL — самый популярный вид базы данных, используемый с PHP (хотя и не единственный). Если нужно настроить локальное окружение для разработки и тестирования ваших PHP-приложений на компьютере, предусмотрите установку MAMP (Mac) или WAMP (Windows). Установка MySQL на ваш собственный компьютер может стать утомительным процессом, а оба этих программных пакета содержат MySQL. Ловко и просто.

    12. Установите лимиты своим скриптам

    Установка лимита времени на PHP-скрипты – очень ответственная вещь. Бывают моменты, когда скрипты выходят из строя, и когда это произойдет, вам придется использовать свойство set_time_limit (установить лимит времени), чтобы избежать бесконечно повторяющихся циклов и истечения таймаутов времени соединения с базой данных. Set_time_limit устанавливает лимит времени на максимальное количество секунд, за которое выполняется скрипт (по умолчанию 30). По истечении этого времени возбуждается неустранимая ошибка.

    13. Используйте объекты (или ООП)

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

    14. Поймите разницу между одинарными и двойными кавычками

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

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

    15. Не ставьте phpinfo() в свой Webroot

    Phpinfo – чудесная вещь. Просто создав PHP-файл, в котором есть:

    Статический и динамический анализ php-кода

    Автоматический анализ кода ( static code analysis ) очень полезен на больших проектах и он часто встраивается в серверы непрерывной интеграции. Некоторые IDE уже поставляются с простыми аналитическими инструментами, но первые всё-таки предпочтительней, потому что туда смотрит вся комманда. Всё что этот софт делает это периодически смотрит в систему версионирования (SVN) и строит график качества (и например запускает юнит-тесты). По сути это аналог комплекса упражнений для человека, поддерживающих хорошее здоровье и бъющих тревогу если возникает рак спагетти-кода.

    Самые известные CI-серверы:

    • Hudson и его бесплатный двойник Jenkins (на java, много модулей) → есть шаблон
    • CruiseContro l
    • Atlassian Bamboo
    • Jetbrains TeamCity
    • BuildBot
    • Xinc
    • Arbit (включает в себя project management и bugtracker)

    Статический анализ кода и его метрики

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

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

    Размерные метрики

    Метрики наследования

    Метрики сложности

    • CF — фактор связанности двух классов (т.е. один класс вызывает или использует методы/свойства другого класса) = число вызовов / максимальное число вызовов (значение от 0 до 1)
    • CALLS — число вызовов методов
    • FANOUT- число (вызываемых ) классов → (fin+fout)2 * len
    • Структурная сложность = CALLS 2
    • Сложность данных SC = IOvar / (CALLS +1)
    • Цикломатическая сложность CC = число решений / число строк (Java = 0.2, C++ = 0.25). Разные научные определения (Halstead, McCabe, McClure)
    • Системная сложность: SYSC = SC + SD

    Некоторые программы ещё измеряют степень безопасности через число точек прямого входа, т.е. использования параметров GET, POST, SESSION, FILE.

    Инструменты

    Для php таких аналитических программ относительно мало — есть консольные узкоспециализированные программки:

    • Depend — использует некоторые приведённые выше метрики для анализа сложности pdepend —overview-pyram >pdepend —jdepend-xml=out.xml my_project_namedependencies.php out.xml -o out3.svg
    • Mess detector — ищет неиспользуемый код и сложные выражения phpmd my_project_name text phpmd.xml
    • Code sniffer — проверяет названия методов и переменных согласно правилам из XML-файла настроек phpcs —standard=CodeREview —report-source my_project_name
    • Dead code detector ищет невызываемый код
    • Copy-paste detector
    • phploc — оценивает размер
      phploc my_project_name
    • PHPLint — проверяет синтаксис и генерирует документацию
    • Analzer for Type Mismatches — ищет возможные ошибки с несовместимостью типов

    Ещё есть чуть более общие PMD (на java) и phpsat, специализированные RIPS, RATS (как вариант Fortify360 + Jenkins), Yasca, Pixy и агрегаторы всего что только можно — PHPUnit, PHPLint, Sonar

    Динамический анализ кода

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

    • Покрытие кода тестами (Statement, Branch, Path coverage)
    • Граф скорости загрузки и использования памяти в зависимости от методов
    Мастер Йода рекомендует:  Главные изменения в алгоритме Google
Добавить комментарий