Development

Первая статья из обещаемой серии статей про создание клона Heroes 3 на JS. Статья достаточно короткая, но содержит интересные технические решения и ограничения т.к. задача реверс-инжиниринга игры и переписывания её на JS - сложная инженерная задача.

Хороший обзор нового встроенного в nodejs test runner'а. В обзора сравниванются функциональные возможности ранера по сравнению с существующими. В целом, node:test выглядит достаточно неплохо: - Есть watch режим - Можно приладить кастомные репортеры, которые умеют обрабатывать Tap репорт - Есть базовые асерты, но вывод ошибок в консоль неудобен. Ошибка есть, но где именно разница - непонятно. - Есть возможность распаралеллить тесты в рамках 1го файла. - Есть функционал для мокирования. Как функций так и целых модулей - Есть возможность указать отдельный лоадер для запуска, например, ts файлов - Немного странное решение с выполнением определенных тестов через `only` - по умолчанию раннер игнорирует эту опцию и учитывает её только с определенным флагом. Это расходится с уже устоявшимся паттерном "если в файле есть only - то только они и запускаются, на прекомите запрещаем комитить only" - Есть сбор code coveraage В общем, выглядит достаточно неплохо и не требует установки кучи пакетов, что уже плюс.

Вышел Storybook 7. - Обновленный дизайн - Zero-config поддержка Vite, NextJS, SvelteKit - Новый формат (опять) для описания историй. Теперь типобезопасный - Плагин Docs поддерживает MDX2. В статье пишется что это самое крупное изменение в SB7. Появился тэг autodoc для автоматической генерации документации, больше возможностей для ручной документации (и теперь она быстрее компилируется) - Добавлен сбор code coverage при использовании историй сторибука как тестов (насколько помню предполагается использование jest + playwright) - Поддержка pnpm и rspack.

Забавная игра на знание работы сравнения в JS. В игре нужно расставить флаги, какие сравнения будут `true` при применении `==`

Статья в блоге Мартина Фаулера про использование ChatGPT для программирования. Достаточно короткая заметка, в рамках которой рассматривается 1 из вариантов использования chatGPT для создания кода. Первым вводом в ChatGPT дается контекст: что делаем, тех стек, архитектура, ограничения. При этом явно указывается что пока что код не нужен. Также запрашивается верхнеуровневое решение. В каждом следующем вводе идет просьба имплементировать какой-то определенный кусок решения. Выглядит как рабочая схема. Многие к похожей схеме приходят сами.

Доклад от Allen Holub про вред оценок и почему подход no estimates - это единственный работающий процесс оценки работ. Что плохого в оценках? Люди плохо справляются с оцениваем работы. В большинстве случаев люди ошибаются в оценке, причем не в оптимистичную сторону. Также. оценку как правило получают, когда полный объем работ неизвестен. Скорее всего в момент оценивания известен результат (мы хотим чтобы пользователь мог сделать Х), но не известен объем работ. В итоге человек дает неверную оценку для непонятного объема работ, который затем менеджмент воспринимает как обязательство и ставит deadline. А затем, чтобы успеть к дедлайну, все вокруг срезают углы (тут отрежем от безопасности, тут от тестируемости, тут от ценности). Это очень популярная процессная дисфункция - сначала спрашивать оценки, хотя они будут неверны, а затем воспринимать их как обязательство. При этом, согласно исследованиям, только 20% проектов оцениваются более менее точно, что делает превращение оценок в сроки еще более плохим методом работы. Многие называют непопадание 80%: проектов в срок - кризисом разработки. Но на самом деле, кризис не в том, что проекты не попадают в срок, а в том, что компании вместо фокуса на правильных фичах, которые будут кормить их годами, фокусируются на доставке в срок неправильных фичей (фича нас немного прокормит, но только если мы уложимся в бюджет) Во многих проектах также есть большой беклог. Как правило, верхушка беклога - это очень важные вещи, дальше идут в целом хорошие фичи, а где-то начиная с середины - то что вообще не надо делать. Следующая дисфункция - это оценивание задач из беклога. Для задач 3го типа оценка - это лишняя работа т.к. задачи не будут сделаны. А иногда компании еще занимаются переоценкой всего беклога, если там что-то изменилось, увеличивая лишнюю работу кратно. Если вспомнить историю классического производства, то там все начиналось с того, что процесс производства разделялся на примитивные работы, каждая из которых затем замерялась. Т.е. был прям отдельный человек с таймером, который замерял, кто на что тратит сколько времени и затем как-то принимали решение об оптимизации. Это в целом тоже плохо работало, поэтому на производстве Тойота этот таймер передали самим работникам. Т.е. теперь работники решали, как они работают и как им лучше это делать (возможно это метафора, я не понял, если честно). Это одна из вещей, которые сделали Тойота эталоном производственных процессов. Вот то же самое и с разработкой. Вместо того, чтобы тратить время на оценивание работы, разработчики сами разберутся как делать оптимально. Заказчик же должен сфокусироваться на том, чтобы выбрать правильные и приоритетные фичи. Как же все таки планировать работу? Тут Allen Holub приводит примеры от автора NoEstimates подхода. Он взял статистику по работе какой-то команды и построил Cummulative-Flow диаграмму. Она показывает отношение несделанной работы к сделанной в момент времени. Условно, на первой неделе у нас было сделано задач на 10 SP (стори-поинты), осталось 70 SP, а на второй мы сделали еще 8 и получилось 18SP, а в беклог добавили задач еще на 2 SP, итого осталось 64SP. Построив такую диаграмму мы можем интерполировать её и получить примерную дату, когда мы все завершим. Автор NoEstimates нашел интересную закономерность. Если оценивать одни и те же задачи в SP по шкале 1-3-5, по шкале 1-2-3 и считать все задачи за 1, то прогноз отличается не более чем на 10%. Но разница между временем оценки огромна - для оценки в SP нужно потратить много времени, для оценки задач в штуках достаточно 1 человека и уметь считать Краткий итог: - Оценка задач и превращение оценок в сроки - это дисфункция - Задача заказчика - определить самую приоритетную работу и задекомпозировать её на мелкие куски, задача разработчика - эффективно выполнять работу - Для того чтобы оценить работу, достаточно уметь считать в штуках Рекомендую к просмотру тем, кто интересуется процессами.

Обычно, при планировании итерации, мы пытаемся забить команду работой под завязку. Например, высчитываем velocity из трех последних итераций и понимаем, что команда в среднем делала Х работы. Давайте запланируем на следующую итерацию Х работы. Получается даже не с потолка, а основываясь на данных. Проблема этого подхода в том, что у команды не остается буфера для внезапных задач, рефакторингов, налаживания процессов. Вместо этого предлагается ввести Slack (наверное корректный перевод будет зазор, но я не уверен). Т.е. планировать заведомо меньше, чем обычно делает команда. Например, команда на протяжении последних N итераций делала 30 работы, но минимальное значение было 20 - давайте планировать итерации на 20, а все остальное - это зазор. Это открывает следующие возможности: - Команда точно сделает то, на что закомитилась - Появляется время для срочной работы - Появляется время для улучшения процессов, рефакторинга, обмена знаниями, улучшения скорости работы - Команда при этом не сидит сложа руки, если основные задачи сделаны, она просто берет следующие.

Microsoft Teams оказывается совершили миграцию своего веб-приложения на новых технологический стек. Было: electronjs+angularjs+html/css. Стало: Webview2+react+webworker+fluentUI. Для начала было проверено, что новый подход можно встроить в старое приложение и это будет работоспособным. Затем начали реализовывать отдельный клиент для некоммерческих пользователей т.к. так меньше фич и можно раньше начать получать обратную связь. Из интересных архитектурных решений новой архитектуры - вынос слоя работы с данными в веб-воркер. В этот слой входит: работа с данными, их загрузка, пуши и оффлайн-функционал. Это позволяет не блокировать UI-тред сложными вычислениями. Основной тред получает данные с помощью GraphQL (возможно неточно понял, но точно используется GraphQL схема для доступа к данным). Это позволило получить более хороший перформанс приложения и явное разделение слоев логики. Webview2 - это, как я понял, альтернатива Electron от MS Edge. Этот переезд позволил сократить потребление памяти, а также дает доступ к некоторым крутым фичам. Также в рамках миграции получилось улучшить пайплайн рендера видео. За последние годы созвоны стали неотъемлемой частью удаленной работы, поэтому особо важно реализовать эту часть работы приложения эффективно. В новом приложении получилось сократить потребление энергии в 2 раза и улучшить эффективность в целом. Это позволило поддержать такие популярные лэйауты как 7х7 и динамические представления (вспоминаем тезис из недавней статьи, что любая оптимизация не приводит к сбережению ресурсов, а только лишь открывает новые возможности). Что еще сделано: - Поддержка больших встреч (тысячи участников) - Поддержка работы в нескольких аккаунтах - Улучшение безопасности - Улучшение доступности Также в статье есть также архитектурная схема нового приложения.

Статья объясняет, почему useEffect может быть исполнен до отрисовки. Обычно ожидается, что useEffect будет исполнен уже после отрисовки компонента в браузере. React гарантирует, что useEffect будет исполнен до следующего рендера. Однако следующий рендер может произойти раньше. Например, в случае, если ререндер инициирует `useLayoutEffect` установкой пропсов. В этом случае, useEffect будет исполнен перед повторым ререндером и отрисовкой компонента. Это же может произойти, если обновлять state во время других операций, например во время `requestAnimationFrame`. Что же делать? Можно попробовать запретить менять стейт в `useLayoutEffect`, но это а) сложно и мы можем не контролировать код в определенных кейсах (например, компонент из какого-нибудь ui-kit'а может вызывать ререндер) б) все равно не гарантирует что стейт не обновится как-нибудь еще Скорее всего вы пытаетесь изменить стейт для того, чтобы как-то повлиять на DOM-элемент. Если так, то можно вручную манипулировать DOM-элементами через ref'ы, нежели работать со стейтом.

Ускорение Tanstack Table в 1000 раз одной строчкой кода! Автор использует Tanstack Table в своем приложении с большими таблицами и заметил, что приложение подвисает на 30-40 секунд, если включить группировку колонок в таблице. Он пошел разбираться, используя старый дедовский метод выводя тайминг в console, почему так лагает. В процессе поиска он постоянно натыкался на места, которые казались ему медленными. "Ага, тут рекурсивный цикл, это точно он!" (нет). "Ага, это reduce вместо обычного цикла!" (нет). В итоге выяснил, что для трех сгруппированных колонок вызывается метод `groupBy`, каждый из которых отрабатывает по 10 секунд. Оказалось, что группировка лагала из-за использования оператора spread `map.set(resKey, [...previous, row])`. Этот оператор используется в reduce для добавления элемента к массиву в одном из значений `Map`. Оператор spread создает новый массив. Поэтому, например, если в результирующем массив будет 1000 элементов, будет создано 1000 массивов. В данном коде не нужна была иммутабельность, поэтому 1 строчное изменение spread оператора на push (`previous.push(row)`) ускорило код в 1000 раз (10 секунд = 10 ms).

React Labs написали пост про разработку React, где рассказали про будущие фичи React. Статья начинается с описания новшеств в серверных React компонентах. После обсуждения концепции с сообществом были изменены некоторые вещи. Во первых, договорились обозначать компоненты для рендера в браузере через директиву "use client" в начале файла. Во вторых, приняли решение об использовании `async/await` как основной способ для загрузки данных в серверных компонентах. Также планируют добавить новый хук `use` (без суффикса) для разворачивания Promise. Как я понял, команда разработки React хочет сделать так, чтобы разработчики просто писали нужные запросы (в API, в БД) на серверных компонентах, а фреймворк сам бы разобрался как доставить эти данные на клиент. Таким образом разработчик не думает о том, как создавать и поддерживать API, фреймворк организует передачу данных за него. Кажется, мы уже видели это лет 10 назад например в MVC-фреймворке (если не ошибаюсь). Что ж, история идет по спирали. Далее следует речь об улучшении Suspense. Suspense позволяет разработчикам описать состояние компонента, пока он ожидает загрузки данных. Но кроме загрузки данных на компонент может влиять загрузка шрифтов, стилей и тд. Вот команда React работает над тем, чтобы Suspense учитывал загрузку ассетов. При этом обещают, что разработчикам не понадобится что-то менять в своих компонентах для того, чтобы новое (будущее) поведение заработало. Звучит как угроза. Также команда React обратила внимание на проблему определения мета-полей страницы. Title вкладки, OG-теги и вот это вот всё. Планируется, что react будет корректно обрабатывать мета-теги в коде и сам заберет на себя всю сложность корректного выставления тегов. Следующая магическая часть поста - про компилятор React компонентов. Команда давно работает над компилятором React Forget, который бы забирал на себя часть оптимизаций React. На текущий момент, как я понял, ребята экспериментируют со своим компилятором, чтобы он оптимизировал "сложные" случаи, когда компонент может ререндерится - например, структурно идентичные, но различные по ссылке объекты (т.е. по сути приходят одни и те же данные, но разными объектами, что сейчас заставляет компонент ререндерится). Для этого они реализовали свой компилятор из AST в AST, совместимый (или встраиваемый) с babel. Еще 1 щепотка магии в котёл React. Следующая будущая фича - Offscreen Rendering. Она позволяет пререндерить компоненты или экраны, не влияя на перформанс приложения. Предполагается, что разработчикам не нужно будет самим размечать свои компоненты и экраны для этой фичи, вместо них эту работу должны взять на себя фреймворки и либы (например роутеры). В общем, команда React в своем стиле делает фичи, которые должны изменить само понимание UI-разработки. Я все еще придерживаюсь мнения, что поставки вдохновения из Колумбии для команды пока еще не перекрыли.

Очень странный заголовок для очень крутой статьи. Если коротко, человек захотел слушать Яндекс.Музыку прямо в vscode, чтобы можно было переключить трек, не отрываясь от кода. Статья очень подробно разбирает как реверс-инженерить чужие API (у яндекса нет документации), как создавать расширения в vscode и как запускать электрон в электроне для запуска audio (предварительно, разобрав исходники расширения LiveShare, в котором, внезапно, есть упоминание Skype)

Обзор популярных пакетов для nodejs cli приложений. Рассматривается, а что вообще есть популярного для cli приложений, как это разрабатывается и поддерживается и какие есть характеристики. Это очень поверхностный обзор, но он может быть интересен.

Статья, рассказывающая о развитии React от "либка для рендера" до "архитектура приложения". Почему вообще React стал успешен? Прежде всего, потому что он предложил компонентный подход. Не то, чтобы это была придумка React, но react построен на этой идее и разработчикам необходимо ей следовать. Компонентный подход убил сразу двух зайцев. Это позволило разработчикам разрабатывать компоненты независимо друг от друга, интегрируясь по необходимости. Также React упростил техническую реализацию - просто пиши компоненты, а React сам разберется чтобы это все работало и было быстрым. В целом все шло неплохо, но код приложений со временем, как правило, не уменьшается, а только становится больше. Это значит, что с каждой новой фичей пользователям нужно грузить больше кода в браузер и дольше ждать отрисовки. Для решения этой проблемы на сцену вышел SSR. Это позволило улучшить опыт пользователя, но усложнило поддержку приложений (раньше просто заливали статику, теперь надо вращать кубы, следить за nodejs). При этом, SSR не убрал проблему (слишком много кода), а просто засунул её под ковёр. Теперь мы рендерим большой кусок верстки на сервере и затем рендерим большой кусок верстки на клиенте. Чтобы это немного оптимизировать, React научился в потоковый рендер, позволяя отправлять пользователю те части конента, которые уже готовы. Следующая проблема - это загрузка данных. Как правило, приложения на React - это не просто вёрстка, это еще и данные, которые необходимо обрабатывать. Необходимо придумать оптимальный способ понимания, каким компонентам какие данные нужны, при этом загрузив их наиболее оптимальным способом. Тут на сцену выходит GraphQL и похожие технологии, которые оптимизируют работу с внешними данными, но добавляют ещё сложности в разработку. Следующий шаг - увеличить модульность приложения. React форсит компонентный подход, но когда мы рассматриваем всё приложение, как единое целое, его становится сложно оптимизировать. Поэтому появились разные варианты модульности: вложенный роутинг, микрофронтенды и тд и тп. Это позволяет каждому модулю работать независимо, а значит, например, можно распараллелить рендер и загрузку данных и обработку ошибок. И вот все это развитие делается сообществом вокруг React, создавая неконсистентность в подходах, а также накручивая оптимизации сверху, вместо реализации оптимизаций в ядре. Серверные React компоненты как раз призваны исправить этот недочет. React, как фреймворк, вводит серверные компоненты для улучшения опыта пользователя (за счет технических оптимизаций) и разработчика (за счет скрытия технических сложностей)

Статья про миграцию с ts-node на Bun. Автор использует ts-node для создания простых консольных утилиток. В рамках статьи, он переводил утилиты для своего блога. На bun переводится очень простой проект. И его миграция достаточно простая. Единственный важный нюанс, с которым столкнулся автор во время переезда - bun не ждет завершения промисов приложения. У cli-утилки была асинхронная функция main, которая не await'илась. Nodejs не завершает процесс пока не выполнится промис, а bun завершает процесс т.к. исполняемый файл закончился. Это не то поведение, которое ожидается, но в данном случае оно легко фиксится добавлением await'а. Как итог, скрипт стал работать в 2 раза быстрее.

Разные инструменты с ИИ наделали много шума. ИЗ каждого утюга можно услышать что скоро будут не нужны маркетологи, копирайтеры, медики, юристы, художники и разработчики. В статье автор рассказывает, что угрозы для фронтенд-разработчиков нет, а ИИ инструменты станут отличным дополнением к ежедневной работе и повысят эффективность разработки. Автор давно занимается веб разработкой и не в первый раз встречается с тезисом "Инструмент Х лишит веб-разработчиков работы". Сначала (в 1996 году между прочим) это были GUI решения, которые позволяли сделать веб-сайт просто перетаскивая элементы. Затем появился wordpress, затем webflow, затем "no code" инструменты. Теперь вот ИИ-инструменты. Инструменты в прошлом не сделали разработчиков ненужными, просто теперь, чтобы запустить сайт парикмахерской, не нужно нанимать отдельного разработчика - достаточно найти веб сервис который за небольшую плату позволит сделать сайт по шаблону. А разработчики занимаются созданием сложных или узких решений. Текущие возможности ИИ преувеличены. Да, они действительно могут написать несколько сотен строчек кода, но в реальных приложениях нам нужно писать тысячи строчек кода, думать о декомпозиции, тестировании, НФТ. ИИ станет отличным инструментом в помощь разработчику и писать код станет легче. Как следствие, у нас появится больше времени для важных и крутых фич, уделяя меньше времени рутинным задачам. Кроме веб разработчиков, в статье приводится мнение юристов (ИИ смог пройти тест, который необходим для получения лицензии юриста) и аниматора из disney. Они в целом того же мнения - ИИ значительно упростит рутинную работу, но не заменит человека в профессии. Выше был пересказ мнения автора, с которым я согласен. Но я также могу вспомнить, что есть какой-то эффект или закон, который гласит, что если что-то будет оптимизировано, то это не снизит издержки - просто оптимизированное начнут использовать больше, чем раньше. Хороший бытовой пример - появление энергосберегающих лампочек. Появились лампочки с потреблением в 8-10 раз меньше, чем лампы накаливания. Теперь там, где раньше людям для жизни хватало одной лампочки, ставят сразу кучу лампочек, и даже появились рекомендации от дизайнеров интерьеров который звучит примерно так: "каждые Х квадратных метров потолка должен иметь хотя бы 1 источник света". Также не упущу возможность порекламировать Codefest 13. Приходите, я буду там рассказывать про то, как chatGPT помогает разработчику.

В последнем релизе Deno ввели поддержку package.json. Это очень удивительно, при том что Deno изначально отрицал идею файла package.json. Deno использует HTTP-импорты для импорт зависимостей. Это позволяет быстро разрабатывать, не думая о менеджмент зависимостей. Но из-за этого появляется проблема дублирования зависимостей, ведь разные части кода могут тянуть разные, но совместимые, версии зависимостей, или зависимости зависимостей могут делать то же самое. Поддержка package.json преследует сразу 2 цели: - Сделать управление зависимостями более эффективным - Сделать переход из nodejs более простым. В будущем deno введет deno-урлы (будет что-то типа `import lodash from 'deno:lodash'`), в котором зависимости будут тянуться из deno registry и проблема с дублированием зависимостей будет как-то решена.

Вышел новый релиз playwright, в котором добавлена возможность запускать playwright UI. В нем можно смотреть статус тестов, что происходит в тесте, что происходит в исходниках. Выглядит интересно

Продолжение серии статей про ускорение экосистемы JS. На этот раз выбор автора пал на то, как npm запускает скрипты (например через `npm run`). Оказывается, для того чтобы запустить скрипт npm тратит около 400мс. С одной стороны, не так уж много, с другой стороны, что там делать 400мс? Автор проводит несколько оптимизаций, которые уменьшают время запуска до 137мс. Но возможности оптимизаций ограничены временем на борьбу с архитектурой пакета npm. Если писать подобное решение с нуля, удалив все "лишнее", то можно уместиться в 22 мс. Что конкретно сделал автор. 1. Классическая проблема JS экосистемы - все `require` и `import` описываются в начале файла, что заставляет движок сразу подгружать код, хотя он может быть еще не нужен. В npm эта проблема так же повторяется - мы просто хотим запустить скрипт, но npm делает require разных утилок, которые, например, нужны для обработки ошибок. Простой перенос require в то место, где код действительно понадобится, позволяет ускорить работу основного скрипта. 2. Класс, который обрабатывает команды npm, является супер-классом и тянет в себя много функционала. Вы хотите просто запустить скрипт? Держите audit, dedupe, workspaces и другие крутые функции, которые вам сейчас не нужны. Вынос этого функционала дал 20мс 3. Еще 1 вещь, которая замедляет npm - это сортировка строк. Опять же, хороший вопрос, зачем нам там что-то сортировать, когда мы вызываем конкретный скрипт из package.json. Для сортировки используется `Intl. Collator`, это позволяет сортировать строки с учетом локали пользователя. Но там сортируется массив названий команд и с этим хорошо справляется обычный `.sort`. Таким образом выиграли еще 10 мс. К этому моменту время запуска сократилось до 200мс 4. Следующий найденный, но не исправленный момент - установка названия процесса. Чтобы процесс не назывался `npm` или `node`, npm ставит процессу корректное название, позволяющее легче с ним работать, например, при мониторинге работы процессов. Это очень полезная фича, но она занимает 10мс 5. Дальше было найдено, что функция glob также тратит много времени работы. npm управляет логами запуска скриптов и это очень полезная фича. Иронично, что она тратит много времени на сортировку массива из десятка элементов через `Inlt.Collator`. Замена на обычный `.sort()` сохранила еще 10 мс. К этому момент время запуска сократилось до 137мс (не спрашивайте "как?", я тоже не понял, но вот между 3 и 5 шагом есть всего 1 оптимизация на 10мс, но разница - 63мс. Возможно там 6 раз делалась сортировка, возможно автор делал что-то еще, что решил не отображать в статье) Дальше автор приходит к выводу, что для дальнейшего ускорения нужно заняться очень агрессивным удалением или комментированием кода. Поэтому он пишет с нуля свою минимальную имплементацию и получает 22мс.

В больших организация внутренняя культура - это ключевая составляющая успеха. Культура постоянно меняется - уходят и приходят люди, меняется контекст. Культура также может быть поражена "вирусом". Культурный вирус - это заразная идея, которая негативно влияет на культуру компании. Первый вирус это отсутствие ответственности. Это может выражаться несколькими способами. Например, конфликт при долгой разработке, когда разработчик считает, что требования плохие, требования постоянно меняются, кто-то шатает инфраструктуру, а заказчик считает, что разработчик медленно работает. В этом кейсе определенно есть проблема - фича долго разрабатывается. Но никто не хочет брать ответственность за проблему, все хотят ее спихнуть. Особенно удобно получается, когда можно спихнуть ответственность на того, кто уже не работает в компании. Другой пример - это когда у команд такая маленькая зона ответственности, что в случае проблемы как-будто бы никто и не виноват. Второй вирус это "типа выгорание" (не путать с настоящим выгоранием), погоня за ресурсами (мне нужны еще люди Х) и фатализм (мы пробовали и у нас не вышло, это не получится и тд). Казалось бы, это все про разное. Но эти проблемы объединяет один результат - люди, вместо того, чтобы делать задачу или решать проблему, говорят что они не могут это сделать. "У нас не получится это сделать, мы и так устали / работаем без выходных", "Мы не можем сделать этого пока не наймем еще 3х разработчиков" (вместо того чтобы реогранизовать задачу или работу по нему), "У нас просто не получится" Третий вирус это позитивная токсичность. Нет ничего плохого в том, чтобы двигаться дальше, не смотря на все проблемы. Даже более того, это определенно нужно в быстрорастущих стартапах, хотя это и выглядит как безумие. Однако, это может переродится в игнорирование проблем. А если проблемы игнорировать, то их импакт увеличивается со временем. Как бороться с вирусами? - Правильный выбор и обучение лидеров в организации поможет в борьбе с культурными вирусами и поможет держать "здоровье" культуры на хорошем уровне - Следите за тем, чтобы ваша культура была понятная сотрудникам. Вы все должны быть на одной волне. - Используйте культуру как мотиватор, а не как способ наказать кого-то (кто не следует культуре)

Заметки по исследованию влияния архитектурной сложности на разработку. В 2013 году один студент MIT решил проверить, есть ли корреляция между архитектурной сложностью и сложностью поддержки системы. Для определения архитектурной сложности был взята оценка McCabe. Она выделяет 4 класса сложности: низкая, средняя, большая, не тестируемо. Заметьте, что в определении есть прямая связь между нетестируемостью кода и его сложностью. Для определения сложности поддержки была взята статистика из гита, HR баз и внутренних трекинговых систем. К каким выводам пришел студент, делающий исследование. 1. В более сложных системах в 3 раза больше багов. 2. В сложной системе скорость работы разработчика в 2 раза ниже. 3. Сложность системы связана с шансом увольнения сотрудника. В статье есть график, который показывает зависимость увольнения от количество кода, влитого в Core функционал. В общем, если вам нужны какие-нибудь цифры, на которые можно ссылаться при обсуждении решения тех. долга, рефакторинга, обсуждения архитектуры - то вот они. PS: если по ссылке заметки по исследованию, то этот пост - заметки по заметкам по исследованию?

Пост в блоге Typescript про миграцию на typescript на модули. В релиз ноутсах к релизу 5.0 команда typescript уже рассказывала, что они порефакторили кодовую базу и смогли переехать на модули и получили от этого большой (10-20%) буст в перформансе. В этой статье подробно рассказывается, как конкретно производилась миграция Исторически так сложилось, что кодовая база Typescript писалась с использованием неймспейсов. Это привело к нескольким проблемам: - Невозможность использовать фичи, которые разрабатываются для пользователей. Инкрементальные билды, автоматическая организация импортов и другие. Это создает ситуацию, когда разработчики typescript не могут сами оценить преимущества и проблемы того, что они создают. - Из-за реализации неймспейсов (создание дополнительных оберток, скоупов) появляется замедление перформанса в рантайме. Т.к. кода написано много и проводить ручной рефакторинг из неймспейсов в модули параллельно разработке (а фризить разработку на недели или месяцы никто не будет) просто невозможно, команда автоматизировала большинство кейсов миграции. Текущий консенсус по созданию оптимизированных приложений состоит в том, чтобы использовать какой-нибудь бандлер, который умеет оптимизировать код. Поэтому разработчики typescript решили тоже бандлить свой проект. Они выбрали esbuild как за скорость и удобство, так и за умение инлайнить енамы прямо в код. Миграция прошла одним пул-реквестом на 282к строк кода. Этот ПР постоянно обновлялся новым кодом из мастера т.к. команда не хотела фризить разработку. Автоматизация миграции позволяла достаточно быстро обновлять ветку. Автоматические тесты давали уверенность в том, что все работает как надо. Поэтому в 1 момент мастер все таки зафризили и влили 1 большой ПР. Теперь TS написан на es модулях Что это дало: - итоговый размер пакета уменьшился почти в 2 раза - ускорение работы на 10-20% - современная кодовая база - пользователи могут работать с модулями, вместо неймспейсов, что намного удобнее - команда ТС пользуется своими же фичами для модулей Также в статье рассматривается кейс, когда переезд на современный код немного замедлил парсер. Дело в том, что до переезда на esbuild код собирался в ES5, и все let и const трансформировались в var. Теперь же код собирается в ES2018 и let и const остаются. Это привело к просадке скорости работы парсера на 5% т.к. JS-движку необходимо чекать в рантайме, была ли уже инициализирована переменная. Как решение - в особо чувствительных местах typescript'а используются var вместо let и const. Но вообще команда ожидает доработки в esbuild, чтобы он позволял компилировать let и const в var там, где это безопасно. А безопасность уже гарантируется typescript'ом.

Вышел Typesctipt 5.0. В канале уже был пост про релиз 5.0 beta и с тех пор значительных изменений нет. Но коротко перескажу, что нового в 5.0: - Изменения в синтаксисе декораторов. Теперь они совместимы со стандартом ES. - Возможность писать const типы, что убирает необходимость описывать as const во многих случаях, когда нам нужно подсказать тайпскрипту, что не надо обобщать тип - Возможность композировать tsconfig из нескольких конфигов. - Изменения в работе Enum. Каждый Enum это теперь union своих значений. - Миграция Typescript на сборку через esbuild позволила а) уменьшить вес пакета б) ускорить сборку и тайп-чек больших приложений на 10-20% В общем, можно переезжать.

Вышле новая документация по React. Красиво, с живыми плейграундуами прямо в доке, вроде есть новые гайды и объяснения. Обещанного 3 года ждут, а новую доку по React мы ждали 5 лет.

Существует принцип Питера: в иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности. Это означает, что человек поднимается по карьерной лестнице пока он становится совсем некомпетентным, из-за чего выше залезть уже не может. В реальной жизни вы, наверняка, сталкивались с ситуацией, когда на должность руководителя повышают самого крутого работника. О, Сергей крутой фронтендер, он делает такую крутую вёрстку. Давайте сделаем его тимлидом фронтендеров? Звучит просто превосходно! Однако потом оказывается, что Сергей может быть и крутой фронтендер, но вот управлять людьми он не умеет. Вот это желание повысить самого крутого работника до руководителя - одна из самых больших проблем любой индустрии. В том числе она проявляется в IT. Вместо того, чтобы промоутить в лидов тех, кто хочет и умеет, в целом предпочитается терять хорошего разраба и получать плохого менеджера. В статье описывается небольшое "исследование" на выявление работы этого принципа. Были взяты аналитические данные по работе продавцов (sales). Продавцы оказались удобными для анализа т.к. их эффективность легко посчитать. У обычного работника считаются, собственно, сами продажи, а у менеджера измеряется изменение метрик отдела после становления руководителем. Выяснилось, что самые крутые продавцы чаще получали повышение, и при этом чаще же оказывались плохими менеджерами. В итоге компания теряла хорошего работника и получала плохого менеджера. Как с этим бороться? - Поощрять хороших работников другими способами, а не только повышениями - Сделать отдельные карьерные лестницы для менеджеров и неменеджеров

Rspack - новый бандлер, написанный на Rust, который старается заменить webpack. Основные фичи: быстрый (за счет фокуса на распаралелливании процессинга и использования Rust) и совместимость с webpack. Совместимость с webpack не полная, но основные лоадеры уже работают. Т.е. видимо (я не погружался) если у вас болеe менеe простой конфиг без изысков (кастомных лоадеров и плагинов), то можно заменить webpack на rspack в строке запуска сборки и все заработает, только быстрее.

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

Пост в блоге Sentry про переезд с Enzyme на React Testing Library. В Sentry долгое время использовали Enzyme, но в итоге столкнулись со следующими проблемами: - Enzyme некорректно работает с React 17. А React 18 пока не планируют поддерживать - Enzyme завязан на внутренности React - Нет удобного API для тестировния хуков - Enzyme медленный - Тесты завязаны на внутренний стейт компонентов В итоге разработчики Sentry решили начать миграцию на RTL: - Нужно обучить разработчиков писать тесты на RTL - Все новые тесты пишутся на RTL - Старые тесты мигрируются по-немногу. Либо отдельной активностью, либо вместе с изменением существующих enzyme-тестов При этом команда столкнулась со следующими проблемами: - getByRole медленно работает на больших компонентов. В таких кейсах начали использовать другие методы получения DOM-элементов - userEvents тоже работают медленно. И сами по себе, а также ребята заметили, что эмуляция клика плохо работает если у компонента много стилей т.к. RTL проверяет, можно ли на компонент кликнуть (ну, например, нет ли на компоненте display: none) В целом, рекомендую к прочтению. Опять хороший гайд по тому, как делать миграции с одной технологии или подхода на другую в больших проектах

Каталог популярных инструментов для node.js экосистемы

Sandworm - библиотека для проведения аудита безопасности JS проектов