Еще 7 ошибок, обычно совершаемых разработчиками PHP

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

Я призываю вас внимательно прочитать его — он содержит действительно ценную информацию, о которой вам следует знать, особенно первые восемь пунктов. Пару дней назад Анна Филина пополнила список семью новыми записями. Хотя она менее конкретна и распространена, ее очки все же имеют вес и должны учитываться при развитии.

Еще 7 ошибок часто делают PHP-разработчики

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

1. Использование расширения mysql

Эта новость довольно старая, но количество разработчиков, не замечающих этого факта, вызывает беспокойство. При использовании баз данных SQL, в частности MySQL, слишком много разработчиков по-прежнему выбирают расширение mysql. Расширение mysql официально устарело . Это небезопасно, ненадежно, не поддерживает SSL и отсутствует некоторые современные функции MySQL. Он также генерирует уведомления об устаревании, которые не нарушают ваше приложение, они просто появляются в верхней части вашего приложения. Весело, что это означает, что также возможно просто Google для всех различных сайтов, которые используют эту небезопасную настройку, просто ища это . Мир вреда, которому подвергаются эти приложения из-за этого беспорядка, ошеломляет.

Вместо использования mysql, выберите одну из альтернатив: MySQLi или PDO. Например, использовать MySQLi вместо этого почти так же просто, как добавить букву «i» в конце вызовов API:

$c = mysql_connect ( "host" ,   "user" ,   "pass" ); mysql_select_db ( "database" ); $result = mysql_query ( "SELECT * FROM posts LIMIT 1" ); $row = mysql_fetch_assoc ( $result ); 

против

 $mysqli =   new  mysqli ( "host" ,   "user" ,   "pass" ,   "database" ); $result =  $mysqli -> query ( "SELECT * FROM posts LIMIT 1" ); $row =  $result -> fetch_assoc (); 

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

Вы должны выбрать PDO, хотя. Подробнее об этом в пункте 2.

2. Не использовать PDO

Не поймите меня неправильно, mysqli (буквально) на несколько поколений впереди древнего расширения mysql. Это обновлено, безопасно, надежно и быстро. Тем не менее, это специфично для mysql. Вместо этого использование PDO позволит вам использовать удивительно практичный объектно-ориентированный синтаксис и подготовит вас к танго с другими базами данных SQL, такими как PostgreSQL, MS SQL и другими. Более того, PDO позволит вам использовать именованные параметры , такую ​​полезную функцию, что мало кто может представить, что может пойти на что-то еще после того, как правильно им воспользуется. И последнее, но не менее важное: вот что вы можете вставить извлеченные данные непосредственно в новый объект, что позволяет сэкономить время в больших проектах.

3. Не переписывать URL

Еще одна обычно игнорируемая и легко решаемая проблема. Такие URL, как myapp.com/index.php?p=34&g=24 , просто недопустимы в myapp.com/index.php?p=34&g=24 время. Из-за того, что было невероятно сложно написать хорошее руководство по перезаписи URL, которое охватывало бы каждый сервер и инфраструктуру, почти в каждой среде есть руководство по настройке чистых URL ( Laravel , Phalcon , Symfony , Zend ) и любые, которые не Это просто не стоит использовать — они, очевидно, не заботятся о современных методах.

4. Подавление ошибок

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

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

Недавно мы рассмотрели некоторые дополнения Heroku для готовых приложений PHP, и одним из них был превосходный Papertrail — дополнение, которое позволяет перенести все ошибки вашего приложения на их серверную часть для упрощения поиска, группировки и устранения в дальнейшем; так что даже если некоторые ошибки действительно случаются, лучше позволить им регистрироваться и избавляться от них, исправляя ваш код, чем заглушать их и играть глупо перед вашими пользователями.

5. Назначение в условиях

Даже опытные разработчики иногда просто щелкают пальцем и пишут if ($condition = 'value') { вместо if ($condition == 'value') { . Наши руки соскользнут, наши клавиатуры не будут регистрировать нажатие клавиш, в итоге мы вставим из другой части кода, где фактически произошло присвоение — это происходит, и мы обычно узнаем только при запуске приложения.