Мы уже касались темы правильного структурирования компонентов. Сейчас хочу привести пример ошибки и правильного решения.

Вот мы разрабатываем новую тему для WordPress на базе Bootstrap.

За основу мы взяли стартер тему Underscores (_s).

Почему то программисты любят разбивать js и css файлы по типам. Когда я спросил зачем вы так делаете? Они сказали — «Ну это MVC».

При этом ни одно программист внятно не смог описать что значит MVC. У каждого какая то каша в голове.

Проблемы

Такой подход дает ряд проблем и головняков:

  1. Если нужно изменить компонент, то приходится рыскать в поисках его частей по разным подпапкам
  2. Если нужно обновить компонент, то опять же тратим время на то чтобы найти его части раскиданные по разным папкам
  3. Если компонентов будет много, это неизбежно влечет энтропию и как следствие — повышает хрупкость продукта, множит ошибки
  4. У разных подпродуктов могут быть файлы с одним названием, например style.css или main.js. Если следовать этой логике, то можно легко перезатереть файлы разных компонентов.

Применяем ВИСИ в WordPress

На самом деле если мы используем готовые компоненты как подпродукты, то должны поместить все его файлы в отдельную папку вместе! Вот как скачали архив с компонентом, так и помещаем в подпапку.

К примеру наша тема зовется wpbss. Там создаем папку include (еще может быть inc или assets). Суть этой папки — хранить все что используется внутри продукта. Или другими словами — хранить файлы подпродуктов.

Если представить что продукт будет состоять из более чем 10 подпродуктов, то в идеале мы должны получить дерево папок, где каждый подпродукт будет находиться в отдельной папке. Этот метод называется ВИСИ.

Пример с Bootstrap

Наша тема — в основе имеет Underscores. А Bootstrap для нее являетя подпродуктом.

Программист взял, разрезал этот подпродукт на кучу файлов и рассовал их по папкам js и css. Перепутав и перемешав его с другими файлами такого типа. Это не так страшно если у вас 1 или 2 подпродукта. Но если их 10? Такая мешанина превратится в кашу.

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

Правильно в этом случае следовать методу ВИСИ. Именно этот метод структурирования позволят избежать множества проблем. И ниразу не противоречит методу MVC, если знать что это такое.

Если следовать этому методу, то в папке inc мы должны создать подпапку bootstrap и туда распокавать скачанный архив так как он идет из коробки. Это создает легкую избыточность, с одной стороны это чуть чуть снижает эффективность (размер продукта растет), но зато повышает антихрупкость.

Простой пример где это бывает полезно: например мы решили обновить компонент Bootstrap. Нам достаточно скачать новый архив и снова распаковать его в ту же папку. Минимум действий. Не нужно тратить время и рыскать в поиске файлов и того как они раскиданы. Это лишь малый пример пользы такого подхода.

Пример с wp-bootstrap-navwalker

Идем далее, вот мы решили создать меню в теме. Для этого есть отличное решение, готовый компонент wp-bootstrap-navwalker.

Программист взял и переименовал этот файл, засунув его куда ума хватило.

Нужно было скачать архив и распаковывать его снова в папку inc как отдельную подпапку. Это тоже подпродукт. При этом по правилу ВИСИ, он не относится чисто к Bootstrap. А является связующим звеном между Bootstrap и WordPress. Если бы это был плагин для Bootstrap, то мы бы его поместили в уже созданную папку Bootstrap. Но это не так. Потому он будет храниться рядом. Опять же копируем целиком архив, включая файлы readme.txt. Это важно, на тот случай если кто то решит изменить продукт, ему нужно знать что это готовое решение, которое отторгаем и может быть относительно без болезненно обновлено. Опять же это должно происходить без лишних телодвижений. Скачали — залили — получили обновление.

Резюме

Правильное струтурирование компонентов (подпродуктов) — помогает снижать затраты на разработку продуктов и их изменение.

Пример того что получилось в нашем случае:

280

В результате мы получаем ряд преимуществ:

  1. Легко понять что это отторгаемые компоненты. Есть даже их readme файлы, легко прочитать их описание и понять как их использовать.
  2. При желании их можно обновить в пару кликов без нужды рыскать по папкам и искать что от куда торчит.
  3. Если нужно изменить компонент, то все его файлы в одном месте. Опять же проще.
  4. Если продукт будет достаточно сложным и содержать более 10 подпродуктов, то мы увидим дерево, в котором легко сможем разобраться.
  5. Вы никогда не затерете файлы разных компонентов, если они имеют одно и тоже название.

Плюсом вы получаете все преимущества ВИСИ, которые расписаны в этой статье.

Пример идеально структурированной темы WordPress — Unite. Как видите все в папке inc. За исключением стандартных файлов WordPress, у которых должно быть соответствующее расположение относительно корня. Как не странно, это первая тема которая так идеально структурирована, но я обратил на нее внимание из за идеальной настройки. Я использовал ее на множестве сайтов, включая наш, без каких либо существенных изменений, при этом она идеально поддерживает большинство плагинов WordPress. Она в высшей степени антихрупка. Как им это удалось? Вероятно у авторов в голове был порядок. Знали они или нет что такое ВИСИ — не ясно. Но то что они ему следовали осознанно или нет — это факт. Это лучшая из тем для WordPress которые мне встречались. Сегодня наш сайт работает на базе именно этой темы, без каких либо изменений. Зачем что то менять, если оно идеально? 🙂 Моя мечта — сделать что то подобное. Получится или нет — покажет время 🙂