Ускорьте рабочий процесс при создании тем WordPress

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

Как бы выглядел такой рабочий процесс? И как вы можете применить некоторые передовые практики в повседневной работе, чтобы ускорить доставку? Что ж, есть несколько способов разобраться в этом. Первый:

Улучшения технического рабочего процесса

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

Предложение 1. Подготовьте тему для начинающих

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

Как это помогает?

1. Нет необходимости каждый раз выполнять настройку Gulp. Все пакеты есть "из коробки", они запускаются, конфигурация проверена более чем на одной машине.
2. Поставляется с краткой документацией. Если есть новые члены команды, им не нужно задавать вопросы об основных задачах настройки, поскольку большая часть из них уже объяснена.
3. Нет необходимости каждый раз выбирать файловую структуру для внешнего интерфейса. В основном наша команда разработчиков работает над новой темой с первого дня, поэтому, если им придется каждый раз придумывать структуру папок / файлов для файлов Sass, мы потратим часы на проект.
4. Мы сохраняем все согласованно - это еще один огромный импульс. Обычно одновременно активно несколько проектов, поэтому знание того, где найти то, что вы ищете в первый раз, при открытии проекта позволяет значительно сэкономить время. Имея одинаковую структуру для всех тем, стили, файлы JS, файлы PHP находятся в одном месте.

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

Предложение 2 - Сохраняйте тот же стиль кодирования и подходы

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

Вы можете посмотреть, например, руководство по стилю кодирования HTML / CSS от Google.

Источник

Общие способы называть «Запись» или «Комментарий» или способы управления «списками», такими как .list-<name> и т.п., являются одними из стандартных подходов, которые мы используем при создании макетов.

Предложение 3 - Улучшите вашу локальную рабочую настройку

Быстрый способ навигации между проектами сам по себе значительно экономит время. Просто $cd'ing между каталогами может легко занять полчаса в день. Это все потраченное время. Вместо этого вы можете настроить TMUX на своем компьютере, настроить отдельное окно для каждого проекта и отдельную панель для каждой задачи / цели, например «Запуск Gulp» - панель 1; «Выполнение команд в теме» - панель 2; «Запуск команд в плагинах» - панель 3.

Вдобавок убедитесь, что вы можете открыть редактор кода прямо из терминала. Это более быстрый способ приступить к программированию, чем открытие с помощью значка, затем переход к «открытому проекту» и тому подобное. VS Code очень легко настроить.

Используйте свои инструменты лучше

• Код VS, Sublime text и многие другие инструменты имеют всплывающее окно «Command», где вы можете вводить практически все, что может сделать редактор. Сохранить все открытые документы? Всего несколько кнопок. Закрыть их? Все так же.
• Перемещайтесь по палитре команд - просмотр файлов на боковой панели тоже занимает слишком много времени. Просто напишите нужное имя файла. Добавьте расширения для ускорения общих операций, таких как переименование, перемещение, дублирование и удаление файлов.
• Настроить линтеры. Нет нужды тратить время на форматирование файлов, если есть инструменты, которые могут сделать это за вас. Каждый раз, когда вы делаете отступ в коде, добавляйте пробелы между скобками и т. Д. Может быть лучше потрачено на решение проблем.
• Используйте ярлыки и сниппеты - для фронтенд-разработчиков Эммет - спаситель. Простые однострочные nav>.site-nav>ul.list-items>li.list-item*5>a{title} вроде: nav>.site-nav>ul.list-items>li.list-item*5>a{title} расширяются до 15+ строк кода HTMl, все отформатированные и готовые к стилизации. Ввод этой строки занимает секунды.

Пример палитры команд VSCode. Вы можете прочитать намного больше на их странице обзора.

Принятие решений для улучшения рабочего процесса

Это может быть немного сложнее и может потребовать большего опыта и понимания бизнес-потребностей клиента. Это также один из наиболее ответственных подходов, но иногда именно он может спасти проект от срыва сроков.

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

Делегируйте работу на ранней стадии, но старайтесь поддерживать низкое общее количество вовлеченных людей. Это то, что каждый замечает на определенном этапе. Возможно, самый ранний - в школе, когда 10 детей приступают к работе над проектом, но только двое или трое делают большую часть работы.

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

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

Хорошее время для добавления дополнительных разработчиков внешнего интерфейса будет тогда, когда будет сделана большая часть фундаментальной работы и работа может быть делегирована отдельным компонентам, таким как «Карты содержимого», «Целевая страница X» или «Страница 404» и тому подобное. К тому времени шрифты применяются, общие настройки типографики устанавливаются, создается большинство файлов и создается как минимум 1-2 страницы.

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

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

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

В итоге:

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

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