WordPress родился пятнадцать лет назад, и потому, что он исторически сохранил обратную совместимость, новые версии своего кода не может в полной мере использовать новейшие возможности, предлагаемые новые версии PHP. Хотя последняя версия PHP составляет 7.3.2, WordPress по-прежнему предлагает поддержку до PHP 5.2.4.
Но эти дни скоро закончится! WordPress будет модернизировать свою минимальную поддержку версии PHP, натыкаясь до PHP 5.6 в апреле 2019 года, и PHP 7 в декабре 2019 года (если все пойдет по плану). Затем мы можем, наконец, начать использовать императивные возможности программирования PHP, не опасаясь взлома сайтов наших клиентов. Ура!
Потому что WordPress ‘пятнадцать лет функционального кода повлияли, как разработчики построили с WordPress, наши сайты, темы и плагины могут быть усеяны менее чем оптимальным кодом, который может с удовольствием получить обновление.
Эта статья состоит из двух частей:
-
Наиболее актуальные новые функции
Дополнительные функции были добавлены в версии PHP 5.3, 5.4, 5.5, 5.6 и 7.0 (обратите внимание, что PHP 6)исследуем наиболее актуальные из них. -
Создание лучшего программного обеспечения
Мы рассмотрим эти функции и то, как они могут помочь нам создать лучшее программное обеспечение.
Начнем с изучения «новых» функций PHP.
Классы, OOP, SOLID и шаблоны дизайна
Классы и объекты были добавлены в PHP 5, так WordPress уже использует эти функции, однако, не очень широко или всесторонне: парадигма кодирования в WordPress в основном функционального программирования (выполнение вычислений по вызов функций, лишенных состояния приложения) вместо объектно-ориентированного программирования (OOP) (выполнение вычислений путем манипулирования состоянием объектов). Поэтому я также описываю классы и объекты и как их использовать через OOP.
ООП идеально подходит для создания модульных приложений: Классы позволяют создавать компоненты, каждый из которых может реализовать определенную функциональность и взаимодействовать с другими компонентами, и может обеспечить настройку через свои инкапсулированные свойства и наследования,что позволяет высокую степень повторного использования кода. Как следствие, приложение дешевле тестировать и поддерживать, так как отдельные функции могут быть изолированы от приложения и рассматриваться самостоятельно; есть также повышение производительности, поскольку разработчик может использовать уже разработанные компоненты и избежать изобретать колесо для каждого приложения.
Класс имеет свойства и функции, которые могут быть даны видимость с помощью private (доступны только из определяющего класса), protected (доступны из определяющего класса и его предка и наследственных классов) и public (доступны отовсюду). Из функции мы можем получить доступ к свойствам класса, предусмотив их $this-> имена:
class Person {
protected $name;
public function __construct($name) {
$this->name = $name;
}
public function getIntroduction() {
return sprintf(
__('My name is %s'),
$this->name
);
}
}
Класс мгновенно превращается в объект через new ключевое слово, после чего мы можем получить доступ к его свойствам и функциям -> через:
$person = new Person('Pedro');
echo $person->getIntroduction();
// This prints "My name is Pedro"
Наследуемый класс может переопределить public и protected функции из своих классов предков, и получить доступ к функциям предка, предусмотив их parent:: с:
class WorkerPerson extends Person {
protected $occupation;
public function __construct($name, $occupation) {
parent::__construct($name);
$this->occupation = $occupation;
}
public function getIntroduction() {
return sprintf(
__('%s and my occupation is %s'),
parent::getIntroduction(),
$this->occupation
);
}
}
$worker = new WorkerPerson('Pedro', 'web development');
echo $worker->getIntroduction();
// This prints "My name is Pedro and my occupation is web development"
Метод может быть abstract сделан, что означает, что он должен быть реализован наследственным классом. Класс, содержащий abstract метод, должен быть сделан abstract сам, что означает, что он не может мгновенно; только класс, реализующий абстрактный метод, может быть мгновенно:
abstract class Person {
abstract public function getName();
public function getIntroduction() {
return sprintf(
__('My name is %s'),
$this->getName()
);
}
}
// Person cannot be instantiated
class Manuel extends Person {
public function getName() {
return 'Manuel';
}
}
// Manuel can be instantiated
$manuel = new Manuel();
Классы также могут определить static методы и свойства, которые живут под самим классом, а не под моментионированием класса как объекта. К ним обращаются self:: из класса, а также через название :: класса- из-за него:
class Factory {
protected static $instances = [];
public static function registerInstance($handle, $instance) {
self::$instances[$handle] = $instance;
}
public static function getInstance($handle) {
return self::$instances[$handle];
}
}
$engine = Factory::getInstance('Engine');
Чтобы максимально использовать принципы ООП, мы можем использовать принципы SOLID для создания прочной, но легко настраиваемой основы для приложения, и шаблоны проектирования для решения конкретных проблем проверенным и проверенным способом. Шаблоны проектирования стандартизированы и хорошо документированы, что позволяет разработчикам понять, как различные компоненты в приложении связаны друг с другом, и обеспечить способ структурировать приложение упорядоченным образом, что помогает избежать использования глобальных переменных (таких global $wpdb как), которые загрязняют глобальную окружающую среду.
Пространства имен
Namespaces были добавлены к PHP 5.3, следовательно, они в настоящее время отсутствует вообще из WordPress ядра.
Namespaces позволяют организовывать кодовую базу структурно, чтобы избежать конфликтов, когда разные элементы имеют одно и то же имя — по аналогии с каталогами операционных систем, которые позволяют иметь разные файлы с тем же именем, пока они хранятся в разных Каталоги. Namespaces делают один и тот же трюк инкапсуляции для элементов PHP (таких как классы, черты и интерфейсы), избегая столкновений, когда разные элементы имеют одно и то же имя, размещая их на разных пространствах имен.
Именные пространства являются обязательными при взаимодействии с сторонними библиотеками, так как мы не можем контролировать, как будут называться их элементы, что приводит к потенциальным столкновениям при использовании стандартных имен, таких как «File», «Logger» или «Uploader» для наших элементов. Кроме того, даже в рамках одного проекта пространства имен не позволяют названиям классов становиться чрезвычайно длинными, чтобы избежать столкновений с другими классами, что может привести к таким именам, как «MyProject-Controller»FileUpload.
Namespaces определяются с помощью ключевого слова namespace (размещены на линии сразу после <?php открытия) и может охватывать несколько уровней или подименных пространств (по аналогии с наличием нескольких субдиректоров, где размещение файла), которые разделены с помощью :
<?php
namespace CoolSoftImageResizerControllers;
class ImageUpload {
}
Чтобы получить доступ к вышеуказанному классу, мы должны полностью квалифицировать его имя, включая его пространство имен (и начиная с):
$imageUpload = new CoolSoftImageResizerControllersImageUpload();
Или мы также можем импортировать класс в текущий контекст, после чего мы можем ссылаться на класс по его имени напрямую:
use CoolSoftImageResizerControllersImageUpload;
$imageUpload = new ImageUpload();
Называя пространства имен в соответствии с установленными конвенциями, мы можем получить дополнительные преимущества. Например, следуя рекомендации PHP Standards PSR-4,приложение может использовать механизм автоматической загрузки композитора для загрузки файлов, тем самым уменьшая сложность и добавляя беспрепятственную совместимость между зависимостями. Эта конвенция устанавливает для включения имени поставщика (например, название компании) в качестве верхнего поднаимениния, по желанию следует название пакета, и только после чего внутренняя структура, в которой каждое поднаименное пространство соответствует каталогу с тем же Имя. В результате отображается физическое местоположение файла в диске с пространством имен элемента, определяемого в файле.
Черты
Трассы были добавлены в PHP 5.4, следовательно, они в настоящее время отсутствует вообще из WordPress ядра.
PHP поддерживает одно наследование,поэтому подкласс происходит от одного родительского класса, а не от нескольких. Таким образом, классы, которые не простираются друг от друга, не могут повторно использовать код через наследование классов. Traits — это механизм, позволяющий горизонтально композицию поведения, позволяющий повторно использовать код среди классов, живущих в разных иерархиях классов.
Черта похожа на класс, однако, она не может быть мгновенной сама по себе. Вместо этого код, определяемый внутри черты, можно рассматривать как «копированный и вставленный» в состав класса во время компиляции.
Черта определяется с помощью trait ключевого слова, после чего она может быть импортирована в любой класс через use ключевое слово. В приведенном ниже примере два совершенно не связанных класса Person и могут повторно использовать один и тот же код через Shop Addressable черту:
trait Addressable {
protected $address;
public function getAddress() {
return $this->address;
}
public function setAddress($address) {
$this->address = $address;
}
}
class Person {
use Addressable;
}
class Shop {
use Addressable;
}
$person = new Person('Juan Carlos');
$person->setAddress('Obelisco, Buenos Aires');
Класс также может составить несколько черт:
trait Exportable {
public class exportToCSV($filename) {
// Iterate all properties and export them to a CSV file
}
}
class Person {
use Addressable, Exportable;
}
Трассы также могут состоять из других черт, определить абстрактные методы,и предлагают механизм разрешения конфликта, когда два или более состоит черты имеют то же имя функции, среди других функций.
Интерфейсы
Интерфейсы были добавлены в PHP 5, так WordPress уже использует эту функцию, однако, чрезвычайно экономно: ядро включает в себя менее десяти интерфейсов в общей сложности!
Интерфейсы позволяют создавать код, который определяет, какие методы должны быть реализованы, но без необходимости определять, как эти методы на самом деле реализованы. Они полезны для определения контрактов между компонентами, что приводит к лучшей модульности и удобству обслуживания приложения: класс, реализующий интерфейс, может быть черным ящиком кода, и до тех пор, пока подписи функций в интерфейсе не изменятся , код может быть модернизирован по своему воле, не создавая нарушений, которые могут помочь предотвратить накопление технической задолженности. Кроме того, они могут помочь уменьшить блокировку поставщика, позволяя поменять реализацию некоторого интерфейса на интерфейс другого поставщика. Как следствие, необходимо кодировать приложение в соответствии с интерфейсами вместо реализаций (и определения, которые являются фактическими реализациями через инъекцию зависимости).
Интерфейсы определяются с помощью interface ключевого слова, и должны перечислить вниз только подпись своих методов (т.е. без их содержания определены), которые должны иметь видимость public (по умолчанию, не добавляя видимости ключевое слово также делает его публичным):
interface FileStorage {
function save($filename, $contents);
function readContents($filename);
}
Класс определяет, что он реализует интерфейс через implements ключевое слово:
class LocalDriveFileStorage implements FileStorage {
function save($filename, $contents) {
// Implement logic
}
function readContents($filename) {
// Implement logic
}
}
Класс может реализовать несколько интерфейсов, отделяя их от , :
interface AWSService {
function getRegion();
}
class S3FileStorage implements FileStorage, AWSService {
function save($filename, $contents) {
// Implement logic
}
function readContents($filename) {
// Implement logic
}
function getRegion() {
return 'us-east-1';
}
}
Поскольку интерфейс декларирует намерение того, что компонент должен делать, крайне важно правильно назвать интерфейсы.
Замыкания
Закрытия были добавлены к PHP 5.3, следовательно, они в настоящее время отсутствует вообще из WordPress ядра.
Закрытие — это механизм для реализации анонимных функций,который помогает отсеить глобальное пространство имен из одноразовых (или редко используемых) функций. Технически говоря, замыкания являются экземплярами Closure класса, однако на практике мы, скорее всего, можем быть в блаженном неведении об этом факте без какого-либо вреда.
Перед закрытием, при передаче функции в качестве аргумента другой функции, мы должны были определить функцию заранее и передать ее название в качестве аргумента:
function duplicate($price) {
return $price*2;
}
$touristPrices = array_map('duplicate', $localPrices);
При замыкании функции анонимной (т.е. без имени) уже можно передавать непосредственно в качестве параметра:
$touristPrices = array_map(function($price) {
return $price*2;
}, $localPrices);
Замыкания могут импортировать переменные в контекст через use ключевое слово:
$factor = 2;
$touristPrices = array_map(function($price) use($factor) {
return $price*$factor;
}, $localPrices);
Генераторы
Генераторы были добавлены в PHP 5.5, следовательно, они в настоящее время отсутствует вообще из WordPress ядра.
Генераторы обеспечивают простой способ реализации простых итераторов. Генератор позволяет писать код, который использует foreach для итерата над набором данных без необходимости создания массива в памяти. Функция генератора такая же, как и обычная функция, за исключением того, что вместо того, чтобы вернуться один раз, она может yield столько раз, сколько нужно, чтобы обеспечить значения, которые будут итерированы более.
function xrange($start, $limit, $step = 1) {
Аргумент и возвращение типа деклараций
Различные объявления типа аргумента были введены в различных версиях PHP: WordPress уже в состоянии объявить интерфейсы и массивы (что это не так: Я едва нашел один экземпляр функции, объявляющей массив в качестве параметра в ядре, и нет интерфейсы), и в скором времени сможет объявить callables (добавлено в PHP 5.4) и scalar типов: bool, поплавок, int и строки (добавлено в PHP 7.0). Объявления типа возврата были добавлены в PHP 7.0.
Объявления типа аргументов позволяют функциям декларировать, какой конкретный тип должен быть аргументом. Проверка выполняется во время вызова, бросая исключение, если тип аргумента не является объявленным. Объявления типа возврата являются одной и той же концепцией, однако они указывают тип значения, которое будет возвращено из функции. Объявления типов полезны для упрощения понимания намерения функции и предотвращения ошибок в расписании выполнения от получения или возврата неожиданного типа.
Тип аргумента объявляется до того, как значение переменной аргумента объявляется до иобратно, а тип возврата объявляется после аргументов, которым предшествует: :
function foo(boolean $bar): int {
}
Декларации типа scalar имеют два варианта: принудительные и строгие. В принудительном режиме, если неправильный тип передается в качестве параметра, он будет преобразован в правильный тип. Например, функция, которая получает ряд для параметра, который ожидает строку получит переменную строки типа. В строгом режиме будет приниматься только переменная точного типа декларации.
Принудительный режим — это по умолчанию. Для включения строгого режима мы должны добавить declare заявление, используемое с strict_types декларацией:
declare(strict_types=1);
function foo(boolean $bar) {
}
Новый синтаксис и операторы
WordPress уже может определить переменную длину списки аргументов через функцию func_num_args . Начиная с PHP 5.6, мы можем использовать ... маркер, чтобы обозначить, что функция принимает переменное количество аргументов, и эти аргументы будут переданы в данную переменную в виде массива:
function sum(...$numbers) {
$sum = 0;
foreach ($numbers as $number) {
$sum += $number;
}
return $sum;
}
Начиная с PHP 5.6,константы могут включать в себя скалярные выражения с участием цифровых и строковых буквальных значений вместо просто статических значений, а также массивов:
const SUM = 37 + 2; // A scalar expression
const LETTERS = ['a', 'b', 'c']; // An array
Начиная с PHP 7.0, массивы также могут быть определены с помощью: define
define('LETTERS', ['a', 'b', 'c']);
PHP 7.0 добавил несколько новых операторов: Null объединения оператора ( ?? ) и оператор космического корабля ( <=> ).
Оператор Null coalescing ?? является синтаксической сахаром для общего случая необходимости использования тернари в сочетании с isset(). Оно возвращает свою первую operand если она существует и не NULL; в противном случае, он возвращает свою вторую операнду.
$username = $_GET['user'] ?? 'nobody';
// This is equivalent to:
// $username = isset($_GET['user']) ? $_GET['user'] : 'nobody';
Оператор космического корабля <=> используется для сравнения двух выражений, возвращающихся -1, 0 или 1, когда первая операндр соответственно меньше, равна или больше, чем вторая работа.
echo 1 2; // returns -1
echo 1 1; // returns 0
echo 2 1; // returns 1
Это наиболее важные новые функции, добавленные в PHP, охватывающие версии от 5.3 до 7.0. Список дополнительных новых функций, не перечисленных в этой статье, можно получить, просматривая документацию PHP о переходе из версии в версию.
Далее, мы анализируем, как мы можем сделать большую часть из всех этих новых функций, и из последних тенденций в веб-разработке, чтобы произвести лучшее программное обеспечение.
Рекомендации по стандартам PHP
Рекомендации PHP По стандартам были созданы группой разработчиков PHP из популярных инфраструктур и библиотек, пытаясь установить конвенции, чтобы различные проекты могли быть интегрированы более бесшовно и различные команды могли лучше работать с Друг другу. Рекомендации не являются статичными: существующие рекомендации могут быть обесточены, а новые рекомендации создаются для их места, а новые публикуются на постоянной основе.
Текущие рекомендации следующие:
| Описание | рекомендации | группы |
|---|---|---|
|
Стили кодирования Стандартизированное форматирование уменьшает когнитивное трение при чтении кода от других авторов |
PSR-1 | Базовый стандарт кодирования |
| PSR-2 | Руководство по стилю кодирования | |
|
Автозагрузка Автозагрузчики удаляют сложность включения файлов, отображая пространства имен для файлов системных путей |
PSR-4 | Улучшенная автозагрузка |
|
Интерфейсы Интерфейсы упрощают совместное использование кода между проектами, выполняя ожидаемые контракты |
PSR-3 | Интерфейс логгера |
| PSR-6 | Интерфейс кэширования | |
| PSR-11 | Контейнерный интерфейс | |
| PSR-13 | Гипермедиа Ссылки | |
| PSR-16 | Простой кэш | |
|
HTTP Совместимые стандарты и интерфейсы для агностичного подхода к обработке запросов и ответов HTTP, как на стороне клиента, так и на сервере |
PSR-7 | Интерфейсы сообщений HTTP |
| PSR-15 | HTTP Обработчики | |
| PSR-17 | Фабрики HTTP | |
| PSR-18 | Клиент HTTP |
Думайте и кодвия в компонентах
Компоненты позволяют использовать лучшие функции из фреймворка, не будучи заблокированным в самой инфраструктуре. Например, Symfony был выпущен в виде набора многоразовых компонентов PHP, которые могут быть установлены независимо от платформы Symfony; Laravel, другой фреймворк PHP, использует несколько компонентов Symfony,и выпустил свой собственный набор многоразовых компонентов, которые могут быть использованы в любом проекте PHP.
Все эти компоненты публикуются в Packagist, хранилище общедоступных пакетов PHP, и могут быть легко добавлены в любой проект PHP через Composer, чрезвычайно популярный менеджер зависимости для PHP.
WordPress должен быть частью такого добродетельного цикла развития. К сожалению, wordPress ядро само по себе не построен о компонентах (о чем свидетельствует почти полное отсутствие интерфейсов) и, кроме того, он даже не имеет composer.json файл, необходимый для установки WordPress через композитора. Это потому, что WordPress сообщество не согласился ли WordPress является зависимость сайта (в этом случае установка его через композитор будет оправдано), или если это сам сайт (в этом случае композитор не может быть правильным инструментом для работы).
На мой взгляд, если мы ожидаем WordPress оставаться актуальными в течение следующих пятнадцати лет (по крайней мере WordPress в качестве бэкэнда CMS), то WordPress должны быть признаны в качестве зависимости сайта и доступны для установки через Композитор. Причина очень проста: с едва одной командой в терминале, Composer позволяет декларировать и устанавливать зависимости проекта от тысяч пакетов, опубликованных в Packagist, что позволяет создавать чрезвычайно мощные приложения PHP в нет время, и разработчики любят работать таким образом. Если WordPress не адаптируется к этой модели, он может потерять поддержку со стороны сообщества разработчиков и канет в Лету, так как FTP упал в немилость после введения Git основе развертывания.
Я бы сказал, что выпуск Гутенбергужеужев уже демонстрирует, что WordPress является зависимостью сайта, а не сам сайт: Гутенберг рассматривает WordPress как обезглавленный CMS, и может работать с другими системами бэкэнда тоже, как иллюстрирует Drupal Гутенберг. Таким образом, Гутенберг дает понять, что CMS питания сайта может быть swappable, следовательно, она должна рассматриваться как зависимость. Кроме того, Гутенберг сам предназначен для базирования на JavaScript компонентов, выпущенных через npm (как объяснил основной коммиттер Адам Silverstein), так что если клиент WordPress, как ожидается, управлять своими пакетами JavaScript через npm менеджер пакетов, то почему бы не расширить эту логику до бэкэнда, чтобы управлять зависимостями PHP через Composer?
Теперь хорошая новость: Существует не нужно ждать этого вопроса, который будет решен, поскольку это уже можно рассматривать WordPress как зависимость сайта и установить его через композитора. Джон. Блох имеет зеркальные WordPress ядро в Git, добавил composer.json файл, и выпустил его в Packagist, и корни’ Bedrock предоставляет пакет для установки WordPress с индивидуальной структурой папки с поддержкой для современных средства разработки и повышение безопасности. И темы и плагины покрыты слишком; до тех пор, как они были перечислены на тему WordPress и плагин каталоги, они доступны под WordPress Packagist.
Как следствие, это разумный вариант для создания WordPress код не думать с точки зрения тем и плагинов, но думать с точки зрения компонентов, что делает их доступными через Packagist, которые будут использоваться в любом проекте PHP, а также дополнительно упакованы и выпущены в качестве темы и плагины для конкретного использования WordPress. Если компонент удостаивается взаимодействовать с AA WordPress, то эти AA можно абстрагировать за интерфейсом, который, если возникнет необходимость, может быть реализован и для других CMS.
Добавление движка шаблона для улучшения слоя представления
Если мы следуем через рекомендацию мышления и кодирования в компонентах, и относиться к WordPress как зависимость сайта, кроме самого сайта, то наши проекты могут вырваться из границ, введенных WordPress и импортировать идеи и инструменты, взятые из других Рамки.
Рендеринг HTML-контента на стороне сервера является примером, что делается через простые шаблоны PHP. Этот слой представления может быть увеличен с помощью шаблонных двигателей Twig (по Symfony) и Blade (по Laravel), которые обеспечивают очень краткий синтаксис и мощные функции, которые дают ему преимущество перед простыми шаблонами PHP. В частности, динамические блоки Гутенберга могут легко извлечь выгоду из этих шаблонных движков, так как их процесс визуализации HTML блока на стороне сервера отделен от архитектуры иерархии шаблонов WordPress.
Архитектор Приложение для общего использования
Кодирование в отношении интерфейсов и мышление с точки зрения компонентов позволяют нам проектировать приложение для общего использования и настраивать его для конкретного использования, которое нам необходимо использовать, вместо кодирования только для конкретного использования для каждого проекта, который у нас есть. Несмотря на то, что этот подход является более дорогостоящим в краткосрочной перспективе (он предполагает дополнительную работу), он окупается в долгосрочной перспективе, когда дополнительные проекты могут быть реализованы с меньшими усилиями, просто настраивая приложение общего пользования.
Для того чтобы этот подход был эффективным, необходимо учитывать следующие соображения:
Избегайте фиксированных зависимостей (насколько это возможно)
j’ery и Bootstrap (или Фонд, или lt;-вставьте свою любимую библиотеку здесь- )можно было бы уже считалось обязательным имунами несколько лет назад, однако, они неуклонно теряют свои позиции против ванили JS и новые родные функции CSS. Таким образом, проект общего пользования, закодированный пять лет назад, который зависел от этих библиотек, может быть уже не подходящим в настоящее время. Таким образом, как правило, чем меньше количество фиксированных зависимостей от сторонних библиотек, тем более актуальным оно будет в долгосрочной перспективе.
Прогрессивное повышение функциональности
WordPress является полномасштабной системой CMS, которая включает в себя управление пользователем, следовательно, поддержка управления пользователями включена из коробки. Однако, не каждый сайт WordPress требует управления пользователем. Следовательно, наше приложение должно учитывать это и оптимально работать над каждым сценарием: поддерживать управление пользователями, когда это необходимо, но не загружать соответствующие активы, когда это не так. Этот подход также может работать постепенно: Скажем, клиент требует реализации Контакт нас форме, но не имеет бюджета, поэтому мы код его с помощью бесплатного плагина с ограниченными возможностями, а другой клиент имеет бюджет, чтобы купить лицензию от коммерческого плагина предлагая лучше Функции. Затем мы можем кодировать нашу функциональность по умолчанию до очень простой функциональности, и все чаще использовать функции от того, из которых является наиболее способным плагином, доступным в системе.
Непрерывный обзор кода и документации
Периодически пересматривая наш ранее написанный код и его документацию, мы можем проверить, является ли он либо современным в отношении новых конвенций и технологий, и, если это не так, принять меры по его обновлению до того, как техническая задолженность станет слишком дорогой для преодолеть, и мы должны кодировать все это снова и снова с нуля.
Рекомендуемое чтение: Будьте бдительны: PHP и WordPress Функции, которые могут сделать ваш сайт небезопасным
Попытка свести к минимуму проблемы, но будьте готовы, когда они происходят
Ни одно программное обеспечение никогда не 100% совершенным: ошибки всегда есть, мы просто не нашли их еще. Таким образом, мы должны убедиться, что, как только проблемы возникают, они легко исправить.
Сделать это просто
Сложное программное обеспечение не может быть сохранено в долгосрочной перспективе: не только потому, что другие члены команды не могут понять его, но и потому, что человек, который закодировал его, может не понять свой собственный сложный код через несколько лет. Таким образом, производство простого программного обеспечения должно быть приоритетом, тем более, что только простое программное обеспечение может быть правильным и быстрым.
В противном случае на компилировать время лучше, чем на Runtime
Если часть кода может быть проверена на предмет ошибок в момент компиляции или времени выполнения, то мы должны определить приоритеты решения времени компиляции, чтобы ошибка может возникнуть и быть рассмотрена на этапе разработки и до того, как приложение достигнет производства. Например, оба const и define используются для определения констант, однако, в то время как const проверяется во время компиляции, define проверяется во время выполнения. Таким образом, когда это возможно, использование const предпочтительнее . define
Следуя этой рекомендации, функции WordPress, содержащиеся в классах, могут быть расширены, передавая фактический класс в качестве параметра вместо строки с именем класса. В приведенном ниже примере, если класс Foo переименован, в то время как второй крюк приведет к ошибке компиляции, первый крюк выйдет из строя во время выполнения, следовательно, второй крюк лучше:
class Foo {
public static function bar() {
}
}
add_action('init', ['Foo', 'bar']); // Not so good
add_action('init', [Foo::class, 'bar']); // Much better
По той же причине, как выше, мы должны избегать использования глобальных переменных (таких global $wpdb как): они не только загрязняют глобальный контекст и не легко отслеживать, откуда они берутся, но и, если они будут переименованы, ошибка будет производиться во время выполнения. В качестве решения мы можем использовать контейнер для инъекций зависимостей для получения экземпляра требуемого объекта.
Работа с ошибками/исключениями
Мы можем создать архитектуру Exception объектов,так что приложение может реагировать соответствующим образом в соответствии с каждой конкретной проблемой, либо оправиться от него, когда это возможно, или показать полезное сообщение об ошибке пользователю, когда нет, и в целом войти ошибка для админа, чтобы исправить проблему. И всегда защищать пользователей от белого экрана смерти: Все непойманные Error s и s могут быть Exception перехвачены через функцию set_exception_handler для печати нестрашное сообщение об ошибке на экране.
Принять инструменты сборки
Инструменты сборки могут сэкономить много времени, автоматизируя задачи, которые очень утомительно выполнять вручную. WordPress не предлагает интеграцию с каким-либо конкретным инструментом сборки, поэтому задача включения их в проект будет полностью падать на разработчика.
Существуют различные инструменты для достижения различных целей. Например, существуют инструменты сборки для выполнения задач для сжатия и избавительных изображений, минимизации файлов JS и CSS, а также копирования файлов в каталог для выпуска, таких как Webpack, Grunt и Gulp; другие инструменты помогают создать строительные леса проекта, который полезен для производства структуры папок для наших тем или плагинов, таких как Yeoman. Действительно, с таким количеством инструментов вокруг, просмотр статей сравнения различных доступных инструментов поможет найти наиболее подходящий для наших нужд.
В некоторых случаях, однако, нет инструментов сборки, которые могут достичь именно того, что нужно нашему проекту, поэтому нам может потребоваться кодировать наш собственный инструмент сборки в качестве расширения самого проекта. Например, я сделал это для создания сервиса-worker.js файл, чтобы добавить поддержку для работников службы в WordPress.
Заключение
Из-за своего сильного акцента на сохранении обратной совместимости, продлен даже до PHP 5.2.4, WordPress не смог извлечь выгоду из последних функций, добавленных в PHP, и этот факт сделал WordPress стал не очень-захватывающая платформа для кода для многих Разработчики.
К счастью, эти мрачные дни могут скоро закончится, и WordPress может стать блестящей и захватывающей платформой для кодирования еще раз: требование PHP 7.0 «, начиная с декабря 2019 года сделает множество функций PHP доступны, что позволяет разработчикам производить больше мощное и более исполнительное программное обеспечение. В этой статье мы рассмотрели наиболее важные новые функции PHP и как максимально выбрать из них.
Недавний релиз Гутенберга может быть признаком грядки: даже если сам Гутенберг не был полностью принят сообществом, по крайней мере, он демонстрирует готовность включить новейшие технологии (такие как React и Webpack) в ядро. Такой поворот событий заставляет меня задаться вопросом: Если фронтенд может получить такой макияж, почему бы не распространить его на бэкэнд? После того, как WordPress требует по крайней мере PHP 7.0, обновление до современных инструментов и методологий может ускориться: Столько, сколько npm стал менеджером пакета JavaScript выбора, почему бы не сделать Композитор стать официальным менеджером зависимости PHP? Если блоки являются новым блоком для строительных площадок в передней части, почему бы не использовать компоненты PHP в качестве устройства для включения функциональных возможностей в бэкэнд? И, наконец, если Гутенберг рассматривает WordPress как swappable бэкэнд CMS, то почему бы уже не признать, что WordPress является зависимость сайта, а не сам сайт? Я оставлю эти открытые вопросы для вас, чтобы подумать и подумать о.
Источник: smashingmagazine.com
