Development

Обычно я не тестирую. Но когда я тестирую, я тестирую на проде (с) Джейсон Стетхем Статья о том, что тестирование на проде является является важной практикой, если мы хотим достичь высокого качества создаваемой системы. Однако, в IT о тестировании на проде принято не говорить, либо говорить в негативном ключе. Почему важно тестировать на проде: - Прод - это единственное место, где ваше приложение работает в настоящих условиях - Тестирование на проде также означает и ответтсвенность разработчика за то, как приложение работает на проде - Как бы вы не старались ловить баги перед продом - у вас всег да будут баги на проде. Поэтому важно уметь работать с прод окружением и мониторингом Тестирование на проде не означает отказ от тестирования перед продом. По-хорошему, вы должны уметь тестировать и перед и на проде. Подробнее о причинах и бенефитах читайте в статье. Статья большая и с английским, который сложнее обычного в IT статьях (ну, мне так показалось).

Недавно в канале была статья про property-tests. Вышло продолжение этой статьи под названием "Когда не нужно писать property тесты" Если коротко: - Не нужно в тесте повторять реализацию тестируемого кода. Вместо этого следует выделять поведение кода. При этом не каждое поведение нам может быть полезно - от некоторых тестов можно отказаться - Если вы легко можете описать руками все возможные входные данные для функции, то лучше написать обычные тесты - Если property-тесты делаются слишком долго, то можно ими пожертвовать. Быстрый фидбек - одно из условий эффективных авто-тестов. - Иногда нам важны не сами тесты, а процесс проектирования через тесты (TDD). В этом случае мы можем в рамках написания кода тестировать его property-тестами, но затем удалить ненужные нам тесты, т.к. они нам помогли написать хороший код и больше не нужны Также указано, что применение property-tests требует изменения способа мышления и заставляет дополнительно подумать о том, как код может быть использован.

Какое-то время назад хабр начали переписывать с нуля на новом стеке - vue.js. Хабр стал типичным SPA приложением со всеми плюсами и минусами подхода. При этом, в идеале, пользователи не должны ощущать дискомфорта от перехода на новую версию сайта. Но, если вы часто сидели в последнее время на хабре, вероятно вы сталкивались с ситуацией, когда вы открываете статью с большим количеством комментариев (например 500), а страница рендерится ну ооооочень медленно. Хотя раньше таких проблем особо и не было. Новое SPA-приложение рендерило комментарии на клиенте неоправдано долго, что фрустрировало пользователей. Команда хабра вплотную занялась этой проблемой и в итоге у них получилось значительно ускорить пользовательский опыт при чтении комментариев. В статье подробно описываются шаги, которые предприняла команда хабра для ускорения отрисовки. Также приведены графики и замеры. Рекомендую к прочтению: реальный опыт ускорения сайта в виде статьи встречается не так часто.

"Нам нужно двигаться быстрее!" - лозунг, применяемый почти во всех IT-компаниях. Всех интересует скорость поставки. Чтобы бысть быстрее, команды должны работать спринтами и замерять велосити. Мы же Agile, а не какой-то waterfall! В статье описывается, что Agile - он не про скорость разработки, он про постоянное создание ценности для пользователя. Неважно, сколько задач сделала команда, важно сколько пользы она нанесла. В статье затрагиваются: - проблемы использования Story Point'ов - проблема расчета velocity по выполненной работе - оценки, принятие обязательств и дедлайны - это разные вещи - "управлять можно только тем, что можно измерить" - может быть вредной установкой - deliver better software, faster = deliver better software, sooner Но все это затрагивается весьма поверхностно

Rendition - Figma плагин, который экспортирует макеты в React компоненты. Выглядит интересно. Пример работы можно посмотреть здесь: https://youtu.be/3WucRJ7B6h0

Хороший пример, как писать кастомный хук для React с использованием TDD. Из минусов: как обычно в таких туториалах, пример очень простой. Но сложнее функции sum, что уже радует

Когда SPA-фреймворки только пришли, было нормой делать сайты без SSR вообще. В итоге пользователь видел белый экран, пока не загружался и не исполнялся весь JS, который уже все рендерил. Следующей итерацией было делать SSR и затем полный ререндер приложения в браузере. Т.е. грубо говоря, мы рендерим всю верстку на сервере, а затем рендерим ее же в браузере и заменяем первую на вторую. В идеале различий не должно быть, но мы тратим время на замену всего DOM-дерева приложения. Потом фреймворки научились переиспользовать тот DOM, который был отрендерен во время SSR. Этот процесс назвали гидрацией. Это уже намного лучше того, что было ранее. Но для полноценной работы сайта требуется загрузить весь JS и подождать, пока все приложение гидрируется. Только после этого инпуты и кнопки "оживали". В данной статье описывается следующий шаг - частичная гидрация. Это когда мы гидрируем только то, что реально нужно гидрировать сейчас. Например, нам важно быстро гидрировать то, что показывается пользователю на первом экране. А все что ниже - можно гидрировать по-позже. Также в статье, кроме описания самой техники, сравнивается, как различные фреймворки и библиотеки подходят к частичной гидрации

Вышел Remix v1 - фреймворк над React от создателей react-router. Уже есть огромная документация и очень хороший getting started гайд

Я, честно говоря, думал что playwright это как puppeteer, но поддерживает еще пару браузеров сверху. По покрайней мере в моей памяти, именно такая у них цель была на момент анонса и релиза первой версии - мы как puppeteer только поддерживаем другие браузеры. Но команда Checkly опубликовала гайд для миграции с Puppeteer на Playwright, а также рассказала, почему следует между Puppeteer и Playwright стоит выбрать именно Playwright. Если коротко, то в Playwright есть крутые фичи, которых нет в Puppeteer, а API, местами, намного удобнее.

Компания Tines столкнулась с значительным снижением скорости сборки при переезде на webpack5. Точнее, они выяснили, что скорость сборки замедлилась когда они добавили поддержку темной темы. Казалось бы, как может поддержка темной темы в CSS-in-JS замедлить сборку? Ребята проверил исследование с профайлингом и компилированием ноды и нашли интересный нюанс имлпементации Array.concat в V8, который может замедлить код.

Набор тулов для работы в терминале. Показано много разного и интересного.

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

Статья про использование подхода property-based-testing с помощью fast-check Разработчики в основном описывают авто-тесты вида вход = функция = выход. Это авто-тесты на основе примеров (example-based). Но можно писать другие авто-тесты - property-based. В таких авто-тестах мы должны выделить свойство (property) тестируемой системы. Свойство - это то, что всегда истинно, если все корректно работают. Можно сказать, что это какое-то правило, описывающее тестируемую систему. Если мы сможем описать какое-то свойство системы, то мы сможем использовать инструмент для property-based тестирования, который сгенерирует для нас сотни и тысячи тестовых сценариев и сам проверит, что свойство всегда истинно. Самый просто пример, который можно описать в рамках канала: ``` const sum = (a, b) = a + b ``` Мы могли бы описать свойство, что при сложении двух позитивных чисел результат всегда будет больше любого из чисел ``` const propertyToTest = fc.property(fc.nat(), fc.nat(), (a,b) = { const result = sum(a,b) expect(result a).toEqual(true) expect(result b).toEqual(true) } fc.assert(propertyToTest, {numRuns: 10000}); ``` И fast-check запустит для нас 10000 тестов с разными числами. Property-based testing достаточно мощная техника, но которую сложно применить. Относительное этой статьи видно, что автор срезает углы, описывая преимущество property-based testing и недостатки examples-based testing. Например, в недостатках example-based тестирования указывается то, что мы можем тратить циклы ЦПУ на тесты, которые нам не нужны. Хотя property-based testing предполагает запуск тысяч тестов т.к. ЦПУ дешевое и мы можем себе позволить проверять кейс тысячи раз. Также в статье приводится достаточно простой для применения property-based тестирования. Будем честны - никогда нет проблем протестировать чистые функции, реализация которых занимает пару строчек. В таком случае не особо важно, какой подход использовать. В остальном статья, как обычно у James Sinclair - классная. Если вас интересует тема автоматического тестирования и property-based тестирование - рекомендую к прочтению, но закройте глаза на сравнения с example-based тестированием.

Обычно предполагают что useEffect запустится после отрисовки. Но всегда ли это так? На самом деле это не всегда так. Например в случае, если был вызван useEffect, а потом был вызван useLayoutEffect, обновляющий стейт компонента. В этом случае react вызовет useEffect раньше отрисовки. Очень интересная статья про работу useEffect в разных условиях

Статья про то, почему выделенная команда для автотестов - антипаттерн, кроме одного сценария. Некоторые команды считают, что разработчики должны заниматься "важными" вещами - делать бизнес-фичи. Автоматизация тестирования это, конечно, важно, но не настолько. Поэтому есть такой паттерн - нанимать отдельных людей, задача которых автоматизировать тестирование за разработчиками. На практике это приводит к тому что: - Разработчики не задумываются о тестируемости кода = тестировать становится сложнее - Разработчики делают изменения, которые ломают авто-тесты, но разработчики не поддерживают авто-тесты. Принятие решения "это тест плохой или мы сломали что-то в продукте" требует большого количества времени - Фидбек от тестов очень долгий. Если у нас есть команда разработки и команда автоматизации тестирования, то, как правило, автотесты пишутся намного позже кода. В итоге эти автотесты дают фидбек о том, что что-то не работает слишком поздно. Возможно даже после релиза. Кажется, что иметь какие-то автотесты лучше, чем никаких. Но на практике это не всегда так. Например, лучше не иметь тестов вообще, если тесты - flaky, а тестовый прогон занимает 1 час. Но лучше все таки поменять процесс так, чтобы те, кто пишут код, писали на него и авто-тесты. Это хорошо, потому что: - Это упростит и написание тестов т.к. разработчик уже в контексте фичи и ему не нужно переключать контекст для написания авто-тестов - Система будет тестируемой - Фидбек от тестов будет раньше Я бы к мыслям автора добавил, что и сам код авто-тестов будет лучше т.к. разработчики, имея руки, растущие из правильного места, могут применить принципы DRY, SOLID и другие хорошие практики к авто-тестам. Автор также делает 1 исключение, в котором выделенная команда автоматического тестирования имеет смысл - это end-2-end тесты. end-2-end тесты могут быть не привязаны к конкретной команде т.к. проверяют все разом (грубо говоря, от верстки до БД), а также могут требовать отдельных компетенций.

При написании историй в storybook иногда хочется сделать историю, в которой уже будет произведено какое-то действие пользователя - по клику открыта модалка, или навешан hover на какой-то элемент. В текущих реалиях для достижения результата нам нужно либо инструментировать код (например, добавлять проп forseOpened), либо пробовать поиграться с диспатчем кастомного события, либо вынести поведения из компонента наружу, а компоненту передавать уже готовое состояние. Новая бета storybook решает эту проблему с помощью введения поля play у историй. В нем storybook позволяет описать действия, которые нужно совершить при заходе на историю. При этом storybook также предоставляет свой testing-library, с помощью которого делать эти действия очень просто. Простой пример использования новой возможности: ``` export const OpenDialog = () = DeleteCustomerDialog /; OpenDialog.play = async ({ canvasElement }) = { const canvas = within(canvasElement); await fireEvent.click( canvas.getByRole('button', { name: 'Delete Customer' }) ); }; ``` Также в примерах кода используется msw для мокирования сети

В Agile мире есть контр-интуитивный тезис: для того, чтобы доставлять фичи быстрее, нужно делать меньше. Но когда мы начинаем реализовывать этот тезис через снижение WIP-лимитов, совместную работу и другие техники, то как-будто встречаем сопротивление. Правда в том, что нельзя просто так, по щелчку пальцев, поменять систему, в которой участвуют люди. Возможно вы сталкивались с тем, что люди соглашаются, что парно программировать и писать приемочные авто-тесты - это "полезно и важно". Но на самом деле люди чувствуют, что это их отвлекает от "по-настоящему важной работы" - писать код. Таких нюансов может быть много. Поэтому слишком активное и прямое внедрение новых техник обречено на сильное сопротивление и обратный ожидаемому эффект. Следовательно, при внедрении техник, нужно учитывать эти нюансы и продумать, как внедрять эти техники наиболее естественным способом. В статье также есть полезные видео про WIP-лимиты и другие полезные мысли. Рекомендую прочитать, если вас интересуют процессы и все с ними связанное.

В preview версии Google Chrome появилась возможность записывать действия на сайте в сценарий, который затем можно редактировать, повторять и экспортировать как puppeteer скрипт. В devtools появилась новая вкладка Recorder, в которой можно начать запись и сделать нужные действия на сайте. После остановки записи, сценарий можно запускать, в том числе настраивая тротлинг сети и процессора. Сценарии также можно редактировать: добавлять новые шаги или изменять существующие. И как вишенка на торте - сценарии можно экспортировать как puppeteer скрипт. Это можно использовать как инструмент автоматизации рутины, как способ сгенерировать код автотеста, если у вас puppeteer, или как шаги для воспроизведения бага

В некоторых языках программирования можно обьявить, какие исключения выкидывает метод или функция. Но в TS нет таких возможностей. Максимум, что у нас есть - это мы можем обьявить в блоке catch ошибку как unknown. Система проверки типов в TS как будто бы просто игнорирует существование throw и catch, не давая при их использовании сильно больших гарантий на уровне типов. Но мы можем использовать монаду Either, которая позволяет декларативно описать тип результата успешного и неудачного выполнения фнукции. Подробнее про то, как это выглядит с хорошими примерами кода - в статье.

Текстовая расшифровка доклада Дмитрия Карловского (более известный как автор $mol) про реактивность в общем и реализацию реактивности в JS-библиотеках в частности. Как всегда от Дмитрия, много полезной теории, всесторонний анализ вопроса и, конечно же, $mol на первом месте

Ситник и artalar (автор ReatomJS) в твиттере рассказали о положительном опыте использования тест-раннера uvu. Поигрался локально - действительно быстро работает Из плюсов: - быстрый - простое API - нет глобальных переменных (describe, it, test). Все нужно импортировать явно. Как следствие, тесты можно запускать просто как `node test.ts` и это будет работать Из минусов: - Пока, например, нет возможности указать кастомный репортер для тестов. Так что, если вам нужна какая-нибудь интеграция или выгрузка результатов из CI куда-нибудь, то раннер может не подойти.

Компания Rakuten поделилась своими ощущениями от 2х лет использования Elm в продакшне. Если коротко, то ребята довольны Elm. - Функционыйльный ЯП - Гарантия отсутствия ошибок в рантайме - Компилятор хорошо оптимизирует код и быстро компилирует. В статье приводится цифра 2.5 секунды для компиляции 60к строк кода. - Великолепный вывод ошибок при компиляции. Компилятор описывает, почему это плохо и как это исправить. Как минимум советую посмотреть статью только хотя бы ради этого пункта - Elm, кроме синтаксиса, предлагает архитектуру - Имеет встроенный линтер При этом Rakuten обозначает явный минусы выбора Elm: - Сложности с наймом - Перейти на ФП не так-то просто - Приходится переизобретать то, что в JS экосистеме уже давно есть - Иногда необходим интероп с JS - Малое количество доступных ресурсов по Elm В целом, вдохновляющая статья про Elm.

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

Захватывающая статья про нестандартное использование useRef в react. Статья начинается с того, что каждый раз писать ref.current - это не нормально, это лишний шум. Поэтому автор приводит несколько примеров, как использовать useRef, но не писать .current А дальше автор уходит в исследование возможностей useRef для нестандартного использования. Например, для создания компонентов со своим независимым скоупом. Рекомендую к прочтению, если вам интересны продвинутые и нестандартные техники использования react

Статья про микрофронтенды и борьбу за обратносовместимые изменения. Микрофронтенды позволяют нам независимо разрабатывать и деплоить разные части приложения. Но если 1 из частей приложения ломает контракт - то может произойти каскад ошибок - часть А ломает контракт, от этого падает часть Б, которая зависит от А, а дальше падает В, зависящая от Б. Автор перебирает разные решения но в итоге приходит к anit-corruption layer. Суть идеи, как я понял, явно выделять фасад модулей для удобного применения и следить за тем, чтобы он был обратносовместим. В npm пакетах эту роль обычно выполняет index.js - вы можете сделать сколько угодно сложную структуру в npm пакете, но index.js должен быть удобным и обратносовместимым. Также в статье много примеров использования module federation

Reveal.js - движок для презентаций на html+js. Reveal-md позволяет описывать слайды в markdown и затем переводить их в reveal.js. Если вы хотите делать презентации, но вы не хотите делать их в каком-то GUI, а просто хотели бы описать все текстом и чтобы оно потом само - рекомендую обратить внимание на reveal-md

Обфускатор JS кода, кототорый легко интегрировать в процесс сборки.

6 Советов по улучшение Code Review: - Опишите изменения, которые приносит этот ПР и зачем он их делает - Если у вас изменения визуала - приложите скриншоты - Расскажите о требованиях к задаче - Не пишите сложный код - Расскажите, как ревьюить ваш код Статья достаточно короткая и почему-то привязана к React, хотя сами советы применимы к Code Review любой задачи.

Репозитории, который содержит описание и реализацию на JS более 100 алгоритмов. Описания, кроме текста, содержат красивые диаграммы и анимации, упрощающие понимание материала

Вовлеченные работники производят больше ценности для бизнеса, а их пользователи счастливее. Вовлеченность - важный аспект для успешных команд. Однако, по результата исследований, в среднем в IT очень низкая вовлеченность. Многие компании просто игнорируют вовлеченность сотрудников как аспект успешности компании. В основном, компании оптимизирует техническую часть систему, забывая про социальную. В первой половине 20-го века Великобритания начала процесс национализации уголе-добывающих шахт. Процесс добычи угля был построен так, что были бригады рабочих, которые сами решали как и что делать и их заработная плата зависела от результата работы всей группы. По сути, они были самоорганизующимися командами, которые сами принимали решение о том, что делать, кто лидер, нужны ли еще люди в команду. При национализации "люди сверху" решили, что надо поменять процесс добычи угля и разделили процесс на 3 этапа и разделили команды на 3 области. Это сильно ухудшило добычу угля и привело к забастовкам. Проблема в том, что при реорганизации добычи угля учитывалась только техническая сторона вопроса. Если мы хотим построить эффективную систему, нам нужно строить социо-техническую систему, т.е. учитывать и социальный фактор и технический. В следующей реорганизации работы шахт уже учитывался социальный аспект системы. Далее статья описывает интересные факты о вовлеченности, командах и социально-технических системах. И при этом есть ссылки на другие практики и книги (DDD, Team Topologies). Если вам интересен managment и agile - статью можно прочитать. Если вы - кодер, то скорее всего статья покажется вам философскими рассуждениями и полной воды. PS: В статье есть интересные илюстрации. Например, самооранизующиеся команды на фоне космоса.