Статьи

Внедрение качества в проекты WordPress: практический пример

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

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

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

Но я думаю, что если вы спросите десять разработчиков, что для них значит качество, вы получите десять разных ответов.

Слово «качество» предлагает три определения :

  1. Как хорошо или плохо что-то,
  2. Характеристика или особенность, которые есть у кого-то или чего-то: что-то, что можно заметить как часть человека или вещи,
  3. Высокий уровень ценности или превосходства.

Если вы подумаете на минуту о том, как это относится к продуктам, которые вы создаете с помощью WordPress, что приходит на ум?

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

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

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

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

И это действительно происходит. Я говорю из опыта.

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

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

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

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

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

В WordPress 4.4 поддержка тегов заголовка изменилась, и вы добавили поддержку для этого, просто включив следующую строку в файл functions.php :

1
<?php add_theme_support( ‘title-tag’ );

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

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

1
<title><?php wp_title( » );

Но зачем кому-то связываться с названием? Подумайте о плагинах SEO. Они часто изменяют элементы title чтобы сделать его более удобным для поисковых систем.

Давайте посмотрим на реальный пример: скажем, вы работаете над темой, а ее элемент title включает в себя вызов wp_title . Кроме того, вы хотите убедиться, что wp_title является фильтруемым, чтобы другой код, такой как вышеупомянутые плагины, мог обновить его.

Это кажется достаточно простым, верно? Но допустим, вы хотите немного украсить его, добавив разделитель и обновив его положение. В этом случае вы можете сделать что-то вроде этого:

1
<title><?php wp_title( ‘|’, true, ‘right’ );

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

Тогда вы можете сделать что-то вроде этого:

1
<title><?php bloginfo(‘name’);

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

Но что происходит, когда кто-то распространяет тему? Кроме того, что происходит, когда кто-то хочет использовать плагин для изменения элемента title ?

Это не сработает.

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

Чтобы убедиться, что использование wp_title() является максимально гибким, нам нужно определить пользовательскую функцию и отфильтровать ее с wp_title фильтра wp_title предоставляемого WordPress:

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
<?php
 
add_filter( ‘wp_title’, ‘acme_wp_title’, 10, 2 );
/**
 * Provides a standard format for the page title depending on the view.
 * filtered so that plugins can provide alternative title formats.
 *
 * @param string $title Default title text for current view.
 * @param string $sep Optional separator.
 * @return string The filtered title.
 * @package acme
 * @version 1.0.0
 * @since 1.0.0
 */
function acme_wp_title( $title, $sep ) {
    global $paged, $page;
 
    if ( is_feed() ) {
        return $title;
    }
 
    // Add the site name.
    $title .= get_bloginfo( ‘name’ );
 
    // Add the site description for the home/front page.
    $site_description = get_bloginfo( ‘description’, ‘display’ );
    if ( $site_description && ( is_home() || is_front_page() ) ) {
        $title = «$title $sep $site_description»;
    }
 
    // Add a page number if necessary.
    if ( $paged >= 2 || $page >= 2 ) {
        $title = sprintf( __( ‘Page %s’, ‘acme’ ), max( $paged, $page ) ) .
    }
 
    return $title;
 
}

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

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

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

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

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

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

Мы заканчиваем с настроенной версией названия. Мы также даем сторонним разработчикам возможность переопределять наш собственный код.

Хотя это больше кода, это решение более высокого качества.

Помните, однако: это не всегда так. Иногда больше кода может снизить качество и усложнить задачу. Но не в этом суть этой статьи. Возможно, это лучше обсудить в другом уроке.

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

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

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

Все вышеперечисленное вместе способствует повышению качества.

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

Если вас интересуют другие вещи, которые я написал или создал для Envato, вы можете проверить мою работу на странице моего профиля , а также подписаться на меня в моем блоге и / или Twitter по адресу @tommcfarlin, где я говорю о разработке программного обеспечения в контекст WordPress.

Не стесняйтесь оставлять любые вопросы или комментарии в ленте ниже, и я постараюсь ответить на каждый из них.