Ростислав Royroev

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

Все так, в pipeline интегрирована утилита, которая в зависимости от типа проекта, делает запрос к API Front Radar с разным набором параметров

Все таки Web Core, т.к. мы решаем намного больше задач, чем просто пилить фронт) Спасибо за замечание, исправили!

В очень редких случаях

Спасибо! У нас самописная витрина, было так решено, когда еще не было Storybook на TS, теперь появилась, может быть и попробуем.

Спасибо за очень важные вопросы.
1.Да. Мы выбрали недельные спринты что бы декомпозировать задачи по созданию компонентов на небольшие.
2. Иногда зависят, мы обозначаем ddl для таких кейсов. Если есть альтернативы в нашей библиотеке компонентов — они используют то что есть. Криты и блокеры по компонентам у нас в 0 приоритете.
3. Наша команда собирает потребности и области применения компонента в компании. Если потребность есть у нескольких команд или только у одной, но есть гипотеза что остальным тоже понадобится — такой компонент попадает в дизайн систему. Команды пишут свои велосипеды если этот велосипед слишком уникален.
4. Примерно 15 команд в нашей компании используют дизайн систему.

Спасибо за вопрос! У нас есть скриншот тестирование, на основе разработанной у нас в компании фреймворка, мы запускаем тесты как и в самой библиотеке компонентов, так и на продуктов после внедрения. Мы думали о кодмодах (или скрипты миграции) для легкого перехода на новые версии компонентов, но рассчитав трудозатраты на создание такого подхода мы поняли, что это будет очень не дешево. Поэтому мы описываем braking changes в readme компонента и надеемся на автотесты

она внедрена в нашу библиотеку уже на 40%, когда сделаем на 100% — будем внедряться в продукты.

Спасибо за вопрос! Забыл про это указать в статье. Да, конечно прорабатываем, стараемся поддерживать скрин ридеры, учитываем все комментарии lighthouse по доступности контента для людей с ограниченными возможностями. W3C соблюдаем, но пока что все проверки у нас не автоматизированы, планируем добавить в ci/cd quality gate, используя библиотеку www.npmjs.com/package/node-w3c-validator

Спасибо за статью! Очень полезно

Ой как все плохо. А как же es6, как же наследование компонентов через extend. Зачем каждый раз в представлении писать this.state…. и вытаскивать данные, если красивее вытащить их в начале рендера, а на es6 еще красивее через let. Можите заминусить но сделать этот функционал на react-starter-kit будет намного приятней