Development

На хабре вышла расшифровка доклада от VK с конференции Saint HighLoad++ про оптимизацию работы с сетью. У меня от статьи противоречивые чувства. С одной стороны, написано много интересного про сетевые протоколы (включая HTTP3 и QUIC), RTT, сжатие картинок. С другой стороны, похоже на мою дипломную работу в университете - вроде буквы написаны, вроде даже осмысленные, но непонятно зачем это все написано. Хотя кое-где моя дипломная работа выигрывает - в ней, по крайней мере, все оси графиков были подписаны Не смотря на то, что статья заканчивается "вот так вот мы ускорили VK на N%", в комментариях присутствуют справедливые упрёки от пользователей VK, что сайт как был медленным, так и остался. А некоторые тезисы из статьи критикуются с хорошими аргументами - например, касательно сравнения webp и jpeg. В любом случае рекомендую вам почитать статью, если вам интересно как работает сеть и сетевые протоколы.

Вышел выпуск подлодки про Peer Review с Филом Дельгядо. Code Review - это частная форма Peer Review. В выпуске же обсуждались разные варианты рецензирования кода и как и когда их следует применять. Если вы чувствуете, что с вами Code Review что-то не так - советую послушать

Статья от Евгения Карагодина про сложную судьбу модульной системы в Javascript на примере настройки абсолютных импортов в проекте. Очень занятное чтиво. Во время чтения ловил вьетнамские флешбеки от настройки других аспектов инфраструктуры в JS проектах.

Команда storybook недавно мигрировала 541 свой компонент из Styled Components в Emotion. Для проверки корректности миграции использовались скриншот-тесты на Chromatic (инструмент для скриншот-тестирования историй в storybook от команды storybook). Статья на 50% состоит из рекламы storybook и chromatic, на другие 50% - про подход и про изменения в коде. В целом больше интересен сам подход проверки изменения большого количества стилей. Юнит-тесты в виде скриншот-тестов помогли корректно отрефакторить код.

Текстовая расшифровка доклада Фила Дельгядо с TeamLeadConf про process smell. Достаточно абстрактная (никаких советов и ответов) статья про то, какие проблемы бывают в процессах, как они появляются и какие инструменты есть для исправления проблем

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

Или как ускорить разработку, удалив 80% кода. В статье рассказывается путь одной команды, которая старалась следовать хорошим практикам, но использовала их не к месту, из-за чего с кодом стало очень неудобно работать. В результате вместо ускорения разработки, она замедлилась В статье на примере сущностей и отношений между ними, показано как можно убрать ненужные абстракции, сократить количество файлов в 5 раз и упростить работу с кодом Рассмотренные в статье проблемы кода: - Ответственность распределена слишком мелкими порциями - Паттерны проектирования используются без получения реальной пользы - Преждевременная оптимизация перформанса - coupling уменьшается везде, где надо и где не надо В целом статья хорошая, но так как нет контекста проекта, то не следует воспринимать конкретные действия автора как рекомендации. Также в статье есть странные тезисы, например про противостояние vertical slice и onion architecture. Возможно это из-за формата статьи, возможно неточность в формулировках. Также перевод на хабре собрал много комментариев https://habr.com/ru/company/mvideo/blog/599401

Интересный список статей и глав из книг про экономику разработки

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

Еще одно видео от Максима Дорофеева про терпимость к неопределенности, тревожность и связь всего этого с планированием.

Видео от Максима Дорофеева про то, что делать с бесконечным бэклогом книг\статей\курсов. Также в этом видео применяется диаграмма разрешения конфликтов, про которую писал Голдратт в своей книги Цель-2.

Автор популярных пакетов faker.js и colors решил удалить эти пакеты из open-source в проекте faker.js была опубликована версия 6.6.6 в которой не работает ни один метод, а github-репозиторий проекта был отчищен через force-push в проекте colors опубликована версия 1.4.1, в которой используется бесконечный цикл с выводом в консоль. В обоих проектах на github в issue заведены issue от автора, в которых он выражает недовольство тем, что проекты очень популярные, но никто не готов поддержать его, как автора, деньгами. Достаточно интересный вышел перформанс.

Bulletproff-react - еще один гайдлайн по архитектуре react приложений. С одной стороны - ничего нового. С другой - гайдлайн неплохо описан

Opinionated список рекомендаций для проектов на React. Описаны рекомендации от написания кода компонентов, до тестирования кода и производительности приложения.

Enzyme - один из первых популярных инструментов для unit-тестирования React компонентов. Но сейчас он переживает не лучшие времена. Автор статьи сделал неофициальный адаптер enzyme для React 17. Он сделал его на время, пока мейнтейнеры enzyme сами не сделают свой адаптер, т.к. автору статьи адаптер нужен был уже сейчас. Но официального адаптера так и не появилось. Автор статьи предупреждает всех, что enzyme может не сделать официальную поддержку для React 18 т.к. для 17го так и не сделали, а для 18го React это сделать еще сложнее. Поэтому, если вы еще пишете enzyme тесты, вам следует уже начать писать новые тесты на testing-library и думать, как и когда переписывать существующие.

Storybook выпустили UI Testing Handbook - небольшой handbook по тестированию UI. Для тестирования UI предлагается: - Изолировать компонент в storybook - Делать скриншот-тесты в storybook - Делать тесты взаимодействие с компонентами с помощью jest и testing-library. Предлагается импортировать в код jest-тестов истории и тестировать именно эти компоненты. Звучит очень логично, но чтобы все заработало, нужно вызвать специальное API storybook в setupTests для jest. - Проверять доступностость с помощью Axe - Писать e2e-тесты с помощью Cypress В handbook есть подробные примеры кода тестов и настройки CI. Это неплохое, готовое руководство по тестированию UI. При чтении следует учитывать, что оно слишком привязано к storybook (что неудивительно т.к. это блог storybook), но все описанные принципы - верные

Framer Motion - достаточно известная библиотека для анимаций на React. Недавно вышла версия библиотеки для 3D анимации с React Three Fiber. Если вам интересны анимации или 3D в вебе - вам будет явно интересна эта либа.

tasuku - таск раннер на nodejs. Выглядит интересно

Статья про то, что нужно использовать milestones вместо проектов. Выглядит весьма спекулятивно. Впрочем, спекулятивность - фишка статей от agile коучей. Например, в одном из абзацев написано, что нельзя попасть в оценку при оценке проектов. Через пару абзацев уже пишется, что оказывается можно попадать с точностью в 97% если проекты небольшие. Не смотря не спекулятивность, в целом хорошая статья, которая сводится к следующим мыслям: - Люди плохо работают с большими проектами, но при этом люди стремятся планировать работу именно большими кусками. - Вместо этого следует: - Работать небольшими итерациями - На каждой итерации поставлять что-то готовое для пользователя - Декомпозировать большие проекты на маленькие вертикальные слайсы

Статья про переход Etsy на Typescript. У Etsy кодовая база организована монорепо с более чем 17000 JS файлов. При таком обьеме невозможно разом переехать на typescript и нужно думать об организации плавной миграции. Из интересных поинтов: - Делали сразу максимально строго и сразу максимально описывали типами, чтобы получить наибольший эффект от Typescript - Переезд был по-командным. Т.е. нельзя было просто взять и начать писать на Typescript. Сначала команда проходила обучение, затем ей разрешали переводить файлы на Typescript под присмотром менторов, а затем команда уже свободно писала Typescript - Организовали централизованное обучение. Даже пригласили автора книги Effective Typescript. - Столкнулись с проблемой производительности компилятора Typescript. Описали в статье, как воспользовались трасировщиком Typescript для нахождения проблемного типа, на котором компилятор "спотыкался" на 47 секунд. В целом рекомендую прочесть. Кроме самого переезда на typescript очень интересна организационная часть изменений.

Неплохой доклад от Дмитрия Коваленко про то, что тесты должны не просто быть, но и помогать. Описание доклада с ютуба: Все говорят про последователей TDD, но никто их в глаза не видел? Вот он — Дима! А что, если TDD — это совсем не про то, что тесты нужно писать до кода? Хотя формально именно про это. Но в этом докладе Дима расскажет про свой подход к написанию тестов в стиле TDD, который экономит ему время и не имеет ничего общего с юнит-тестами.

На хабре вышла статья от Miro про ускорение SPA приложения. В статье нет явного указания, что Miro оптимизировали свое приложение. А было бы интересно посмотреть, какие у них были проблемы и как они их решили и как это повлияло. Эта статья об оптимизации загрузки сайта в общем случае. В целом неплохая статья. Радует что очень подробно описано выделение контента, который нужен не сразу, в отдельные чанки

Asciinema - приложение для записи действий в терминале и плеер для их воспроизведения. Само приложение интересно с технической точки зрения и об этом можно почитать у них в документации. Но этот пост про обновление 3.0 - цель которого - улучшить перформанс. Стек изменился с clojurescript + react на rust + solid, что позволило ускорится в более чем 50 раз.

У вас есть команда из нескольких человек и нескольких проектов. Для того, чтобы выполнить проект, нужно, чтобы им занималась вся команда. Это создает сложность в коммуникации и координации. Как придти к консесусу о проекте, которым необходимо заниматься? В теории игр есть понятие - Schelling point. Это когда игроки, не коммуницируя друг с другом, способны выбрать одно решение потому что они считают, что другой игрок тоже его выберет. Например, есть 2 игрока и 4 квадрата - 3 синих и 1 красный. Если оба игрока выберут 1 квадрат независимо друг от друга - они выиграют. Из 4х квадратов - красный выделяется, и все предполагают что другой игрок выберет его. И так и происходит. Это и есть Schelling point - выбор единого решения исходя из того, что оба игрока подумают одинаково по каким-либо причинам. Вернемся к проблеме координации людей. В статье предлагается как раз использовать Schelling point для принятия общего решения. В статье описано несколько способов координации с наглядными гифками (реально крутые гифки - простые и понятные) и обьяснениями.

Вышла хорошая статья в блоге Мартина Фаулера про принятие архитектурных решений. Традиционно при построении архитектуры есть Архитектор или команда архитекторов, которые принимают решения об архитектуре. В этом случае команда архитекторов становится узким место процесса, вынуждена постоянно переключатся между контекстами и погружаться в каждый контекст, чтобы принять правильное решение. Альтернатива этому подходу: децентрализированный способ принятия решений об архитектуре. Что-то вроде анархии. Для этого нужно построить процесс, где архитекторы будут не принимать решения об архитектуре, а помогать разработчикам принимать эти решения. Для этого в статье предлагается применять 4 техники: - Архитектурный форум, где любой человек может принести свою проблему и получить совет - Легковесные ADR - Architecture Decision Record. ADR - это артефакт, описывающий какое-то архитектурное решение, его плюсы, минусы, альтернативы и последствия. - Командные архитектурные принципы. Это когда команда описывает, каким принципам должны соответствовать ее решения. - TechRadar. Это, по сути, список инструментов и подходов, которые применяет команда, и уровень их адоптации в команде. Хороший пример - techradar компании thoughtworks https://www.thoughtworks.com/radar

Открыли записи TeamLeadConf 2021

Очень часто при создании новой сущности в коде нужно описать определенное количество бойлерплейта. Для решения этой проблемы существуют генераторы файлов. Можно в том числе написать и свой генератор с нуля. В минимальном исполнении минимальный генератор можно написать на bash, скомбинировав команды cp для копирования шаблонов и sed для подстановки переменных в шаблоны. hygen - еще 1 генератор файлов на основе шаблонов. Но у него есть интересные фичи: - Работает на основе шаблонов в проекте. Т.е. чтобы завести новый шаблон, не нужно писать плагины или публиковать форк - Умеет создавать сразу директории, а не только файлы - Умеет не только создавать новые файлы, но и редактировать существующие - Можно писать логику в шаблон

Еще одна библиотека для JS, позволяющая легко выносить тяжелые вычисления в web-workers. Выглядит весьма удобно

Библиотека для создания тестовых данных с помощью фабрик.

Статья об ускорении Heybooster. Если коротко, то были применены следующие оптимизации: - Нахождение и удаление неиспользуемых npm-пакетов. Хотя они не использовались, они все равно влияли на итоговый размер ресурсов - Некоторые библиотеки весили непозволительно много. Один пример - библиотека для отрисовки графиков. На сайте в основном использовались 3 вида графиков и для каждого из них взяли отдельный, наиболее подходящий инструмент. Размер библиотек отличается на порядок. Например, для grid chart раньше требовалось загружать 4.9МБ JS, а теперь 78 КБ. Также разработчики нашли, что плагины для рендера markdown во vue весят очень много. Вместо плагинов они стали использовать marked.js напрямую. Размер библиотек также отличался на порядок. - Начали активно использовать миксины - Убрали все глобальные плагины, миксины, пакеты и компоненты из main.ts. Стали импортировать все в местах использования. - Отказались от EventBus в пользу vuex. - т.к. по флоу работы с сервисом пользователи вынуждены часто обновлять страницу с перезагрузкой данных, то оптимизировали стратегию кеширования и оптимизировали сборку webpack для эффективного кэширования