Повествование ведется от лица Jake Goldman (прим. перев.)

Несколько располневший, грузный 47-летний человек подходит ко мне и говорит: «Я планирую стать следующим олимпийским медалистом в беге. Что вы думаете по этому поводу?» Я отвечаю: «Отлично, мне в любом случае импонирует ваша цель».

По правде сказать, этот мужчина, возможно, никогда и не выступит на Олимпийских играх. Система WordPress имеет в себе признаки многочисленных платформ и фреймворков для создания приложений, включая базовый API, а также методы, позволяющие автоматизировать и упростить такие сложные операции, как пользовательская аутентификация и удаленное взаимодействие с данными. Система WordPress обычно производит бурный эффект, поскольку она переносит издательский опыт на удобную, доступную и открытую платформу. Бизнесмены, выбирающие систему публикации, практически не интересуются таким аргументом, как пригодность PHP к разработке объектно-ориентированного программного обеспечения.

Таким образом, когда разговор заходит о «наилучшей платформе для публикации и управления контентом», данный аргумент – мощный и подкрепленный фактами – убедительно говорит в пользу WordPress. Если же разговор идет о «наилучшей платформе для проектирования приложений», то в таком случае неясно, будет ли выбор сделан в пользу WordPress – во многом из-за размытости и широты критериев; до сих пор ведутся споры о сравнительных достоинствах архитектуры этой платформы. В спорах об архитектуре и технических преимуществах самые свежие технологии – избавленные от всего устаревшего и оптимизированные для современности – всегда ставятся на первое место. Наше видение процесса авто-обновлений (как в случае с обновлениями Chrome, которые проходят в фоновом режиме без вмешательства пользователя) – который может успешно выполняться лишь с фактически гарантированной обратной совместимостью – конфликтует с видением конкурентоспособной, современной программной платформы.

Опасный соблазн

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

Смахивает на фанатизм. Нет ничего плохого в том, чтобы выражать привязанность какой-либо команде – главное, чтобы «плохое» и «хорошее» было определено в этой команде. Если рассматривать мою текущую судьбу, связанную с WordPress, то настрой «Платформа WordPress – хорошая, платформа X – плохая» является соблазнительным – и в то же время опасным. Я не хочу быть тем, кто предпочитал MovableType в 2008 или Adobe Flash в 2011. Я давно уже восхищаюсь своим другом, веб-стратегом John Eckman, потому что вы можете описать ему свои функциональные требования к веб-платформе, и он приведет вам сравнительную характеристику трех или четырех платформ, некоторые из которых он даже не поддерживает. Я хочу быть именно таким человеком, а не фанатом «WordPress, f**k yeah!».

Именно по этой причине я описываю 10up как агентство веб-публикации, выбравшее лучший на сегодняшний день инструмент для нашей работы (WordPress). Именно по этой причине я говорю крошечным компаниям, которым требуется простой интернет-магазин, что Shopify может оказаться более полезным, нежели WordPress + eCommerce-плагины. Я посоветовал крупному предприятию рассмотреть сложный, построенный на базе WordPress интранет, что являлось лучшим выбором, отвечающим их требованиям, в то время как два «агентства WordPress» пытались всучить им бессмысленные, дорогостоящие WordPress-решения. Клиент выбрал для себя более подходящий инструмент, поблагодарил меня за обедом и вернулся позже с проектом, который выступил прекрасной адаптацией. Два месяца назад я обедал с бывшим редактором paidContent, который поведал мне, что Мэтт Мулленвег покорил его сердце тогда, когда он рассказывал про недостатки WordPress – для каких именно проектов система не слишком пригодна.

Все это – лишь долгий, извилистый путь к тому, что я хотел сказать: когда мы утверждаем WordPress в качестве решения, я пытаюсь подавить в себе преданного фаната (и продавца), выкрикивающего «бери WordPress!» Я ставлю перед собой вопрос: «Если смотреть объективно, действительно ли WordPress – это самое подходящее решение в данной ситуации?» Я предлагаю WordPress в качестве платформы для приложений, потому что это прекрасное решение или потому что я знаю WordPress? Как веб-профессионал, могу сказать, что впаривание WordPress клиенту, когда есть лучшая и более подходящая альтернатива – это, с моей точки зрения, злоупотребление своим служебным положением.

Является ли WordPress хорошей платформой для приложений на сегодняшний день?

Итак, давайте пока отложим этот вопрос: если вы столько же времени обращаетесь в экосистеме WordPress, как и я сам (примерно 7 лет), то вы, возможно, помните такой проект как BackPress. BackPress был проектом, предназначенным для «отпочкования» платформы приложений от WordPress, чтобы она могла использоваться в качестве фреймворка для проектов, таких как bbPress 2.

Как вы, вероятно, знаете, bbPress 2 в конечном счете принял форму прекрасно выполненного WordPress-плагина (сейчас им занимается 10up, а ранее занимался John James Jacoby), использующего родную для WordPress архитектуру информации: в нем нет ни одной произвольной таблицы. Это яркий пример потенциала WordPress как платформы для приложений. По крайней мере, до тех пор, пока вы не послушаете Джона, описывающего свистопляски, которые ему пришлось сделать для реализации этой работы. Это не значит, что bbPress 2 – не самое лучшее программное обеспечение: это лишь говорит о том, что если бы Джон искал сегодня платформу для этого, то он вряд ли выбрал бы WordPress. Он сделал так, потому что хотел прикрутить форум к системе публикации.

Пожалуй, излишне говорить о том, что BackPress сегодня практически не подает признаков жизни. Прочтите еще раз: последний на данный момент проект, предназначенный для эффективного извлечения прикладного уровня WordPress, провалился. Справедливости ради, система WordPress выросла совсем немного с момента создания BackPress. Пал ли BackPress жертвой неправильно выбранного временного отрезка?

Я представил эволюцию модели данных WordPress, которая описывает нашу абстрактную модель. Изучившие ее специалисты (которые не заснули в процессе просмотра), такие как Mark Jaquith и Erick Hitter, сообщили мне, что им было весело снова взглянуть на такие таблицы, как «linkcatagories», «post2cat» и «link2cat». Можно легко забыть, что в самых ранних версиях WordPress не было даже объекта (для записей) meta.

Увидев такие поля, как «ping_status» и «comment_status» в нашей таблице объектов (или таблице «posts»), не говоря уже о таблицах, связанных с «links» и «comments», очень сложно назвать всю схему оптимизированной, обобщенной платформой для приложений, а не просто очень гибкой моделью публикации данных.

Хуже то, что у нашей архитектуры таксономий есть фундаментальные дефекты, которые оставляли meta в безвыходном положении в течение многих лет (и способствовали появлению некоторых уродливых, нерешаемых багов). Andrew Nacin, которому я надоедал по этому поводу как минимум два года, теперь уверяет нас, что у него есть план, заложенный в roadmap… благодаря фокусу на платформе для приложений. Что бы я ни думал по поводу конечной цели – а мы еще вернемся к ней, – Макиавелли ухмыляется во мне.

Есть и другие признаки, которые отсутствуют в WordPress, но характерны для остальных платформ – такие как нехватка эффективных 1:1 объектных взаимосвязей. Несмотря на то что неудобные соглашения о присвоении имен для объектов, полученные в наследство от «posts», в действительности не сильно мешают, мы должны все же признать, что они тоже сбивают с толку разработчиков, рассматривающих WordPress в качестве платформы для приложений.

Эти проблемы можно решить. Однако перед нами стоит тяжелая задача – и, учитывая преимущества абстрактной модели данных и платформ для приложений, я не считаю, что мы объективно можем выиграть технический спор.

Примерно месяц назад я сделал предложение многостороннему разработчику программного обеспечения, который мне импонирует, чтобы тот присоединился к 10up. Он долго мучился с выбором, прежде чем сказал: «10up – удивительная компания, в которой каждый может изучить много всего, но я не хочу видеть то, как ваши сотрудники работают над ядром WP. WordPress – это совсем не то, с чем я хотел бы связать свою карьеру. Не думаю, что вам хотелось бы брать на работу человека, который не заинтересован на 100% в том, чем занимается 10up». Перед отправкой этого заключительного решения (по модели «как отшить работодателя»), он признал, что если бы я продавал Symfony или какие-либо «более современные», более мощные фреймворки, то он бы с радостью устроился ко мне на работу.

После вечеринки на WordCamp San Francisco я рассказал Мэтту Мулленвегу эту историю: «Нам нужны такие элитные специалисты». Он ответил мне, что я «увернулся от летящей пули»: идеализирующие все и вся специалисты никогда не уживаются в бизнес-среде. Он был прав. Но я тоже не был неправ. Если мы построим WordPress на идеалах открытости и демократичности процесса публикации, то мы привлечем прекрасных специалистов, которые поддерживают такое видение и которые не понимают элитарных программистов.

По-настоящему вдохновляющая история Paul Clark не затрагивала моделей баз данных или программирования.

Систему WordPress как платформу для приложений можно защищать по разным показателям: один из них касается технических достоинств. Я недавно спросил Nacin, не думал ли он о том, что фундамент PHP поставил WordPress под угрозу. Он нехарактерно задумался, отмахиваясь от моих предыдущих вопросов, и затем сказал: «Возможно».

Можем ли мы «переосмыслить» WordPress? Можем ли мы, воспользовавшись быстрой моделью циклов выпуска, органически превратиться в конкурентоспособную, серьезную платформу для приложений, и захватить не только рынок систем управления контентом, но и значительную долю более широкого рынка платформ? И если да, то каким будет WordPress в самом конце этого пути? Все это наталкивает меня на следующую мысль.

Автоматические обновления == обратная совместимость != радикальное переосмысление

Ранее летом я выступал совместно с директором по маркетингу Acquia, Tom Wentworth, на CMS Expo, где мы, 7 участников, описывали варианты применения для наших систем управления контентом (Acquia так же относится к Drupal, как Automattic к WordPress). После ожидаемого умаления достоинств WordPress как платформы для публикации («используйте Drupal, если вы хотите сделать WordPress»), Tom стал рекламировать фантастические инструменты разработчиков, доступные в Drupal 8, включая фундамент Symfony. Я напомнил аудитории, что далекий от автоматических обновлений, Drupal 8 потребует переписывания всех веб-сайтов. Я также задал вопрос, почему, если вы являетесь издателем (большая часть народу на этой конференции были именно ими), а не продвинутым специалистом, вам нужно будет восстанавливать все это каждые несколько лет.

Даже как ориентированный на предприятия поставщик, я не согласен с хором голосов, возражающих против намерения WordPress интегрировать автоматические обновления версии. Совершенно точно появится подмножество людей, для которых отключение автоматических обновлений будет выступать критически важным действием – точно так же, как они отключают одним щелчком мыши уведомления в WordPress; своего рода тщательно контролируемая корпоративная бизнес-среда, в которой отключено и автоматическое обновление Windows. Большинство «потребителей», однако, извлечет выгоду из автоматических фоновых обновлений. Это – будущее программного обеспечения, это именно та причина, по которой многие организации – включая и компании – переходят на PaaS-сервисы, такие как WordPress.com и его VIP-ответвления – и мы должны охватить это. Давайте держать в памяти то, что эти крупные компании не поскупятся на то, чтобы заплатить за поиск варианта «без обновлений», даже если эта константа зарыта глубоко в wp-config.

Здесь есть одно «но». Это работает в модели «клиентов» или «потребителей», в которой наш вариант использования программного обеспечения (в нашем случае публикация контента) стоит выше технической чистоты. Мы не можем выпустить «автоматическое обновление», которое ломает функциональность. Это идеально согласуется с агрессивной обратной совместимостью в WordPress и быстро увеличивает число «устаревших» скриптов.

Однако… Аудитория «платформы для приложений» очень сильно отличается от аудитории «системы публикации»: это разработчики и специалисты, ищущие удобные, современные инструменты. Даже от предпочитающих WordPress специалистов можно порой услышать ворчание о противоречивых соглашениях о присвоении имен и «вечно живых» моделях данных, как наши позорные глобальные переменные $post и $wp_query или фундаментально устаревшие, вековые компоненты, как TinyMCE (визуальный редактор).

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

Подумайте об этом: автоматический патч и сервис-пак, встроенный в Windows и OS X (это реализовано в Mavericks), оказались бы целесообразным решением: это естественное развитие простоты использования для потребителей. Теперь представьте себе автоматическое обновление от Windows XP до Windows Vista, или от Windows 7 до Windows 8, или более сумасшедший вариант – от Windows 98 до Windows XP (притворимся, что Windows Me не существует). В каждом из этих случаев Microsoft понадобилось бы отбросить поддержку определенного API и моделей данных (несовместимость драйверов оборудования между Vista и XP – необходимый шаг в правильном направлении, но фактически это способствовало ранним проблемам Vista, поскольку потребители ожидали плавных и незаметных обновлений). Если Microsoft подумали бы о бесконечном постепенном обновлении Windows XP, это, возможно, пользовалось бы большим спросом у потребителей. Но и такой подход умер бы в конечном счете из-за необходимости отказа от разработчиков – Windows, это, прежде всего, операционная система, которую можно назвать платформой для «настольных приложений».

Даже когда я запускаю бизнес, сфокусированный по большей части на крупных корпоративных клиентах, я пламенно защищаю потребительские цели. Каждый человек является потребителем, включая руководителей и менеджеров отдела IT, и страсть к потребительским электронным прибамбасам пропитывает бизнес. Microsoft Windows не запускалась как продукт, рассчитанный на предприятия, что верно и для iPhone, и для Android. WordPress не позиционировалась как платформа для компаний. Каждый старался поддержать свои потребительские базы, иногда неуклюже, ориентируясь на сильные потребительские пристрастия, которые и помогали корпорациям «пустить корни».

Действительно ли это – вопрос позиционирования?

Я все время возвращаюсь к «platform stack» с выступления State of the Word, положившего всему этому начало, думая: «все верно». Размышление о WordPress как о различных уровнях с вариантами использования (CMS, блог) – подмножествами нижнего уровня, более абстрактной информационной архитектурой и хелперами, является верным. На самом деле мне кажется, что, как бы это ни было парадоксально, но этот тип мышления – отделение структуры данных и взаимодействия от представления (не важно, веб-сайт это или приложение) –  является во многих случаях ловушкой для профессиональных разработчиков ПО, двигающих WordPress к принятию более усовершенствованной MVC-архитектуры.

Однако я полагаю, что неправильно считать «CMS» и «Блоггинг» существенно различающимися приложениями, в противоположность к более широкой «публикации контента». В рамках этого я не подразумеваю «уровень» платформы как абстрактную, отдельную платформу. Уровень платформы для приложений создан и оптимизирован для доставки контента, и не случайно это было исходным намерением WordPress.

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

Более того, если руководство планирует вывести WordPress на рынок в качестве обобщенной «платформы для приложений» вместо «платформы для публикации», мой протест будет лишь усиливаться. Я предпочитаю продавать и применять лучшие решения. Я хочу работать с Cadillac систем публикации, а не с Visual Basic платформ для приложений (для тех, кто не знает: Visual Basic был … а правда ли был?… известен как очень простой язык программирования для Windows, но который никогда не использовался для создания более серьезных или премиальных настольных приложений).

Правильный маршрут, неправильный пункт назначения

Давайте вернемся назад к тому потенциальному взрослому олимпийцу из первого абзаца. Я подожду, пока вы перечитаете этот абзац. Мой старый друг любил говорить «профессионализм – это осознание своих пределов».

Если рассматривать WordPress как движок для публикации, то я с легкостью бы провел его через строй конкурентов – если брать альтернативы с открытым исходным кодом, которые позволяют издателям управлять своими данными. А как платформу для приложений? Как и наш потенциальный атлет, который имеет две ноги и готов к бегу, существуют некоторые варианты использования WordPress как платформы для приложений, когда модель данных позволяет это делать: это «сфокусированные на контенте приложения» и «издательские приложения». Вот почему я считаю, что мы должны переосмыслить WordPress, рассматривая ее не как платформу для широкого круга приложений, а как «платформу для доставки контента» или «платформу для публикации».

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

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

Но возможно… наш потенциальный медалист не должен бросать свою основную стабильную работу.

Источник: http://jakegoldman.me/2013/09/wordpress-app-platform/