Разработчики WordPress: начните здесь!

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

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

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

От идеи до внедрения  

Независимо от того, работаете ли вы над новым продуктом или взялись за работу с клиентом, процесс перехода от идеи к внедрению состоит из 4 этапов. Хотя эти этапы дискретны, они значительно перекрываются и не являются линейными. Мы обсудим это далее в тексте:  

1. Мозговой штурм и выявление требований.
2. Прототипирование.
3. Разработка.
4. Развертывание.

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

Основополагающих принципов мозгового штурма два. Стремитесь к количеству и отложите решение на потом. Ранее мы уже писали о том, как вы можете организовать такую ​​сессию, как сформировать правильное мышление и какие необычные инструменты помогут вам в этом.

Выявление требований

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

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

Вам, вероятно, потребуется организовать структурированные интервью со всеми заинтересованными сторонами, если вы хотите получить информацию о требованиях к сложным продуктам. Для этого пользовательские истории — идеальный способ. Они являются частью мышления Agile и представляют собой неформальный способ начать обсуждение требований, чтобы добиться общего понимания. Краткие описания функций записываются на бумажных карточках, обычно на стикерах Post-It, и перетасовываются на доске, создавая повествование о пути пользователя. Пользовательские истории генерируются на месте путем участия, обсуждения и манипулирования карточками на доске. Детали постепенно уточняются и, наконец, добавляются в качестве функций в бэклог продукта. Джефф Паттон написал прекрасную книгу о картировании пользовательских историй, которую мы настоятельно рекомендуем, если вы хотите узнать больше об этом предмете и начать использовать его в своих проектах.

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

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

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

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

Вот где Pressidium Cloning пригодится. Он позволяет быстро клонировать веб-сайт одним щелчком мыши и приступить к разработке. Таким образом, вы можете подготовить несколько шаблонных веб-сайтов, используя шаблоны, предварительно загрузить их с необходимыми плагинами, темами и конфигурацией и клонировать их каждый раз, когда они вам понадобятся в проекте. Вы также можете таким же образом клонировать их на другой аккаунт Pressidium, например, на аккаунт вашего клиента. Не беспокойтесь, если ваши прототипы находятся на другом управляемом хостинг-провайдере WordPress. Просто воспользуйтесь нашим Мастером миграции и импортируйте их в свою учетную запись Pressidium!

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

1. Практика хороших программных привычек.
2. И зная, что все есть, где это и почему оно там.

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

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

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

Разместите свой сайт с Pressidium

60- ДНЕВНАЯ ГАРАНТИЯ ВОЗВРАТА ДЕНЕГ

ПОСМОТРЕТЬ НАШИ ПЛАНЫ

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

Кроме того, поскольку производительность сайтов WordPress сильно зависит от правильного использования кэша браузера, важно знать, как ваш управляемый хостинг-провайдер WordPress использует кэширование. Затем ваш код будет работать синергетически с вашей платформой хостинга, чтобы обеспечить максимально возможную производительность. Однако имейте в виду, что правильное измерение скорости вашего веб-сайта не так просто, как может показаться, и оно содержит несколько ошибок!

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

  Мы написали краткое введение и руководство по WordPress REST API , а также простой способ начать работу с ним с помощью плагинов для браузера, таких как Postman.

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

Мы использовали объекты WordPress, такие как категории и сообщения, для моделирования канбан-доски с задачами, столбцами и потоком создания ценности. Мы набросали Kanban Columns and Cards API, который связал все вместе.

Документация

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

Неважно, как вы на это смотрите, документация — это актив.  

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

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

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

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

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

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

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

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

В будущем мы углубимся в UML, особенно в другую полезную нотацию, называемую диаграммами последовательности, а также в более подробные примеры диаграмм сценариев использования, чтобы уточнить требования проекта и построить прототипы.

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

Если вы являетесь клиентом Pressidium, вы можете интегрировать свой репозиторий со своей учетной записью через SFTP с помощью внешней службы, такой как deploybot. В качестве альтернативы вы можете использовать SFTP для передачи файлов в свою учетную запись, так как это самый простой и понятный метод. Вы также можете создать несколько пользователей SFTP и назначить их определенным веб-сайтам и средам. Говоря об этом, наличие тестовой среды для вашего веб-сайта гарантирует, что ваш процесс разработки и развертывания будет более оптимизированным, а ваш рабочий веб-сайт защищен от нежелательных изменений. Например, включив промежуточную подготовку для своего веб-сайта, вы можете извлечь копию из рабочей среды, а затем создать учетную запись SFTP для своего разработчика, которая имеет доступ только в промежуточной среде.

Настройка оптимизированного конвейера разработки, проходящего через несколько сред, — одно из изменений, которые движение DevOps привнесло в ИТ-среды. Принятие дисциплины Continuous Delivery и постепенное и частое внесение изменений в программное обеспечение приводит к более быстрым циклам развертывания и меньшему количеству ошибок. Вам больше не нужно поддерживать ZIP-архивы с разными версиями вашего приложения. Таким образом, вы можете легко потерять след и внедрить неправильный набор изменений, которые могут нанести вред вашим производственным системам. Также существовала опасность возникновения проблем с искажением прав доступа к файлам, что в лучшем случае могло привести к тому, что ваше приложение не работало должным образом, а в худшем - вызвать проблемы с безопасностью.

Эпилог

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