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

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

  1. Все необходимые изменения будут отмечены в PR. Все комментарии должны быть разрешены до того, как PR будет объединен с кодовой базой FMIC.
  2. Если PR был создан, но не готов к объединению с кодовой базой FMIC, PR должен иметь статус черновика.
  3. PR должен соответствовать критериям приемлемости, указанным в билете Jira. Пожалуйста, оставьте примечания в PR для любых дополнительных изменений или проблем разработчиков, которые необходимо решить.
  4. PR не будет рассмотрен, если после создания PR не пройдены все тесты.

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

Стандарты JavaScript и CSS
При написании CSS, как и многие другие разработчики, мы решили придерживаться Руководства по стилю Airbnb CSS/Sass. Руководство Airbnb по стилю CSS/SASS многие разработчики считают золотым стандартом подхода к написанию CSS. Их подход к форматированию CSS поощряет комбинацию OOCSS и BEM, чтобы помочь разработчикам писать код, который можно повторно использовать, масштабировать, допускает меньше вложенности и меньше специфичности при написании CSS.

При написании JavaScript мы также решили придерживаться Руководства по стилю JavaScript Airbnb. Их руководство по стилю JavaScript включает в себя простые, но хорошо задокументированные рекомендации, которым следует следовать при написании JavaScript. Кроме того, как команда, мы решили, что при написании JavaScript также будем придерживаться следующих правил.

  1. Максимально сведите к минимуму использование jQuery. Если PR включает использование jQuery вместо ванильного/простого JavaScript, укажите причину в описании PR.
  2. При выборе одного или нескольких элементов с помощью клиентского JavaScript всегда используйте селектор CSS, нацеленный на атрибут данных. Это гарантирует, что любой клиентский JavaScript, нацеленный на этот конкретный элемент, может быть легко найден в кодовой базе. Кроме того, это гарантирует, что классы используются специально для CSS, что обычно позволяет избежать путаницы при поиске в кодовой базе.

HTML
<button class=”btn-primary” type=”button” data-example-attribute>This is a Button</button>

JavaScript
const exampleButton = document.querySelector(“[data-example-attribute]”);

Шаблоны ISML
Кроме того, при рассмотрении PR, которые включают в себя картриджи, отличные от нашего основного картриджа, используемого для Fender.com (PreSonus, Jackson и любые другие бренды Fender, которые будут добавлены в SFCC в будущем), внутренние разработчики также просмотрите шаблоны ISML, чтобы убедиться, что повторяющиеся файлы не добавляются в кодовую базу без необходимости. Поддержание только необходимого количества шаблонов ISML помогает команде создавать новые функции сайта для всех сайтов SFCC намного быстрее, поскольку нет необходимости дублировать изменения в нескольких шаблонах брендов.

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

  • Создание новых модульных тестов для всех недавно созданных пользовательских серверных функций.
  • Заполнение модульных тестов путем изменения модульных тестов в репозитории SalesforceCommerceCloud/storefront-reference-architecture и изменения их для работы с нашими измененными файлами в org_fmic.
  • Заполнение модульных тестов, нацеленных на важные для бизнеса функции сайта.

Salesforce включает набор модульных тестов в свой репозиторий Github, содержащий эталонную архитектуру Storefront (SFRA). Однако большая часть основных функций сайта была перезаписана в нашем пользовательском картридже org_fmic. В этом случае мы не могли просто скопировать и вставить модульные тесты, включенные в репозиторий SFRA, и ожидать, что все тесты пройдут. Хотя эти включенные модульные тесты дали нам отправную точку для работы, большинство из этих тестов будут изменены для работы с кодом в org_fmic, измененным из app_storefront_base. Эта практика изменения существующих модульных тестов принесла немало пользы нашей команде, предоставив разработчикам опыт работы с модульными тестами без необходимости писать их с нуля. Как только разработчики SHOP приобрели некоторый опыт заполнения модульных тестов, это дало нам необходимую основу для написания модульных тестов с нуля для всех недавно созданных серверных функций.

Любой, кто когда-либо писал модульные тесты, знает, что одним из наиболее трудоемких аспектов модульного тестирования является имитация всех объектов и служб, на которые опирается тестируемый код. Для этого мы можем использовать репозиторий SalesforceCommerceCloud/dw-api-mock. Этот репозиторий содержит макеты для многих классов и объектов Demandware, которые активно используются в проекте. Использование этого репозитория помогло нам добиться успехов в создании нашего набора модульных тестов, чтобы обеспечить лучшее покрытие кода. Несмотря на то, что предстоит еще много работы, чтобы заполнить все необходимые модульные тесты, наша команда проделала большую работу по этой инициативе в прошлом году.

Ресурсы по модульному тестированию для разработчиков

Добавление Linting обратно в наш репозиторий SFCC

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

  1. Дает вам предупреждения, когда код может быть не интуитивно понятным
  2. Предоставляет предложения для общих передовых практик
  3. Это поддерживает единый стиль кода в команде разработчиков и, следовательно, экономит время во время проверки кода.
  4. Linting помогает уменьшить количество ошибок и повысить качество кода.
  5. Линтинг улучшает читаемость кода
  6. Функция автоисправления может автоматически исправлять многие ошибки

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

В начале года линтинг всех наших файлов JavaScript был по существу отключен, поскольку все основные каталоги нашего проекта были перечислены в файле .eslintignore. Это было сделано потому, что мы запускали наш проект на устаревшей версии узла, а пакет eslint-loader устарел, что не позволяло корректно анализировать все наши файлы без ошибок.

Поскольку eslint-loader устарел, мы нашли подходящую замену для перехода на eslint-webpack-plugin. Эта работа была завершена в нашем файле webpack.js.config. Ниже показано, как выглядел наш старый файл.

const config = {
  module: {
    rules: [
      {
        test: /\.js$/,
        exclude: /node_modules/,
        loader: 'eslint-loader',
        options: {
          // eslint options (if necessary)
        },
      },
    ],
  },
}

После перехода на новый пакет

const ESLintPlugin = require('eslint-webpack-plugin');

const config = {
  plugins: [new ESLintPlugin(options)],
}

Обновление этого пакета теперь позволило нам линтинговать весь JavaScript в кодовой базе и полностью использовать пакет eslint. Важной особенностью этого пакета является его способность автоматически исправлять многие ошибки линтинга в нашем проекте.

Fixing problems:
  --fix                           Automatically fix problems
  --fix-dry-run                   Automatically fix problems without saving the changes to the file system
  --fix-type Array                Specify the types of fixes to apply (directive, problem, suggestion, layout)

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

npx eslint --fix allourdirectories

Далее нужно было добавить линтинг в наш процесс сборки. Для этого мы отредактировали параметры в новом установленном пакете плагинов.

plugins: [
            new ESLintPlugin({emitWarning: true,
                emitError: false,
                failOnError: false,
                failOnWarning: false,
                quiet: true})
        ]

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

Поддержание работоспособности кодовой базы необходимо не только для предотвращения проникновения ошибок в рабочую среду, но и для поддержки масштабируемой платформы, которая может поддерживать быструю разработку новых функций сайта. Чтобы достичь этого, команда SHOP добавила стандарты линтинга обратно в наш репозиторий SFCC для электронной коммерции, улучшила процессы, связанные с проверками кода и управлением внутренними и контрактными PR разработчиков, внедрила стандарты разработчика JavaScript и CSS, а также начала устранять и ограничивать ненужные и повторяющиеся ISML-шаблоны. Поскольку команда SHOP вступает в 2023 год, мы уверены в своей способности решать инициативы по продуктам, а также поддерживать и внедрять передовые методы обеспечения работоспособности кодовой базы.

- В соавторстве с Диланом Кроушоу и Габи Ветор