Press This: Избегайте долгов перед технологиями, убивающими время, в сборках WordPress с Джоном Мартином

Добро пожаловать в Press This, подкаст сообщества WordPress от WMR. Здесь ведущий Дэвид Фогельполь беседует с гостями со всего сообщества о самых серьезных проблемах, с которыми сталкиваются разработчики WordPress. Ниже приводится транскрипция оригинальной записи.

Работает на RedCircle

Дэвид Фогельполь: Всем привет и добро пожаловать на подкасты Press This, подкасты сообщества WordPress на WMR. Это ваш ведущий, Дэвид Фогельполь, я поддерживаю сообщество WordPress благодаря своей роли в WP Engine, и мне нравится делиться с вами лучшими из сообщества, которые вы слышите каждую неделю в прессе. Это как напоминание, вы можете найти меня в Твиттере @wpdavidv , или вы можете подписаться на это в iTunes, iHeartRadio, Spotify или загрузить последние выпуски на wmr.fm. В этом эпизоде ​​мы поговорим об одной из моих любимых тем, а именно о том, как избежать технического долга при сборке WordPress. И присоединяясь к нам для этого разговора, я хотел бы поприветствовать Джона Мартина. Джон, добро пожаловать в Press This.

Джон Мартин: Большое спасибо, приятно быть здесь.

ДВ: Вы знаете, я тренируюсь произносить Халлум перед выступлением, но, конечно, я напортачил в самом начале, Джон, извините. Круто, так что те, кто слушает с Джоном, поделятся своими мыслями о влиянии технического долга на команды разработчиков WordPress, например, что значит иметь технический долг и как он влияет на вас? Как вы можете подумать о сокращении своего технического долга по каждому проекту. И тогда почему вы обязаны делиться соображениями технического долга со своими клиентами

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

ДВ: Мы собираемся перейти к мыслям Джона по этой теме, но прежде чем мы начнем, Джон, я собираюсь задать вам тот же вопрос, который я задавал каждому гостю. Расскажите мне вкратце о своей истории происхождения WordPress. Когда вы впервые использовали WordPress

ДМ: так что в начале 2010-х я бы не был уверен, что это правильное выражение для того периода времени. Так что я фактически начал сам и был генеральным директором того, как мы создали агентство в 2008 году. И в то время WordPress все еще был платформой для ведения блогов. Мы создавали веб-сайты с большим количеством богатого контента. Так что это немного ругательное слово, но в то время мы использовали Joomla. Но тогда вместо

ДВ: Joomla — ругательное слово. Лично мне нравятся все CMS с открытым исходным кодом.

JM: Да, мы хотели бы сказать, что это отличный проект. Я думаю, что ключевым моментом для нас является то, что с течением времени Joomla была действительно очень сильной, когда WordPress выпустил поддержку пользовательских почтовых сайтов. Это было, когда для меня все действительно изменилось в WordPress, что подняло его из того, что было известно как платформа для ведения блогов, в полноценную CMS, на которой вы можете делать все виды сайтов, будь то для вас, очень маленький один человек бизнес или фрилансер или что-то еще, вплоть до крупных корпоративных, сложных веб-сайтов. И я думаю, действительно, действительно для меня это было убийственным решением с их стороны, потому что это одна из причин, по которой WordPress сейчас так популярен. Так что да, именно тогда она начала употреблять здесь. Саша история до этого действительно я и теперь генеральный директор о том, как мы вместе были в группе. И у нас есть эта блестящая идея подумать: ну, знаете что, это здорово, больше равного времени в дороге, и действительно трудно вырваться на мою текущую работу. Итак, мы подумали: «Знаете что, давайте создадим агентство и станем веб-разработчиками, потому что это действительно поможет уделить столько времени тому времени, когда это было отличным решением». Я действительно очень доволен этим, но он также, безусловно, наивное решение, потому что думать, что работа на себя дает вам больше времени, было определенно ошибкой, которую, я думаю, мы осознаем немного позже. И до этого момента, вы знаете, я немного знал о SQL, и с тех пор я собирал компьютеры, на самом деле, с тех пор, как видеокарта очень хорошо поддерживает цвета. Так что для всех, кто знает, что такое CGA, это поможет вам узнать, сколько мне лет. Но да, на самом деле, это было, когда вышли CPT. Этот жир изменил для нас все. И мы начали использовать WordPress в одночасье, на самом деле, это стало нашей избранной CMS, и с тех пор мы не оглядывались назад, и, вы знаете,

ДВ: из всех людей, которым я задавал этот вопрос, очень немногие на самом деле имели представление о том, как материальные пользовательские типы сообщений соотносятся с их историей происхождения WordPress. И это смешно. У меня похожая история. Я основал агентство в 2010 году. Так что немного позже, чем вы все, но когда кастомный пост, он вроде как уже попал. Мы начали строить с Joomla и перешли на WordPress по тем же причинам, но это были настраиваемые типы постов и настраиваемые метаданные. поля, с которыми я согласен, и я на самом деле представил этот формат в том, что это был такой момент, когда WordPress действительно стал настоящей CMS. Через год после того, как появилась WooCommerce, появился WP Engine, множество других брендов пространства WordPress, это такое преобразующее время. Интересно услышать от вас ссылку, которая является корнем вашей истории происхождения. Хотя они рассказывали мне о том, как, ну, вы знаете, об основополагающем моменте, если хотите, но не могли бы вы вкратце рассказать мне немного о том, как вы это делаете?

ДМ : Да, конечно. Итак, на самом деле, это агентство, которое мы нашли, было не таким, как мы позже двигались. Ладно ладно. Ну, главная причина этого на самом деле в том, что, знаете ли, в те старые времена существовала очень четкая разница между тем, что мы создаем веб-сайты, и тем, что мы занимаемся SEO и тому подобными вещами. И на самом деле не так уж много людей во всем мире применяли интегрированный подход и действительно думали о таких вещах, как пользовательский опыт, и как это работает с SEO и разработкой, и все такое прочее. Итак, именно поэтому мы в конце концов позже объединились с Алленом Миланом, который существует уже около 20 лет, и наш основатель создал его в самом начале, когда SEO только начало становиться важным. Итак, да, мы объединили два агентства. Шесть, семь лет назад, может, чуть больше. Память у меня не очень хорошая, надо признать. А потом А потом действительно, да, это стало нашим подходом, это полностью интегрированный подход о смешивании всех этих различных дисциплин вместе, чтобы помочь людям увидеть грань? Итак, теперь мы занимаемся контекстной рекламой, SEO, цифровым PR, очевидно, веб-дизайном, а также растяжками бренда, цифровой стратегией и прочими вещами, всеми теми дисциплинами, которые вам действительно нужны, чтобы иметь сильное цифровое присутствие в наши дни. Какова ваша роль там, компания? Итак, моя должность называлась технический директор. Так что я буду честен, на самом деле не совсем охватил все, что я делаю. Я руковожу командой разработчиков в течение длительного периода времени. Так что все, чем будет WordPress, было под моим руководством. Я рад сообщить, что у нас в команде гораздо лучшие разработчики, чем мы с Хулио когда-либо работали, когда мы только начинали, и именно поэтому в наши дни наши дела идут намного лучше. И мы понимаем вещи немного больше. Так что в последнее время я руковожу командой разработчиков в течение длительного периода времени, в том числе и по стоимости данных. Так что это означает, что я играю с машинным обучением, Python, Bartek и другие играют, хотя я должен представить, как все это играет.

ДВ: Работа с крутыми отдельными клиентами приведет к некоторому техническому долгу. И поэтому мне любопытно, что вы думаете о том, каковы общие типы технического долга и, возможно, специфичные для WordPress. Это на минутку, но как вы думаете об этом, когда вы думаете о том, как и как вы все управляете своим техническим долгом, как будто вы заблокировали его по типам с помощью встроенного WordPress?

ДМ: Да, мы делаем. Я имею в виду, нет. Не обязательно. Мы используем такой язык, мы не обязательно классифицируем вещи или проходим районный процесс для классификации, но на самом деле они попадают в три разных сегмента. Один из них — это когда вы создаете плохой код поверх существующего кода, и это может быть связано с тем, что вы, возможно, допустили некоторые ошибки в прошлом, которые могут быть проблемой на веб-сайтах Heritage или кем-то еще, по какой бы причине ни была причина, так что это типа первое ведро. Второй — создание кода, который не нужен, и, возможно, просто не нужен прямо сейчас. Вы знаете, я уверен, что мы все были в конце запросов функций от клиентов и брендов, с которыми мы работаем, где они действительно заинтересованы в конкретной вещи, но на самом деле это может быть не то, что нужно, с точки зрения получения фактической ценности. для клиентов. И затем третья, самая большая, которую мы видим на самом деле, — это создание функций, которые на самом деле должны быть на другой платформе. Таким образом, понимание этого архитектурного элемента о том, какие разные элементы мы подключаем здесь, это CRM, а это веб-сайт, который, по сути, действительно посвящен маркетингу бизнеса. Вот ваша платформа для выполнения заказов, все такое разное.

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

ДМ: Да. 100% Я имею в виду, что не все технические долги плохи. Вы должны принять тот факт, что почти любая функция, которую вы собираетесь создать, будет накапливать некоторый тип технического долга, и вы должны сделать звонок о том, хорош ли этот технический долг или нет. Что-то хорошо, что-то плохо, и действительно зависит от ключевого слова, о котором я говорил ранее, о ценности. Собираетесь ли вы получить ценность, которая вам нужна для этой вещи? Что еще более важно, является ли клиент, конечный клиент, не вашим клиентом, а их клиентами? Получат ли они за это цену? Обычно это довольно хороший путеводный свет, чтобы понять, стоит ли принимать этот технический долг.

ДВ: Да, я хочу как бы глубоко погрузиться в то, как вы думаете об этой цитате, в формуле того, стоит ли ее принимать или нет, но хорошо подумать о том, чтобы получить хорошее представление о том, что вы думаете об этом. различные типы технического долга, и особенно те, которые вы, возможно, захотите оптимизировать для удаления. Что я хотел бы сделать дальше, так это получить представление о том, было ли что-то, что заставило вас сфокусироваться на этой области, но мы собираемся сделать наш первый перерыв, и мы возвращайся сразу же. Пора включить рекламную паузу. Оставайтесь с нами, чтобы узнать больше об этом. Всем привет. С возвращением, чтобы прессовать подкасты сообщества WordPress на W EMR. Это ваш ведущий, Дэвид Фогель. Павел. Я беру интервью у Джона Мартина о том, как время мочеиспускания убивает технических мертвецов. Джон, прямо перед перерывом вы объясняли, что, по вашему мнению, три типа технического долга, от которых вы, возможно, захотите избавиться, — это создание плохого кода на плохом коде, создание кода, который не нужен для успеха сайта, над которым вы работаете. А затем, возможно, создать код для функций, которые могут быть лучше реализованы на другой платформе. Однако прежде чем мы перейдем к формуле «Цитата стоит того». Мне было интересно, было ли какое-то конкретное время, и ваше путешествие — это конкретный случай технического долга, который для вас является основным направлением деятельности?

ДМ: Да, абсолютно. Есть один действительно знаковый проект, который заставил меня задуматься об этом около четырех или пяти лет назад. Я видел много других случаев. Бизнес накапливает время, все время, не только через WordPress через всевозможные вещи, на самом деле бизнес накапливает его также через свои операционные процессы. Если вам нужно быть технической вещью, где вы создаете эту колоду. Во-первых, одна история, которая действительно выделяется на мой взгляд больше, чем любая другая история клиента, мы работаем с относительно небольшой компанией, мы сделали для них много платной работы со СМИ. Продажа, по сути, продажа вещей в Интернете. Это был бизнес электронной коммерции. И у них был традиционный вид доставки по почте, но у них было много работы, и они пытались привлечь больше трафика в Интернете, поэтому им не нужно было проходить через почту, заказ будет управляться через веб-сайт, и они пришли к нам, потому что они сайт, построенный для них, полностью сделан на заказ. И на тот момент они существовали около 10 лет. Таким образом, он стал довольно старым и начал немного ползти. Вы знаете, стандарты и двигаться дальше. Технологии шагнули вперед, пришло время немного переосмыслить. Итак, клиент сел с нами, они начали анализировать все, что они делали на веб-сайте. И мне очень быстро стало ясно, что в веб-сайт встроена всевозможная бизнес-логика и бизнес-процессы. И это была логика, которая приводит к заказам и вполне специфична для того, как работают поставщики. Так что я не буду вдаваться в подробности, но у меня довольно сложная договоренность между поставщиками и тем, как они выполняют заказы и доставляется ли товар в их магазин, прежде чем он отправит все эти вещи. Так что все достаточно сложно. Теперь владелец бизнеса и предыдущий о том, как они работают, в конечном итоге построили систему, которая в значительной степени управляет всем этим, была действительно, очень хорошей системой в то время и действительно помогла этому бизнесу значительно вырасти. Теперь, о чем они на самом деле не думали, так это о том, что у всех веб-сайтов в конечном итоге есть срок годности, который они когда-то воплотят в жизнь, как любое программное обеспечение и в мире маркетинга. Этот срок годности действительно относительно короткий по сравнению, например, с тем, что если вы инвестируете в CRM, так как бизнес обычно будет работать в течение довольно долгого времени, это около 10 лет, если не больше веб-сайтов. Вообще говоря, между двумя-пятью годами мы обнаруживаем, что большинство, по крайней мере, крупных брендов, как правило, перестраиваются каждые три года или около того. Итак, проблема заключалась в том, что они встроили всю эту сложную логику в существующий веб-сайт, и им пришлось перестроить весь веб-сайт. И вдруг приходится перестраивать всю эту бизнес-логику. Теперь мы увеличили стоимость проекта, и в итоге получилось около половины годового оборота на базе только для того, чтобы восстановить то, что у нас уже было. И что действительно заставило меня задуматься об этом, так это то, что хорошо, хорошо, если они изначально подходят к проблеме по-другому, например, давайте подумаем о разных вещах, которых мы пытаемся достичь на веб-сайте. Вы знаете, это из маркетинга было это для продажи продуктов. Это для выполнения заказа, это лучше всего подходит для управления моим бизнес-процессом с поставками и всеми этими вещами, и я думал об этом немного более модульно, тогда для этого клиента была бы совсем другая ситуация, если бы она была там . Для них это было настоящей проблемой, потому что у них был веб-сайт, на котором они зарабатывали деньги. Он довольно сильно скрипел, потому что он довольно старый. Но в то же время восстановление всего веб-сайта стоило очень дорого, что делало проект очень и очень сложным. Нам удалось найти некоторые довольно умные, но также не очень приятные обходные пути до конца, чтобы попытаться использовать то, что у них уже было, и интегрировать это, но мы не можем цитировать, но вы знаете, в конечном итоге это оказалось намного более болезненным, намного медленнее и намного больше дороже, чем нужно. Если об этой архитектуре думали изначально.

ДВ: У меня так много проектов, что я хочу забыть об этом. Были именно такими, и я могу представить это сейчас, я возвращаюсь в прошлое. Так что, как по мне, это звучит довольно ясно, я думаю, что это очень важный урок, чтобы подумать о том, какие затраты для бизнеса связаны с рефакторингом, который вы планируете. И для меня это звучало как четкий ответ: вам нужно было спроектировать его по-другому. И это, может быть, более четкий путь, если вам нравится то, что вы должны делать. Но я думаю, как и многие команды, когда они думают о техническом долге, они думают так: «Хорошо, было бы круто сделать это, но стоит ли оно того?»

JM: Стоит ли мне поддерживать эту штуку в течение долгого времени? Так что мне просто любопытно, как вы думаете об этой формуле

ДВ : когда, например, когда можно вводить технический долг? И сколько всего, как вы думаете об этой формуле?

ДМ: Да, вы затронули действительно важный момент, вы знаете, что вы думаете о природе разработчиков, разработчики занимаются этим, потому что им нравится делать классные вещи. И это, как вы знаете, большая часть нашей мотивации состоит в том, чтобы научиться делать новые вещи, новые технологии, знаете ли, новые фреймворки JavaScript, что бы это ни было, и это, естественно, дает нам мотивацию, которая становится для создания крутых вещей, но мы не обязательно думаем об этом в долгосрочной перспективе, вы знаете, мы все равно собираемся поддерживать его. Вы знаете, моя жена хотела бы, чтобы у меня дома была гидромассажная ванна, но я знаю, что кто-то собирается ее чистить, и, честно говоря, я не верю никому, кто ее чистит, во всяком случае, это тип мышления. Так что это очень, очень, очень хороший вопрос для размышления, стоит ли оно того, в первую очередь, и если мы немного разберем его, есть несколько разных вещей, о которых вы могли бы подумать, прежде всего, долго думать. термин, какова общая стоимость владения и создания этой штуки, ее тестирования и обслуживания, а затем взвешивания ее по сравнению с ценностью, которую мы получаем? Так, например, может быть очень простой способ решить эту проблему. с помощью электронных таблиц или с использованием немного другой архитектуры, где, возможно, кто-то внутри компании управляет этим в течение короткого периода времени. И это было бы дешевле и эффективнее, чем создавать эту действительно сложную функцию. Но когда вы на самом деле посмотрите на общую стоимость владения, это будет стоить больше, чем если бы кто-то тратил пару часов в неделю на выполнение конкретной задачи. Не поймите меня неправильно. Я большой сторонник автоматизации. технологии должны максимально автоматизироваться, чтобы избежать такого администратора, но

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

ДМ: Да. 100%. Так что я большой сторонник методологии Agile. И, по сути, один из основных принципов Agile заключается в том, что вы создаете правильные вещи в нужное время. И вы сосредотачиваетесь на том, чтобы получить ценность как можно быстрее. Итак, вы хотите создать минимально жизнеспособный продукт. Теперь это означает, что у вас не обязательно есть что-то полнофункциональное на тот момент. Но это дает вам платформу, на которой вы можете начать тестировать его, знаете ли, вы действительно получаете от этого то, что хотите? Ваши пользователи реагируют на это? Вы ожидаете, что любой, кто работал в сфере UX или веб-разработки, будет знать, что довольно часто будут получать запросы от клиентов, потому что они думают, что их клиенты, но на самом деле они этого хотят? Итак, это еще один действительно хороший вопрос, который можно задать: после того, как вы как бы подумали о долгосрочной перспективе, люди, собирающиеся использовать веб-сайт, знаем ли мы, что кто-то будет его использовать, или нам нужно проверить, хотят ли они? использовать его? И затем, как только вы проведете этот тест, мы сможем решить, чего нам не следовало просить об этом, и должны ли мы отступить и на самом деле вложить наши инвестиции в другое место.

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

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

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

ДМ: Да, потому что каждая минута, пока этот сайт находится в разработке, — это минута, когда он не приносит пользы клиентам. И это простой способ думать об этом. Вы хотите запуститься как можно быстрее. А затем тестируйте, отслеживайте, итерируйте, учитесь, понимаете, смотрите, куда вы пойдете дальше, но только потому, что вы делаете это на основе фактических данных, а не того, что вы считаете правильным. Потому что очень часто они не совпадают.

ДВ: Да, мне нравится этот момент. Каждые минуты. Это в разработке, не так ли, как минуту, когда вы не используете это, выясните, и я скажу, что связи верны к своего рода связям с другой моей мантрой, а также управление проектами и управление заинтересованными сторонами, которые являются двумя лучшими словами и получение проекта на нашем лице, чтобы написать. Как вы можете говорить, да, мне нравится, когда я имею дело с заинтересованными сторонами, или когда у меня есть заинтересованная сторона, это мощная, мощная часть. Хорошо. Эм, давайте поговорим о том, что команды могут сделать, чтобы сократить технический долг. Но прежде чем мы это сделаем, мы сделаем последний перерыв. Пора включить рекламную паузу. Оставайтесь с нами, чтобы узнать больше об этом через мгновение. Добро пожаловать снова, чтобы поделиться этим подкастом сообщества WordPress на W EMR. Это ваш ведущий, Дэвид Мобайл, Пол, я как раз в середине разговора с Джоном Мартином о том, как избежать времени, убивающего технический долг, о том, как Джон прямо перед перерывом, мы немного поговорили о вашей формуле ценности. Мне очень понравились ваши идеи о сокращении спецификации И думать о совокупной стоимости владения, и о том, чтобы применить итеративный подход к тестированию. Но давайте теперь рассмотрим, что на самом деле могут сделать команды, чтобы уменьшить свой технический долг и сборки WordPress. Какие ваши любимые методы сокращения технического долга?

ДМ: Итак, есть все виды технических приемов, которые вы можете использовать, и вы знаете некоторые из них, с которыми вы были бы знакомы, так что вы не будете, но на самом деле отправной точкой для меня является гораздо более мягкий подход к разговору. вашим клиентам. И вы должны помнить, что в конечном итоге ваши клиенты — это бренды, которые обращаются к нам, потому что мы являемся экспертами. Им нужен наш совет, и довольно легко попасть в ловушку, что, знаете ли, мы здесь, чтобы просто делать то, что они хотят, что мы там, чтобы делать то, что они хотят, чтобы мы делали, но на самом деле мы там бросить вызов тому, что они хотят сделать, и попытаться улучшить это. Итак, первое, что вы можете сделать, это поговорить с ними об этом и объяснить, хорошо, если мы это сделаем, это будет иметь долгосрочный эффект. Знаешь, это займет у нас дополнительный день тестирования. Каждый раз, когда мы делаем релиз, он будет добавлять пару часов каждый раз, когда нам нужно поддерживать веб-сайт и обновлять все плагины или что-то еще. Но повышая эту осведомленность, мы ведем с ними эти беседы. Вы можете привлечь клиента к участию в этом обсуждении. И затем, в конце концов, они становятся частью решения проблем, и нам приходится постоянно обучать наших клиентов просто потому, что они не знают некоторых вещей, которые делаем мы. Если бы они это сделали, они не стали бы инструментами в первую очередь. Собственно, это и есть отправная точка. Он думает, что нужно помнить об этом, а также упрощать вещи. Опять же, люди не обязательно такие техничные, как мы. Поэтому используйте аналогии, чтобы говорить об этом. Я всегда нахожу, что дома — это великая энергия. Все живут в доме. У большинства людей есть некоторый опыт выполнения какого-либо улучшения дома. Так что было довольно легко использовать эту энергию, чтобы что-то исправить. Итак, первое, что нужно сделать, это заполучить клиента или зациклить эти разговоры. Следующее, чего мы коснулись ранее, — это долгосрочное видение или общая стоимость владения. И задавайте себе эти вопросы и подвергайте сомнению каждый запрос функции. Но быть немного более техническим и как вы будете делать это на работе. Простые вещи, которые вы используете, стандарты WordPress вы знаете, есть стандарты, которые существуют. Они существуют по какой-то причине. Теперь они помогут нам, разработчику, и, может быть, вы работаете над проектом, который вы откладываете на год или два, а затем возвращаетесь к нему. Вам нужно освежить свою память, и вы вернетесь туда, где вы были, когда вы впервые построили его, используя стандарты, которые помогут. Они также помогут другим людям. Так что, если вы не были в команде, это означает, что у вас есть этот общий язык, с которым может работать каждый, который очень, очень полезен с точки зрения эффективности и помогает с документацией и всем этим. Так что это своего рода более мягкий способ уменьшить ваш технический долг за счет наличия стандартов, с которыми может работать любой. Это также поможет вам узнать, что может наступить время, когда некоторые другие разработчики WordPress будут работать над этим проектом. И это помогает им думать об этом как о способе отплатить сообществу и облегчить жизнь вашим коллегам-разработчикам. Итак, это, знаете ли, хороший момент в отношении стандартов и облегчения для себя и других. Следующий больше о великом. Великий кодекс индустрии, ласково известный как дядя Боб, написавший замечательную книгу под названием «Чистый кодер» много-много лет назад. Я настоятельно рекомендую любому разработчику прочитать эту книгу, потому что они ее не читали. На самом деле, я сделал это обязательным чтением для команды разработчиков, для всех, кто присоединился к команде, в основном потому, что у него такой хороший подход к этому, он говорит о модульном тестировании, обо всем этом, но, по сути, о многом. касается того, как вы пишете код таким образом, чтобы он был гибким, чтобы вы могли очень быстро повторять, изменять и добавлять в него дополнительные биты. Один из важных моментов, о которых он говорит, касается частого рефакторинга, и главное, что нужно извлечь из него, это то, что вы пишете кусок кода, который не обязательно означает, что этот кусок кода закончен. Есть вещи, которые вы можете сделать, чтобы оптимизировать его, чтобы сделать его более переносимым, сделать его более модульным или улучшить тесты, независимо от того, что конкретно вам нужно сделать, чтобы потратить время на рефакторинг кода. Это может быть очень, очень трудно сделать, когда вы сталкиваетесь с этим или знаете, может быть, это один временной интервал для бюджета. Но, в конечном счете, это тот тип вещей, который остановит вас от накопления технического долга, и на самом деле, обычно именно так, как я вижу, это происходит принудительно, но поскольку срок проекта установлен, вы должны уложиться в этот срок. Абсолютно. Вы должны поразить его, но лучше сгибать область видимости, чем писать плохой код, который вы потом собираетесь,

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

ДМ: Да. 100% Так что это хороший способ, но на самом деле это хороший способ сделать и то, и другое, вы можете избежать технического долга. Но вы также можете, и это, как вы знаете, WordPress — это одна из форм BMC. Он настолько активен, что может быть и его злейшим врагом. Есть плагин, который делает все. Также существует множество плагинов, созданных для очень специфических целей, но они не обязательно соответствуют вашим собственным плагинам. Так что я видел это, в частности, с некоторыми разработчиками, которым нравится создавать сайты с использованием плагинов и своего рода подход «укажи и щелкни» к вещам, а не кодирование с нуля. Люди склонны бросать плагины на вещи. Мы работали с веб-сайтами, у которых было более 100 плагинов, и многие из них больше не поддерживаются. Во всем этом есть проблемы с безопасностью. Ты попробуй и сделай скорость выпуска. Вы тратите буквально четыре дня на его тестирование, хотя могли бы сделать это за пару часов. Итак, плагины могут быть хорошими или плохими. Правильное подключение в нужное время было замечательной вещью. Самые сильные стороны WordPress, но неправильный подключаемый модуль в неподходящее время также может нанести серьезный ущерб. И на самом деле может быть одним из тех крупнейших источников капитала, которые

ДВ: У меня точно был такой проект. Что ж, Джон, это было невероятно познавательно. Большое спасибо, что присоединились к нам сегодня.

ДМ : С удовольствием.

ДВ: Потрясающе. Если вы хотите узнать больше о Джоне, вы можете посетить hallam.co.uk. Спасибо всем за то, что слушали пресс-подкасты сообщества WordPress на WMR. Опять же, это был ваш ведущий Дэвид Фогельпол. Я поддерживаю сообщество WordPress как часть своей роли в WP Engine, и мне нравится приносить лучшее из сообщества здесь, в Press This.