Следующее переиздано из Tech Times # 165 .
Когда я беру интервью у кандидата на должность разработчика PHP в SitePoint, я почти всегда задаю один вопрос, потому что его ответ так много говорит мне о том, какой он программист. Вот вопрос: «Как вы думаете, в чем разница между хорошим PHP-кодом и плохим PHP-кодом?»
Мне нравится этот вопрос, потому что он проверяет не только энциклопедические знания кандидата о функциях PHP. PHP-сертификация Zend хорошо справляется с этой задачей (как, впрочем, и тест, который Yahoo! выдает кандидатам на работу для PHP-разработчиков )
Скорее ответ на этот вопрос говорит мне, испытывал ли, например, PHP-разработчик боль от работы с плохо написанным кодом, унаследованным от неосторожного предшественника, и пойдет ли он на дополнительные усилия, чтобы спасти остальную часть Команда от той же боли.
У меня нет четкого представления об идеальном ответе на вопрос, но я знаю, что мне хотелось бы услышать. Просто с макушки головы:
Хороший код PHP должен быть структурирован . Длинные порции кода можно разбить на функции или методы, которые выполняют подзадачи с помощью простого кода, в то время как неочевидные фрагменты должны быть прокомментированы, чтобы сделать их смысл понятным. Насколько это возможно, вы должны отделить внешний интерфейс HTML / CSS / JavaScript-код от серверной логики ваших приложений. Функции объектно-ориентированного программирования в PHP предоставляют вам особенно мощные инструменты для разбиения ваших приложений на разумные блоки.
Хороший код PHP должен быть последовательным . Независимо от того, подразумевает ли это установку правил для имен переменных и функций, принятие стандартных подходов к повторяющимся задачам, таким как доступ к базе данных и обработка ошибок, или просто обеспечение одинакового отступа всего кода, согласованность облегчает чтение кода для других.
Хороший код PHP должен быть переносимым . PHP имеет ряд функций, таких как магические кавычки и короткие теги, которые могут сломать хрупкий код, когда они включены или выключены. Однако, если вы знаете, что делаете, вы можете написать работающий код, адаптируясь к своей среде.
Хороший код PHP должен быть безопасным . Хотя PHP предлагает отличную производительность и гибкость из коробки, он оставляет важные вопросы, такие как безопасность, полностью в руках разработчика. Глубокое понимание потенциальных дыр в безопасности, таких как межсайтовый скриптинг (XSS), подделка межсайтовых запросов (CSRF), уязвимости внедрения кода и лазейки в кодировке символов, сегодня очень важно для профессионального разработчика PHP.
Когда кандидат отвечает на этот вопрос, у меня обычно есть довольно хорошее представление о том, будут ли они наняты или нет. Конечно, всегда есть вероятность, что собеседник просто не в состоянии сформулировать подобные вещи, поэтому у нас также есть кандидаты, которые сдают экзамен на PHP.
Многие из вопросов в этом экзамене кажутся простыми на поверхности, но они дают кандидатам много возможностей показать, насколько они заботятся о маленьких деталях.
Следующий «плохой» код — очень упрощенный пример того, что мы могли бы поставить на экзамене PHP для разработчиков. Вопрос может быть что-то вроде «Как бы вы переписали этот код, чтобы сделать его лучше?»
<? echo("<p>Search results for query: " . $_GET['query'] . ".</p>"); ?> Основная проблема в этом коде заключается в том, что пользовательское значение ( $_GET['query'] ) выводится непосредственно на страницу, что приводит к уязвимости межсайтового скриптинга (XSS). Но есть много других способов, которыми это может быть улучшено.
Итак, на какой ответ мы надеемся?
Хорошо:
<? echo("<p>Search results for query: " . htmlspecialchars($_GET['query']) . ".</p>"); ?>
Это наименьшее, чего мы ожидаем. Уязвимость XSS была исправлена с помощью htmlspecialchars чтобы избежать опасных символов в переданном значении.
Лучше:
<?php if (isset($_GET['query'])) { echo '<p>Search results for query: ', htmlspecialchars($_GET['query'], ENT_QUOTES), '.</p>'; } ?>
Теперь это похоже на кого-то, кого мы могли бы нанять:
- «Короткий» открывающий тег PHP (
<?) Был заменен более переносимой (и дружественной к XML) формой<?php. - Прежде чем пытаться вывести значение
$_GET['query'],issetиспользуется для проверки того, что оно действительно имеет значение. - Ненужные скобки (
()) вокруг значения, переданногоecho, были удалены. - Строки разделяются одинарными кавычками вместо двойных кавычек, чтобы избежать снижения производительности при поиске переменных PHP для интерполяции внутри строк.
- Вместо того, чтобы использовать оператор конкатенации строк (
.) Для передачи одной строки в операторecho, строки, которые должны выводиться с помощьюecho, разделяются запятыми для небольшого повышения производительности. - Передача аргумента
htmlspecialcharsдля гарантии того, что одинарные кавычки (') также экранированы, не является строго обязательной в этом случае, но это хорошая привычка.
Несколько досадно, что число разработчиков PHP, которые ищут работу, способную дать вполне удовлетворительный ответ на этот вопрос — по крайней мере, здесь, в Мельбурне, — мало и далеко друг от друга. Мы потратили три месяца на собеседование на эту последнюю должность, прежде чем нашли кого-то, с кем мы были счастливы!
Итак, как бы вы поступили, когда задали такой вопрос? Есть ли какие-то факторы, которые делают PHP-код хорошим или плохим, который, по вашему мнению, я не учел? А что еще вы бы искали в PHP-разработчике?