Development

Storybook помогает тестировать фичи, но только визуально. Для тестирования интерактивности, разработчики вынуждены писать отдельные тесты. Тут появляется логичное желание переиспользовать код историй и для тестов. Истории в сторибуке уже содержат компоненты в разных состояниях готовым кодом. Но сейчас нельзя просто так использовать компоненты из историй, потому что они могут быть завязаны на специфичные декоракторы и специфику сторибука. Для решения этой проблемы команда сторибука сделала возможность получить истории с готовыми декораторми в юнит-тестах компонентов. Выглядит как волшебная пилюля, но не каждый декоратор мы захотим добавлять в jest тесты. Например, использующие DOM API, которое для таких тестов не важео, а в JSDOM его нет - тест просто упадет. С другой стороны, можно руками выделить чистые компоненты, которые импорятся и в сторибук и в тесты. То есть, с одной стороны круто конечно что команда сторибука работает над нативной интеграции сторибука с другими инструментами тестирования. С другой стороын, все как обычно в блог-постах сторибука: - сторибук преувеличил проблему. - как всегда, поддержка пока только для реакта.

Очередная подборка расширений для фронтенда на VSCode. Отличительная черта этого списка - он от smashing magazine, что автоматически добавляет +100 к качеству статьи.

Патентные троли добрались до pwa. Как я понял, PWA запатентовали в USA (вместе с мини-аппами) и теперь "изобретатель" PWA в праве требовать лицензионных отчислений со всех сайтов, использующих PWA в правовом поле США. Никогда такого не было, и вот опять

Продукт постоянно должен развиваться. Это естественное состояние вещей. Но как развивать продукт? Как работать с рисками, что новая фича "не взлетит"? Для разных вещей нужны разные подходы. В идеальном мире для разных контекстов мы можем использовать: - MVP - AB тесты - Работу с фидбеком или реализацию запросов от пользователей - Просто сделать и посмотреть В разных контекстах в рамках одного продукта могут подходить разные инструменты, в зависимости от уверенности в успехе фичи и количества пользователей, которым фича нужна. Проблема идеального мира - его не существует. Поэтому надо уметь снимать риск "делаем не то, что нужно", другими способами. MVP вероятно один из самых популярных фреймворков. Его проблема в том, что часто команды используют его не к месту. Команды не так часто делают именно MVP. Вместо него, если мы примерно понимаем что ъотим получим и почему, следует сфокусироваться на итерационной поставке функционала и адаптации плана на основе фидбека от пользователей.

"Мы начинали маленькой командой и делали все быстро. Сейчас мы в 10 раз больше, а работаем медленнее, чем когда нас было в 10 раз меньше." - классическая история про проблему роста. В статье разбирается, почему так происходит и что нужно делать. Все советы основаны на "честном слове" (нет пруфов). Тлдр: - Разработчики должны быть частью бизнеса и принимать решения, а не просто писать код и двигать тикеты - Автономные кроссфункциональные продуктовые команды - благо - У бизнеса должна быть продуктовая стратегия, на основе которое можно принимать решение (заработать много денег - это не стратегия)

Короткая статья про достаточно занятное исследование, которое показало, что люди предпочитают добавлять, а не убавлять. Т.е. можно сказать, что есть такое когнитивное искажение - если что-то нужно исправить, то исправлять надо добавлением чего либо. Как это проявляется в IT? Чаще всего в виде костылей-подпорок С точки зрения кода: у нас есть какая-то проблема в коде, разработчик добавляет новые параметры или абстракции. С точки зрения процессов: у нас есть проблемы в код-ревью - люди невнимательно смотрят, проскакивают баги. Что делать? Надо сделать его более строгим и формальным, добавить еще пару политик в КР. С точки зрения процессов 2: мы не попадаем в оценки. Что делать? Надо лучше оценивать, для этого начинаем усложнять процесс оценок С точки зрения продукта: мы делаем фичу, и часть фичи имеет достаточно хитрые граничные случаи. Что делать? Надо все их предусмотреть. Во всех этих случаях люди редко рассматривают альтернативу "ну если оно плохо работает - может просто дропнем?". Отчасти это можно обьяснить тем, что мы можем не знать зачем что-то сделано и поэтому убирать это что-то - небезопасно С другой стороны это связано с тем, что мыслительные эксперименты не кажутся "тяжелыми". Если давать людям задачу - сделай симметричный узор из 20-килограммовых камней, то они достаточно быстро найдут оптимиальное решение т.к. 20 килограм это вам не точки рисовать на канвасе. Но при всем этом, считаю что когнитивное искажение имеет место быть и его нужно уметь видеть и работать с ним

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

Typehole - расширение для vscode, добавляющее описание интерфейса typescript на основе данных в рантайме. Как это работает: - допустим вы делаете запрос в апи и не знаете что оттуда приходит - вы оборачиваете res.data в специальную функцию typehole - typehole в рантайме проверяет объект и отсылает в редактор описание интерфейса - расширение добавляет интерфейс в код Выглядит волшебно

Stackblitz сделали возможным запуск nodejs прямо в браузере. На wasm написано окружение, умеющее запускать nodejs приложения. Сам stackblitz разрабатывают онлайн IDE. Вместе это позволяет писать nodejs код, запускать сервер и дебажить его прямо в браузере. Из фичей: - нативная интеграция с дебагером хрома - чистое окружение при релоаде вкладки - быстрая установка нпм пакетов - возможность открыть код проекта, сразу его запустить и посмотреть как это работает. Звучит круто для кодревью Рекомендую к чтению, очень интересный концепт

Отличный инструмент, визуализирующий работу обработчиков событий в DOM

Статья о том, как разобраться с большим количеством багов путём внедрения баг полиси и формулы для определения серьезности бага Тлдр: Во многих продуктах есть проблема огромного количества багов с прода. Разработчики не могут понять, что нужно фиксить, в каком приоритете, и какие сроки поставить на решение проблемы Первая часть решения - внедрения баг полиси. Если совсем утрировать, то баг полиси предлагает разделить баги на две категории: надо фиксить или не надо фиксить. Многие баги можно не фиксить. Не настолько они критичны. Для тех которые все таки нужно пофиксить надо определить, а в какой срок их надо пофиксить. Тут нам помогает заведение специальной формулы, расчёт которой можно автоматизировать в эксель. В формулы вводятся параметры, например количество задетых пользователей, задетый компонент, есть ли обходной путь у пользователя. А на выходе - за какое время надо пофиксить

GitHub в своем блоге поделились использованием feature-flags в своей разработке Feature flags позволяют раскатить изменения не на всех пользователей, а также, в случае факапа - быстро все откатить. Интересно то, как они используют feature flags. С помощью флажков в GitHub можно разметить: - пользователей - репозитории - приложения - просто часть запросов Получается достаточно гибкая система для тестирования новых фич. Если нужно что-то другое, то есть возможность описать свой контекст. У feature flags есть своя цена. Для проверки состояния флажка нужно всегда делать запрос в MySQL, memcached. Чтобы это все было быстро, приходится заморачиваться с инфраструктурой. Для удаления флагов из кода используется автоматика, которая сама открывает пул реквест спустя какое-то время, в котором удаляется использование флага.

Про циклы обратной связи в общем виде. Циклы обратной связи могут быть: - быстрые или медленные - точные (accurate) или неточные Получается 4 вида циклов. Неточные циклы означают, что в результате действия мы получаем зашумленные (noisy) результаты. С разными циклами нужно работать по разному. Хотя с точными и быстрыми все понятно, поэтому статья фокусируется на неточных циклах. В реальной жизни очень многие циклы обратной связи - неточные. Надо учиться с ними работать. Один из антипаттернов - попробовать сделать эти циклы быстрыми и точными. В этом случае большой шанс либо считать не то, что надо, и соответственно улучшать не те метрики. Либо попасть в локальный максимум т.к. уход из локального в максимума в еще больший максимум будет остановлен быстрым циклом обратной связи, который скажет что стало хуже.

Краткий обзор по Enum - зачем вообще нужны перечисления - альтернативы - подводные канми - личное мнение автора по Enum tldr: используйте const string Enum, если вам не нужно иметь обратный мапинг (значение => ключ) т.к. при использовании const enum в рантайме нет словаря. Если нужно иметь мапинг - то string Enum. Это решение практически не имеет проблем на граничных случаях.

Typescript имеет unsoundess типы. Это значит, что тайпскрипт не дает гарантии, что типы переменных в рантайме соответствуют типам переменных, указываемых при описании переменных. Typescript, как проект, никогда не ставил своей целью soundness системы типов. Но одна из целей проекта - быть по максимуму совместимым с JS кодом. В статье указываются 7 самых частых источников расхождения типа в рантайме

Безумно крутая либа для создания приложений на основе графов.

Статья про управление зависимостями в JS мире. Описано как: - Проводить анализ зависимостей - Находить неиспользуемые зависимости - Удалять дубликаты пакетов - Поддерживать зависимости в актуальном состоянии - и еще пара советов С одной стороны не слишком глубокий обзор, с другой стороны - хорошая шпаргалка, если пришло время "причесать" зависимости

The ½ kb state machine hook for React.

Короткий обзор фичей в react, которые улучшили перформнас react-приложений

Статья в блоге Фаулера про платформенные команды. Если коротко: мы хотим чтобы разработка была сфокусирована на бизнес-фичах. Поэтому выгодно аутсорсить не связанные с бизнес-фичами компетенции: инфраструктура, логирование и тд и тп. Иногда может быть принято решение об использовании внешних сервисов (например aws), а иногда может быть принято решение о создании внутренней платформы. Внутренняя платформа ставит своей целью облегчение жизни продуктовых команд. При этом эта платформа должна быть экономически выгодна, т.е. затраты на поддержку платформы должны а) перекрываться скоростью и стабильностью работы продуктовых команд б) быть меньше чем затраты на внешнюю платформу (aws например). Команда поддержки платформы должна использовать все практики продуктовых команд. Они, по сути, и являются продуктовыми командами, которые предоставляют продукт для внутренних команд разработки и конкурируют с внешними продуктами. Каждая платформа должна быть готова к тому, что она устареет и с нее надо будет сьезжать. В целом, для обеспечения максимального качества и выгоды, внутренние платформы должны быть продуктами и конкурировать с внешними продуктами. В таком контексте внутренние платформы могут быть эффективным решением. Если убрать одно из условий, то платформа скатится в платформу ради платформы, которая не очень помогает бизнесу расти.

FoalTS - nodejs веб-фреймворк. Это как NestJS, если представить что NestJS не срисовывали с типичного Java. Из коробки есть практически все, что нужно при разработке серверов.

depcheck - библиотека, которая находит установленные, но неиспользуемые npm пакеты в приложении. Используемые, но неустановленные тоже находит

Sentry в своем блоге опубликовали статью о миграции кода проекта на Typescript. Если коротко то: - На ежегодной внутренней конфе или хакатоне в 2019 году ребята предложили, что пора бы на Typescript писать. Все с этим оказались согласны (без сюрпризов) - Надо было перевести на TS 1100 файлов и 95к строчек кода - Переводили по-немногу - Новые файлы только на Typescript - Старые файлы по мере задевания переводятся на Typescript - И вот в 2к21 все файлы типизированы В статье также описаны некоторые подводные камни перевода. Интересны также отголоски культуры внутри Sentry - внутренняя конфа, комитет архитектуры, отслеживание прогресса. Из странной вещи - ребята зачем-то запретили любые крупные рефакторинги и улучшения пока весь код не перепишут на TS. Относительно самого процесса миграции - все очень абстрактно. Вот просто переписывали по-немножку файлы.

Новая версия техрадара от ThoughtWorks. В этот раз добаили Code Review и он в Hold. Ну и много чего еще

Хороший короткий доклад на тему, почему Скрам - не очень. Хотя некоторые тезисы весьма спекулятивные, в целом по делу.

Описание Switch(true) паттерна - альтернатива куче if-else

Разбор современных сборщиков, которые предоставляют более удобный DX и работают немного по другому принципу, нежели webpack. Отличный разбор esbuild, snowpack, vite, wmr

Статья от команды storybook про то, как тестировать компоненты. Мы можем тестировать UI с помощью: - Скриншот-тесты историй storybook - Интерактивные (проверяем что клик по кнопке действительно что-то делает) - Доступность - Пользовательские сценарии Для разных видов тестов нам нужны разные инструменты и у них разная стоимость и ценность. Т.к. статья в блоге сторибука, то неудивительно, что самыми ценными оказались тесты с помощью storybook + chromatic. При этом скриншот-тесты поделены на 2 вида. Получается будто достаточно взять storybook и получить самые полезные тесты из коробки. Если отбросить эту маркетинговую чушь - то классификация и характеристики тестов неплохие, хотя статья весьма поверхностная.

React hook for form validation without the hassle

Тулза, которая позволяет добавлять кастомные проверки в пул/мердж-реквестам на JS. Она сама интегрируется с git системой, а в gitlab кажется вообще нативная поддержка. Пример использования в GitLab: - Вы ограничиваете количество строк кода в одном МР-е. Например, говорите что нельзя делать МР больше 600 строк кода в файлах с кодом. - Настраиваете job в пайплайне - danger.js пишет комментарий к МР-у и блокирует мердж, если правило нарушено Есть куча плагинов и примеров того, что можно реализовать с danger.js.