Ваши утверждения верны. Погрешность у измерений присутствует, сколько бы проверок не было. 5 — среднее значение, которое эту погрешность сглаживает. И мы смотрим разрез всех проверок в течение месяца, а не ориентируемся на ежедневные отчеты, от этого строится вполне объемная картина.
Спасибо за очень важные вопросы.
1.Да. Мы выбрали недельные спринты что бы декомпозировать задачи по созданию компонентов на небольшие.
2. Иногда зависят, мы обозначаем ddl для таких кейсов. Если есть альтернативы в нашей библиотеке компонентов — они используют то что есть. Криты и блокеры по компонентам у нас в 0 приоритете.
3. Наша команда собирает потребности и области применения компонента в компании. Если потребность есть у нескольких команд или только у одной, но есть гипотеза что остальным тоже понадобится — такой компонент попадает в дизайн систему. Команды пишут свои велосипеды если этот велосипед слишком уникален.
4. Примерно 15 команд в нашей компании используют дизайн систему.
Спасибо за вопрос! У нас есть скриншот тестирование, на основе разработанной у нас в компании фреймворка, мы запускаем тесты как и в самой библиотеке компонентов, так и на продуктов после внедрения. Мы думали о кодмодах (или скрипты миграции) для легкого перехода на новые версии компонентов, но рассчитав трудозатраты на создание такого подхода мы поняли, что это будет очень не дешево. Поэтому мы описываем braking changes в readme компонента и надеемся на автотесты
Спасибо за вопрос! Забыл про это указать в статье. Да, конечно прорабатываем, стараемся поддерживать скрин ридеры, учитываем все комментарии lighthouse по доступности контента для людей с ограниченными возможностями. W3C соблюдаем, но пока что все проверки у нас не автоматизированы, планируем добавить в ci/cd quality gate, используя библиотеку www.npmjs.com/package/node-w3c-validator
Ой как все плохо. А как же es6, как же наследование компонентов через extend. Зачем каждый раз в представлении писать this.state…. и вытаскивать данные, если красивее вытащить их в начале рендера, а на es6 еще красивее через let. Можите заминусить но сделать этот функционал на react-starter-kit будет намного приятней
1.Да. Мы выбрали недельные спринты что бы декомпозировать задачи по созданию компонентов на небольшие.
2. Иногда зависят, мы обозначаем ddl для таких кейсов. Если есть альтернативы в нашей библиотеке компонентов — они используют то что есть. Криты и блокеры по компонентам у нас в 0 приоритете.
3. Наша команда собирает потребности и области применения компонента в компании. Если потребность есть у нескольких команд или только у одной, но есть гипотеза что остальным тоже понадобится — такой компонент попадает в дизайн систему. Команды пишут свои велосипеды если этот велосипед слишком уникален.
4. Примерно 15 команд в нашей компании используют дизайн систему.