Здесь, на Wptuts +, мы много говорим о «как» и меньше о «почему». Конечно, мы учебный сайт, так что это цель, верно? Итак, в продолжение статьи прошлого месяца « Кардинальные грехи разработки плагинов WordPress », сегодня мы рассмотрим несколько практик, которые, если бы каждый разработчик следовал, сделали бы мир лучше (ну, по крайней мере, наш мир!).
В прошлом месяце мы рассмотрели несколько вещей, которых следует избегать при работе с WordPress Development. Основываясь на ответе — который был звездным — мы решили взглянуть на некоторые подобные святости качества разработчиков WordPress.
Конечно, весь заголовок немного дурацкий, но пункты, упомянутые в статье, — нет! Стремитесь к следующим качествам в вашей разработке WordPress, и вы заметите, что они окупаются дивидендами не только в ваших навыках разработки, но и в отдаче сообществу WordPress в целом.
Священная практика 01: следуйте инструкциям по программированию
Ты будешь следовать кодексу … Хорошо, шучу в сторону, хотя и по какой-то причине!
Для любого, кто работал в разработке WordPress в течение длительного периода времени, вполне вероятно, что ваш код со временем становится все более и более стандартизированным. Под этим я подразумеваю, что ваши более ранние проекты считались «выполненными», когда тема или плагин просто работали, тогда как ваши более поздние проекты обычно состоят из более чистого кода и использования лучших практик.
Но как насчет тех, кто находится в середине карьеры WordPress? Вы знаете, как работать с WordPress, но вам не хватает рекомендаций других профессионалов WordPress. Проще говоря, что можно сделать, чтобы перейти к следующему шагу?
Попробуйте стандарты кодирования WordPress . Это один из самых низких результатов, доступных в разработке WordPress — его легко понять, легко начать применять, и он может окупиться, когда другие люди начнут использовать и улучшать вашу работу.
Чтобы быть ясным, WordPress не имеет способа действительно применять правила программирования в проектах, которые строятся на его основе. В конце концов, мы имеем дело с интерпретируемым кодом, платформой с открытым исходным кодом и разработчиками, которые варьируются от новичка до профессионала. Но если вы хотите стать лучшим программистом и респектабельным членом сообщества WordPress, необходимо следовать предлагаемым стандартам кодирования — ваш код будет чище, проще в обслуживании и понятен сообществу разработчиков WordPress. в целом
Святая практика 02: документируй свой код
Документирование вашего кода — это нечто большее, чем просто заметки для себя, а то, что сообщество может оставить.
При разработке программного обеспечения существует множество мнений о том, сколько нужно документировать код. Два из наиболее поляризационных являются следующие:
- Не оставляйте комментариев, пусть код будет собственной документацией
- Прокомментируйте как можно больше строк кода
Вообще говоря, я фанат комментирования кода. Я считаю, что есть золотая середина: документируйте все функции, чтобы объяснить, что они делают, и прокомментируйте любые блоки кода, которые могут сбивать с толку.
Я говорю это не только для разработчиков, которые могут взаимодействовать с моим кодом, но и для себя. В конце концов, сколько раз вы оглядывались на код из шести месяцев назад и думали «о чем я думал?» Если вы не можете вспомнить, что делает ваш собственный код, есть ли надежда для других, кто наткнется на него?
Тем не менее, выступая как человек, который проделал значительную часть разработки WordPress, я могу честно сказать, что прокомментированный код не только легче понять, но и экономит время просто потому, что мне не нужно угадывать, что разработчик пытался сделать.
Разве вы не хотели бы, чтобы люди были благодарны за то, что вы объяснили свой код, а не проклинали его, пытаясь понять, как он работает?
Saintly Practice 03: Используйте модульный тест WordPress
Theme Unit test посвящен объединению вашего собственного подхода к кодированию с контентом, которого ожидают все пользователи WordPress.
Если вы создаете WordPress Themes или работаете над плагином, который работает непосредственно с постами, страницами, комментариями или другими подобными атрибутами, рекомендуется проверять его на соответствие всем типам контента. В конце концов, если вы только тестируете предполагаемый кейс вашего проекта, то вы только наполовину тестируете свою работу — пользователи будут сталкиваться с крайними случаями, и вы хотите убедиться, что вы правильно с ними справились!
Войдите в модульный тест WordPress Theme . Это файл экспорта WordPress, предоставленный командой разработчиков WordPress для использования в нашей работе. В частности, он содержит множество постов, пост-типов, страниц, комментариев, обратных ссылок, категорий и т. Д., Которые мы можем импортировать в нашу локальную установку, чтобы использовать для тестирования нашей работы.
Подобно Руководству по программированию, упомянутому выше, это один из самых мощных инструментов, доступных нам как разработчикам: он избавляет нас от необходимости создавать какой-либо тестовый контент, помогает нам оценивать работу и обеспечивает надежный пример использования нашей работы. будет обрабатывать законный пользовательский ввод.
Священная практика 04: отладка, запись, просмотр, повтор
При создании тем и / или плагинов есть ряд утилит, которые помогут вам обеспечить максимально надежный код. В дополнение к использованию модульного теста WordPress, следующие инструменты могут помочь идентифицировать проблемные области в вашем коде — будь то код для WordPress, разметка, вызовы базы данных и т. Д .:
- WP_DEBUG — это параметр, расположенный в файле wp-config.php вашей установки WordPress. При выполнении любой работы по разработке я всегда проверяю, что для этого параметра установлено значение true. Он будет отображать любые предупреждения или ошибки на экране, сгенерированном во время выполнения вашего кода.
- Theme Check и Plugin Check — два плагина, разработанные для обеспечения соответствия вашей темы или плагина стандартам разработки WordPress. В частности, плагины оценивают ваш код на соответствие стандартам обзора WordPress. Каждый из них содержит четкие предупреждения, ошибки и общую информацию о вашем коде.
- Debogger — простой плагин, который захватывает все данные отладки WordPress и распечатывает их в нижнем колонтитуле локальной установки. Он обеспечивает четкое, хорошо отформатированное отображение любых отладочных данных, сгенерированных во время выполнения вашего кода. Для тех, кто заботится о проверке W3C, Debogger также распечатывает информацию проверки.
Хотя они не всегда были частью моего набора инструментов, я проверяю, что они настроены, установлены и работают каждый раз, когда я выполняю любую работу по разработке WordPress. Они невероятно просты в использовании и обеспечивают значительную стоимость усилий, необходимых для их настройки.
Святая практика 05: избегать устаревших функций
Одна из проблем работы с такой платформой, как WordPress, заключается в том, что она постоянно развивается. По большей части, команда разработчиков WordPress отлично справляется с обслуживанием своего API, но, как и в любом другом программном обеспечении, некоторые функции и аспекты API устаревают. Поэтому для нас важно убедиться, что наш код соответствует платформе.
Хотя можно постоянно проливать кодекс для отслеживания устаревших вызовов, гораздо проще использовать плагин Log Deprecated Notices . Подобно инструментам проверки тем и плагинов, упомянутым выше, журнал устаревших вызовов после активации будет регистрировать любые вызовы API, которые делает ваша тема или плагин, а затем предлагает любые альтернативы, которые обновили бы ваш код.
Работа с WordPress — или любой другой платформой, языком программирования или технологией — это бесконечное предприятие. Вы никогда не будете полностью «там». Есть только место для улучшения. Точно так же, как есть ряд кардинальных грехов, которых следует избегать, следует придерживаться нескольких подобных святости качеств.
Этот список не является исчерпывающим — добавьте его в комментарии!