В WordPress философии есть один принцип, который звучит как «Decisions, not Options». Он означает, что нужно делать работающие решения, и не делать опции.

Каждая новая опция, которая добавляется в продукт — несет в себе одну частицу добра и десять частиц зла, если вы потом решите изменить этот продукт под свои нужды.

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

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

Особенно если берется тема или плагин, в котором множество опций. Особенно это касается готовых премиум тем (или некоторых фреймворков), которые делаются как правило для таких целей. Авторы полагают что они делают продукт законченный для пользователя, дают множество опций, и полагают что нет нужды сильно менять эту тему. Какие-то мелкие стилистические правки — да. А вот что то сильно менять — нет.

Как только встает вопрос изменения, то опции превращаются из добрых и нужных вещей для пользователей, в ад и кошмар любого программиста. И если этих опций много — то ад становится кромешным. Чтобы поменять какую-то одну кнопочку или переставить 2 поля местами, приходится сидеть и разгадаывать алгоритмы по 500-1000 строк. Особенно если авторы увлеклись множеством циклов и создали елочную лапшу из кода. Для изменения такой махины требуется колоссальныз запас внимания и памяти прежде всего программиста. 9 из 10 программистов в этой ситуации просто сдаются и бегут.

С точки зрения дизайнера пользовательских интерфейсов — опция это элемент интерфейса. А значит само по себе зло. Идеальный интерфейс — это отсутствие интерфейса. Где-то слышал такое выражение от дизайнеров и целиком с этим согласен.

Потому идеальный код — это код без опций, который просто делает свое дело. В этом случае он в десятки раз проще, и его изменение в десятки раз дешевле. Была одна задача — она решалась. Решили поменять задачу — поменяли код. Теперь она решается иначе. Но без опций.

Пример

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

Вот готовая форма поиска объектов недвижимости на одной из таких тем:

435

Выглядит просто, не правда ли?

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

Стоит задача чуть чуть поменять поля и перерисовать ее по макету дизайнеров вот так:

295

Согласитесь что поменять пару полей в php файле это задачка максимум на час или два, даже с учетом каких-то изменений в модели и контроллерах?

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

И не тут то было! Оказывается эта форма собирается через функцию. Хорошо, идем и ищем функцию. Опа на! А эта функция оказывается замысловатый набор условий и циклов, в дебрях которых защито еще 2-3 функции вызова. И нет тут никакх полей, которые можно как-то пересобрать.

Лезем разбирать эти 2-3 функции, находим одну и видим что она состоит из 500 строк кода, которые собирают и пересобирают состав этих полей, их порядок и содержимое через тьму циклов и условий.

И вызвано это все одним простым фактором — авторам надо было научить эту форму показывать или не показывать поля по определенным опциям.

Таким образом без опций — эта форма собирается за 30-50 строк кода, пересобрать которые пара пустяков.

А по той причине что авторы добавили опции — теперь мы имеем дело с 500-1000 строк кода, которые надо еще как то распутать и разгадать.

Кто пытался разобраться в чужом коде — тот меня поймет 🙂

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

Резюме

Итак, для тех кто не уловил мысль, подведу итоги тезисами:

1. Без опций код может состоять из 30-50 строк и легко поддаваться изменениям. С опциями этот же код уже состоит из 500-1000 строк кода.

2. Изменение функций с опциями в десятки раз сложнее чем функций без опций

3. Как думаете, какое число ошибок будет содержаться в функции из 50 строк и из 500 строк кода?

Понимая эти особенности, я начал понимать почему многие программисты говорят «Да проще с нуля написать, чем изменять что-то готовое».

Они отчасти правы, но я не совсем согласен с этим утверждением.

Мое мнение такое:

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

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

От сюда же вытекает наша политика в этом отношении:

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

2. Если вы хотите решения под себя. Под свои задачи. Свой дизайн, и чтобы кнопочки и галочки располагались так как надо, то берите чистый WordPress, чистую стартер тему типа _s или Alienship (_s + bootstrap) и пишите код под задачи без опций. Поверьте, написать 50 строк кода, это не одно и тоже что переписать 50 строк кода которые зависят от функций которые состоят еще из 500 строк кода.