Storybook for React Server Components

Storybook добавили экспериментальную поддержку React Server Components в Storybook 8.0 alpha. Так как серверные компоненты могут полагаться на то, что доступен весь API node.js, то у команды Storybook было 2 стула:
- поменять архитектуру Storybook, чтобы там появилась серверная часть
- Сделать все на стороне клиента, но придумать как обойти ограничения

Естественно, выбрали сесть на второй. Реализация сделана на основе Next.js версии React. И если с рендером все более менее понятно, то непонятно что делать с зависимостями. Например, компонент ходит в БД. Для этого Storybook предлагает выделять такие операции в отдельные модули, которые затем в истории можно замокировать черезstorybook-addom-module-mock или через другие решения

export const Success {
  args: { id: 1 },
  parameters: {
    moduleMock: {
      mock: () => {
        const mock = createMock(db, 'findById');
        mock.mockReturnValue(Promise.resolve({
          name: 'Beyonce',
          img: 'https://blackhistorywall.files.wordpress.com/2010/02/picture-device-independent-bitmap-119.jpg',
          tel: '+123 456 789',
          email: '[email protected]'
        }))
        return [mock];
      },
    },
  },
}

https://storybook.js.org/blog/storybook-react-server-components/

#development #javascript #storybook #reactServerComponents

React Tricks: Fast, Fit and Fun

Транскрипция доклада с React-митапа в Копенгагене про уроки и хаки, полученные во время разработки Wouter - библиотека микро-роутер

Автор рассказывает про всякие интересные особенности React, которые позволяют делать компоненты с меньшим количеством ререндеров и меньшим размером при сборке (автор типа частично гонится за оптимизацией размера в gzip). Это все приправлено наглядными демками.

Если коротко, то список уроков и хаков такой:
- cloneElement позволяет добавлять пропсы children-компонентам без добавления лишних оберток. Это также может быть крайне полезно для навешивания ref
- Инициализатор состояния в useState выполняется перед любыми другими хуками и выполняется гарантированно 1 раз. Это также может быть полезно для заворачивания тяжелых вычислений
- Стабильные ссылки на функции с помощью useEvent. useEvent пока еще обсуждается в React, но можно взять реализацию из npm
- useSyncExternalStore, в отличии от комбинации useEffect и useState, позволяет легко и удобно подписываться на состояние и при этом избежать проблемы с неодновременным обновлением UI.

https://molefrog.com/notes/react-tricks

#development #javascript #react #performance

Неплохой канал, где тоже постят ссылки на всякое полезное, но не с таким подробным описанием как у меня (хотя и у меня далеко не всегда подробное описание)

https://www.tg-me.com/coderoll

Канал уходит на новогодние каникулы. Новых ссылок не будет до 9 января.

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

Всех с наступающим новым годом🌲🎅!

Bun, Javascript, and TCO

Статья про tail call optimization - хвостовую оптимизацию вызовов. Когда мы вызываем функцию Б из функции А, то движок формирует call stack - стек вызовов. Это позволяет движку или процессору при выходе из функции Б в функцию А быстро восстанавливать состояние окружения. Но этот стек не бесконечен и, вроде, зависит от окружения (я знаю про ограничение в 65 536 в каких-то движках). Достаточно сложно упереться в лимит в обычном коде, но это реально сделать при реализации рекурсивных функций. Tail Call Optimization позволяет избежать этой проблемы, если движок видит, что функция вызывает саму себя.

Проблему легко продемонстрировать на реализации функции, которая принимает на вход число amount, а на выходе дает массив длинной amount, где значение каждого элемента равно его порядковому номеру.

Мы можем реализовать эту функцию через цикл, и она будет прекрасно работать

function count(amount) {  
  let nums = [];  
  for (let i = 1; i <= amount; i++) 
   nums.push(i);  
  return nums; 
}

Но также мы можем реализовать её через рекурсивный вызов

"use strict"
function count(amount, cur = []) {
  return cur.length >= amount ? cur : count(amount, [...cur, cur.length + 1]);
}

В этом случае, если в движке не реализован Tail Call Optimization, то есть шанс переполнить стек вызовов. Собственно именно это произойдет в Google Chrome, если выполнить count с более менее большим аргументом. В safari же код корректно отработает т.к. в движке safari оптимизация реализована.

А т.к. bun работает на движке JavascriptCore, который в safari, то и в нем есть Tail Call Optimization.

Однако, если мы сравним скорость работы реализации через цикл и рекурсию, то мы увидим огромную разницу (в посте говорится о 0.1 секунды против 7 секунд). Дело в том, что при работе с рекурсией нужно также задумываться и о работе с памятью. В данном случае, рекурсивная функция каждую итерацию собирает новый массив данных. Если изменить алгоритм функции на мутирующий, то она будет выполнятся также быстро как и вариант с циклом

"use strict"
function count(amount, cur = []) {  
  if (cur.length >= amount) 
    return cur;
  cur.push(cur.length + 1);
  return count(amount, cur); 
}

https://www.onsclom.net/posts/javascript-tco

#development #javascript #bun #tailCallOptimization #recursion #optimization #performance

How Single Sign-on Works And Why You Should Care

В статье разбирается базовый флоу работы ссо авторизации в двух имплемениациях: oidc и saml. Они немного отличаются, но в целом работают похоже. SAML чуть сложнее,  но более распространённая техника.

SSO - single sign on. Это такой тип авторизации, когда есть несколько сервисов одной или нескольких компаний и пользователь может залогиниться единожды в один из них, а в остальные сервисы авторизация расшарится автоматически  

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



https://fusionauth.io/articles/authentication/how-sso-works

#development #sso #authentication #authorization #saml #oidc

Making Sense Of “Senseless” JavaScript Features

Статья рассказывает про смысл казалось бы бессмысленных фичей Javascript. 

Первой под разбор попала классическая проблема , когда 0.1 + 0.2 = 0.300000001. Часто в интернете жалуются, что JS такой нелогичный язык, что нельзя надеятся на корректное сложение двух чисел. Однако это проблема общая для всех языков, которые поддерживают стандарт работы с числами с плавающей точкой.  В статье  подробно и в картинах разбирается, что это за стандарт и как он работает. Как минимум стоит прочитать этот разбор, если вы не знаете про этот механизм

Следующая особенность - приведение типов. Javascript - язык с динамической типизацией. И он позволяет проводить операции над разными типами со своими специфичными правилами. Например,  сравнивать строку и boolean или складывать число и строку. Это, скорее всего, было добавлено в язык чтобы упростить вход для новичков: не нужно заморачиваться с явным преобразованием данных в переменой, вместо этого просто сложи строку и число, язык сам все сделает правильно. Проблема этой логики в том, что она не очень логичная. Поэтому её нужно запоминать наизусть, чтобы не допускать ошибок. Но т.к. у людей память не идеальная, то многие разработчики либо не помнят как это работает, либо помнят неправильно.  В итоге это часто приводит к ошибкам в проде.

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

Например, этот код отработает не так, как мы ожидаем, при взгляде на него

const a = 1
(1).toString()

const b = 1
[1, 2, 3].forEach(console.log)

Движок его приведет к виду

const a = 1(1).toString();

const b = (1)[(1, 2, 3)].forEach(console.log);

Поэтому проще всегда ставить ; в коде, чем помнить о том, как их вставляет движок

Следующая проблема: очень много значений, обозначающих "ничего" - null, undefined, NaN (в каком-то роде). И все они работают по разному. При этом разница между null и undefined не совсем понятная. Поэтому сообщество разработчиков часто спорит о том, нужен ли null вообще, ведь undefined выполняет всё те же функции, но ещё и не прикидывается object'ом.

Последний поинт в статье: операторы инкременты и декремента: i++ и ++i. Это явное наследие языка C. Хотя в большинстве случаев понятно как работает оператор, разработчики иногда допускают ошибки (сам лично допустил ошибку сегодня, пока делал заметки про Tail Call Optimization и сделал бесконечную рекурсию).

https://www.smashingmagazine.com/2023/12/making-sense-of-senseless-javascript-features/

#development #javascript

Дайджест за 2024-01-10 - 2024-01-12

Bun, Javascript, and TCO
Статья про tail call optimization - хвостовую оптимизацию вызовов. Когда мы вызываем функцию Б из функции А, то движок формирует call stack - стек вызовов. Это позволяет движку или процессору при выходе из функции Б в функцию А быстро восстанавливать состояние окружения. Но этот стек не бесконечен и, вроде, зависит от окружения (я знаю про ограничение в 65 536 в каких-то движках). Достаточно сложно упереться в лимит в обычном коде, но это реально сделать при реализации рекурсивных функций. Tail Call Optimization позволяет избежать этой проблемы, если движок видит, что функция вызывает саму себя.

Проблему легко продемонстрировать на реализации функции, которая принимает на вход число amount, а на выходе дает массив длинной amount, где значение каждого элемента равно его порядковому номеру.

How Single Sign-on Works And Why You Should Care
В статье разбирается базовый флоу работы ссо авторизации в двух имплемениациях: oidc и saml. Они немного отличаются, но в целом работают похоже. SAML чуть сложнее,  но более распространённая техника.


Making Sense Of “Senseless” JavaScript Features
Статья рассказывает про смысл казалось бы бессмысленных фичей Javascript. 

Первой под разбор попала классическая проблема , когда 0.1 + 0.2 = 0.300000001. Часто в интернете жалуются, что JS такой нелогичный язык, что нельзя надеятся на корректное сложение двух чисел. Однако это проблема общая для всех языков, которые поддерживают стандарт работы с числами с плавающей точкой.  В статье  подробно и в картинах разбирается, что это за стандарт и как он работает. Как минимум стоит прочитать этот разбор, если вы не знаете про этот механизм

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

Legacy Seam

Небольшая заметка в блоге Мартина Фаулера про работу с легаси кодом. Данная заметка посвящена созданию швов в коде, которые позволили бы управлять поведением системы, не изменяя сам код системы. В статье на достаточном простом примере на JS показывается, как это можно реализовать и зачем это нужно.

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

async function someLegacyFunction() {
   /* страшный код на jquery */
   const result = await someLegacySystemCall()
   /* страшный код на jquery */
}

Мы бы хотели иметь возможность заменять реализацию вызова запроса к легаси-системе. Для этого можно добавить шов, например, через явное прокидывание зависимости

async function someLegacyFunction(deps = { systemCall: someLegacySystemCall }) {
   /* страшный код на jquery */
   const result = await deps.systemCall()
   /* страшный код на jquery */
}

Теперь мы можем конфигурировать вызываемую систему без изменения кода. Это и есть шов. Кроме DI есть и другие способы. В частности в статье Мартина Фаулера применяется Service Locator и возможности модульной системы JS.

https://martinfowler.com/bliki/LegacySeam.html

#development #javascript #martinFowler #legacy #refactoring

Introducing JavaScript support in MySQL

В MySQL вводят поддержку Javascript. Относительно недавно Redis сделал то же самое, теперь хранимки на JS можно будет писать и для MySQL. JS запускается на GraalVM.

Пример объявления функции

CREATE FUNCTION gcd_js (a INT, b INT) RETURNS INT 
LANGUAGE JAVASCRIPT AS $$

  let [x, y] = [Math.abs(a), Math.abs(b)];
  while(y) [x, y] = [y, x % y];
  return x;

$$;

Последующий вызов

SELECT col1, col2, gcd_js(col1,col2)
FROM my_table
WHERE gcd_js(col1, col2) > 1
ORDER BY gcd_js(col1, col2);

CREATE TABLE gcd_table 
AS SELECT gcd_js(col1,col2)
FROM my_table;

Отдельного внимания достойна реализации дебага JS. Допустим, есть функция, которая валидирует данные. Она выводит console.log и выкидывает строчку (не ошибку), если валидация проваливается

CREATE PROCEDURE division (IN a INT, IN b INT,
OUT result DOUBLE) LANGUAGE JAVASCRIPT AS $$
  function validate(num) {
    console.log("validating input value: ", num);
    if (num === 0) throw ("Division by Zero!");
  }
  validate(b);
  result = a / b;
$$

Теперь, при вызове функции с неверными данными мы увидим ошибку, а также сможем SELECT-ить то, что вывелось в консоль и stack-trace ошибки

CALL division( 5, 0, @res);
ERROR 6000 (HY000): JavaScript> Division by Zero!

SELECT mle_session_state("stdout");
validating input value:  0

SELECT mle_session_state("stack_trace");
<js> validate(division:9:187-214)
<js> division(division:11:222-232)
<js> :anonymous(division:15:256-265)
</js></js></js>

https://blogs.oracle.com/mysql/post/introducing-javascript-support-in-mysql

#development #javascript #mysql

Effection: Structured Concurrency and Effects for JavaScript

Наткнулся на анонс 3 версии библиотеки Effection. Анонс не очень интересный, а вот библиотека - очень даже интересная. Библиотека предоставляет удобное, хорошо структурированное и небольшое API, которое представляет легковесную альтернативу async/await подходу, но на основе генераторов и итераторов. Библиотека дает следующие плюшки и гарантии: отмена вызовов (за счет генераторов), легкая композиция, полный контроль за исполнением и отсутствие гонки. Выглядит интересно.

https://frontside.com/effection/

#development #javascript #concurrency #library

Let's Bring Back JavaScript's `with()` Statement

Многие читатели канала возможно даже не знают про оператор with, а тут про него целая статья. Оператор with официально признан устаревшим и не рекомендованным к использованию, но в Kotlin такой оператор есть и он достаточно неплохо работает. В статье описывается, чем хорош оператор with и чем он плох.

Если вы вдруг не знаете, что это за оператор, то вот вам ёмкое описание: оператор with позволяет переопределить скоуп поиска переменных.

Но лучше, конечно, показать кодом

const person = {
 name: 'Milton Friedman',
 wasRight: true
}

with(person) {
 console.log(name); // 'Milton Friedman'
 console.log(wasRight); // `true`
}

Обычно переменные ищутся сначала в лексическом скоупе (или что-то в этом роде), затем в глобальном (например в window). Оператор with позволяет добавить еще 1 приоритетный скоуп для поиска переменных. Если в нем не будет найдено переменной, JS пойдет искать дальше как обычно

Проблемы оператора with:
- Есть проблемы с читабельностью кода. Когда мы видим использование переменной name, как нам понять - это от скоупа with или откуда то еще?
- Если в скоупе with не окажется такой переменной, то она будет искаться в глобальном скоупе и может там найтись, что приведет к ошибкам. Например, мы прокидываем в with объект, у которого есть поле history. Но что, если мы ошиблись, и поле history есть не всегда? Тогда при попытке достать history JS его не найдет в with-скоупе, но найдет в window.
- Использование with замедляет код. Автор кстати пишет свой кастомный with, в котором пытается решить эту проблему. Интересно, что для реализации оптимизации он заиспользовал eval, в котором прописан нативный with. Решение интересное

function limitedWith(obj, cb) {
  const keys = Object.getOwnPropertyNames(obj);
  const scopedObj = new Proxy(obj, {
    has(_target, key) {
      return keys.includes(key);
    },
  });

  return eval(`
    with(scopedObj) {
      (${cb}.bind(this))();
    }
  `);
}

Деструктуризация является современной альтернативой with. Не смотря на то, что есть неудобство в виде возможного конфликта имен переменных, это более явная форма доставания свойств из объекта

const person = {
 name: 'Milton Friedman',
 wasRight: true
}

// with вариант
with(person) {
 console.log(name); // 'Milton Friedman'
 console.log(wasRight); // `true`
}

// деструктуризация
const { name, wasRight } = person;
console.log(name); // 'Milton Friedman'
console.log(wasRight); // `true`

https://macarthur.me/posts/with

#development #javascript #with

Simulating Fluids, Fire, and Smoke in Real-Time

Статья про то, как реализовать анимацию огня. Много матана, много демок. Достаточно специфичный контент, но при этом вроде бы хороший. Демки очень интересные, но на моем рабочем ноуте достаточно тяжеловесные. мой Vivaldi подвисает просто от скролинга страницы.

https://andrewkchan.dev/posts/fire.html

#development #javascript #animations

Дайджест за 2024-01-15 - 2024-01-19

Legacy Seam
Небольшая заметка в блоге Мартина Фаулера про работу с легаси кодом. Данная заметка посвящена созданию швов в коде, которые позволили бы управлять поведением системы, не изменяя сам код системы. В статье на достаточном простом примере на JS показывается, как это можно реализовать и зачем это нужно.

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

Introducing JavaScript support in MySQL
В MySQL вводят поддержку Javascript. Относительно недавно Redis сделал то же самое, теперь хранимки на JS можно будет писать и для MySQL. JS запускается на GraalVM.


Effection: Structured Concurrency and Effects for JavaScript
Наткнулся на анонс 3 версии библиотеки Effection. Анонс не очень интересный, а вот библиотека - очень даже интересная. Библиотека предоставляет удобное, хорошо структурированное и небольшое API, которое представляет легковесную альтернативу async/await подходу, но на основе генераторов и итераторов. Библиотека дает следующие плюшки и гарантии: отмена вызовов (за счет генераторов), легкая композиция, полный контроль за исполнением и отсутствие гонки. Выглядит интересно.

В комментариях к посту много обсуждений на тему нужности и ненужности библиотеки и генераторов

Let's Bring Back JavaScript's `with()` Statement
Многие читатели канала возможно даже не знают про оператор with, а тут про него целая статья. Оператор with официально признан устаревшим и не рекомендованным к использованию, но в Kotlin такой оператор есть и он достаточно неплохо работает. В статье описывается, чем хорош оператор with и чем он плох.


Simulating Fluids, Fire, and Smoke in Real-Time
Статья про то, как реализовать анимацию огня. Много матана, много демок. Достаточно специфичный контент, но при этом вроде бы хороший. Демки очень интересные, но на моем рабочем ноуте достаточно тяжеловесные. мой Vivaldi подвисает просто от скролинга страницы.


——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегамдрузьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂

More Than You Need to Know About ReactDOM.­flushSync

flushSync в React позволяет синхронизировать состояние компонента React с его представлением в DOM-дереве. Когда мы вызываем setState, React складывает обновления стейта в очередь, затем разбирает очередь, делает рендер, и чуть позже отображает компонент в DOM-дереве. Получается, что между установкой стейта и его отображением в DOM мы ожидаем как минимум двух шагов: рендера и коммита. Такая реализация позволяет избегать лишних ререндеров. flushSync позволяет нам сразу отобразить изменения в DOM-дереве т.к. этот метод форсит React синхронизировать состояние компонента и представления в DOM.

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

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

Рекомендуется к прочтению всем React-разработчикам.

https://julesblom.com/writing/flushsync

#development #javascript #react #flushSync #recommended

We invested 10% to pay back tech debt; Here's what happened

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

Технический долг опасен тем, что он увеличивает Lead Time, частоту появления ошибок, время на починку ошибок и восстановление, время на разработку. Автор статьи перешел в новый продукт, который оказался переполнен техническим долгом и задачи выполнялись заметно медленнее, чем он ожидал. Команда каждую ретроспективу поднимала тему исправления технического долга, но какого-то определенного плана не следовало. Пока однажды они все таки не договорились о том, что нужно уделять 20% времени исправлению технического долга. Продуктовый менеджер назвал эту цифру неприемлемой и в итоге команда сошлась на 10%.

Как организовать выделение 10% на исправление технического долга? Один из вариантов - дежурства, другой - пробовать оценивать работу. Команда же принимала решение на основе принципа, что вся команда должна вместе решать эту проблему, а не кто-то один. С одной стороны, вместе сделали - вместе исправляем. С другой стороны, это поощряет совместную работу. Таким образом родилась Пятница Технического Долга. Каждую пятницу команда делает не технические задачи, а выплачивает технический долг.

Вы можете заметить, что пятница в рабочей неделе - это 20% времени, а не 10%, но автор говорит что часть людей в пятницу берут day-off'ы, поэтому выходит близко к 10%. В целом, не суть сколько % времени на это выделяется, суть в самом подходе - вся команда имеет единое время, выделенное на исправление технического долга и при этом поощряется совместная работа.

Практика оказалась настолько удачной, что начала распространятся на другие команды.

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

https://blog.alexewerlof.com/p/tech-debt-day

#managment #technicalDebt #recommended

What should we ship?

Недавно у Vercel вышел новый лендинг. Статья же рассказывает, как разработчики реализовывали разные интересные решения для него - свою гибкую систему гридов, работу с иконками, удобные блоки кода, интерактивные визуализации и движения по орбитам. Выглядит красиво и интересно.

https://rauno.me/craft/vercel

#development #javascript #vercel #html #css

How to make Storybook 2-4x faster

Команда Storybook рассказывает, как ускорить сборку storybook в проекте в 2-4 раза. Простые советы, которые могут улучшить вашу разработку:
- Используйте флаг --test для сборки storybook для визуальных и юнит-тестов. Это оптимизированная сборка storybook, в которой исключено все ненужно для автотестов. Возможно собранный storybook будет неплох и для разработки
- Генерация авто-доки к компонентам на основе TS медленная, за счет медленного TS. Генерируемая авто-дока - это фича Storybook, которая определяет, какие пропсы есть у компонента, какого они типа и отрисовывает панельку управления пропсами компонента. Лучших результатов можно достигнуть за счёт получения информации о типах от TS. Но это сильно замедляет сборку автодоки, поэтому, если вам эта фича не так важна - можно заменить docgen на тот, который получает инфу на основе AST кода, а не типов. Он работает в 2 раза быстрее
- Если вам не нужны все фичи storybook (например фича документации через mdx), то вы можете отключить эти фичи, передав опции в storybook/addon-essentials
- Перейдите на SWC, вместо webpack

https://storybook.js.org/blog/optimize-storybook-7-6/

#development #storybook #performance

Remote Mob Programming

Mob-programming переводится буквально как программирование толпой (насколько я помню английский). Это как парное программирование, только вместо пары разработчиков за одним экраном и клавиатурой сидит вся команда. Сайт рассказывает про лучшие практики проведения моб-программирования в условиях распределенной разработки. Также там есть бесплатная книжка, где все описано подробнее.

Короткий список основных требований на пути к успешным сессиям моб-программирования в распределенном формате:
- Все должны работать удаленно. Если часть команды в офлайне друг с другом, а часть - через камеру, то возникает асиметричность информации, которая вредит коммуникации
- Камера всегда включена. Коммуникация намного более качественная, когда мы имеем возможность видеть друг друг
- Регулярные личные встречи. Чем лучше все друг друга знают, тем лучше все идет взаимодействие при удалённой работе. Поэтому периодически встречаться в офлайне для совместного времяпрепровождения и знакомства крайне положительно влияют на работу
- Маленькая команда. Во время удалённого моб-программирования случаются технические накладки, задержки, а говорить в 1 момент времени может только 1 человек. Как следствие, проводить сеанс удаленного моб-программирования неэффективно в большой команде.
- Единое рабочее время. У всех должен быть единый рабочий слот, в который люди готовы работать вместе в режиме моб-программирования. Не обязательно, и наверное даже вредно, выделять весь рабочий день как единое рабочее время. На сайте команда описывает свой опыт и они выделяют 6 часов, в которые все должны быть на связи
- Выделенная роль печатальщика (typist). Только 1 человек имеет контроль над клавиатурой. Этот человек следует инструкциям остальной команды, задает уточняющие вопросы. Человек не должен сам принимать какие-то решения и реализовывать их
- Шаринг экрана. Печатальщик шарит свой экран, а другие смотрят только на него. Есть IDE, которые созданы для совместной работы, но авторы статьи говорят, что им они не зашли т.к. люди начинают в них отвлекаться от общей сессии в пользу своих активностей.
- Короткие интервалы для смены ролей. Собственно ролей всего 2: печатальщик и остальные. Суть в том, чтобы меняться как можно чаще. Авторы используют 10 минутные интервалы, но в вашей команде возможно понадобятся другие. Ротация позволяет всем участвовать в процессе в обеих ролях.
- Передача кода через git. Для передачи кода от одного участника другому используется git. При этом можно упростить флоу до минимального: комитить месседжи "WIP" и работать во временной ветке. Перед вливанием кода в общую ветку code review не требуется т.к. код автоматически получается отсмотренным и проверенным в процессе моб-програмирования.
- Групповые решения. Групповые решения всегда лучше индивидуальных. Групповые решения - еще один автоматический плюс от моб-программирования. Однако, их все равно необходимо документировать, например через ADR.
- Постоянное движение. При работе в одиночку мы часто блокируемся: надо что-то погуглить, почитать документацию или подождать пока проведут code review. В моб-программировании блокировки исключаются т.к. все проблемы решаются тут же.
- Взаимное обучение. Шаринг знаний стоит в основе моб-программирования. Работая в едином окне, происходит взаимное опыление знаниями. Некоторые знания сложно получить другим способом. Например, ваш коллега настроил крутую фичу в IDE, про которую вы не в курсе, а он думает, что все про фичу знают. Также моб-программирование полностью решает проблему бас-фактора.
- Доверие. Экспресс-тест на доверие менеджмента к вам: скажите менеджеру, что с завтрашнего дня вы каждый день весь день будете работать вчетвером за 1 экраном. Если менеджмент вам доверяет, то не усомниться в верности вашей идеи. Чтобы внедрить моб-программирование в процесс разработки, необходимо обеспечить прозрачность коммуникаций и прогресса, а также построить доверительные отношения с менеджментом.

https://www.remotemobprogramming.org

#development #mobProgramming #pairProgramming #recommended

Дайджест за 2024-01-22 - 2024-01-26

⭐More Than You Need to Know About ReactDOM.­flushSync
flushSync в React позволяет синхронизировать состояние компонента React с его представлением в DOM-дереве. Когда мы вызываем setState, React складывает обновления стейта в очередь, затем разбирает очередь, делает рендер, и чуть позже отображает компонент в DOM-дереве. Получается, что между установкой стейта и его отображением в DOM мы ожидаем как минимум двух шагов: рендера и коммита. Такая реализация позволяет избегать лишних ререндеров. flushSync позволяет нам сразу отобразить изменения в DOM-дереве т.к. этот метод форсит React синхронизировать состояние компонента и представления в DOM.

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

⭐We invested 10% to pay back tech debt; Here's what happened
Во время разработки в системах неумолимо растёт технический долг. Есть много разных способов делить и определять технический долг, но в целом его можно поделить на созданный осознанно и не осознанно. Технический долг создается осознанно, когда нам необходимо успеть к релизу или срезать какие-то углы. Неосознанно технический долг создается, когда нам не хватает знаний, компетенций или культуры. Проблемы с техническим долгом нет, пока он выплачивается. Но как быть, если технический долг долгое время не выплачивался, а теперь надо начать? В статье предоставляется пример одной команды, которая нашла для себя ответ на этот вопрос.

Технический долг опасен тем, что он увеличивает Lead Time, частоту появления ошибок, время на починку ошибок и восстановление, время на разработку. Автор статьи перешел в новый продукт, который оказался переполнен техническим долгом и задачи выполнялись заметно медленнее, чем он ожидал. Команда каждую ретроспективу поднимала тему исправления технического долга, но какого-то определенного плана не следовало. Пока однажды они все таки не договорились о том, что нужно уделять 20% времени исправлению технического долга. Продуктовый менеджер назвал эту цифру неприемлемой и в итоге команда сошлась на 10%.

What should we ship?
Недавно у Vercel вышел новый лендинг. Статья же рассказывает, как разработчики реализовывали разные интересные решения для него - свою гибкую систему гридов, работу с иконками, удобные блоки кода, интерактивные визуализации и движения по орбитам. Выглядит красиво и интересно.

How to make Storybook 2-4x faster
Команда Storybook рассказывает, как ускорить сборку storybook в проекте в 2-4 раза. Простые советы, которые могут улучшить вашу разработку:\n- Используйте флаг --test для сборки storybook для визуальных и юнит-тестов. Это оптимизированная сборка storybook, в которой исключено все ненужно для автотестов. Возможно собранный storybook будет неплох и для разработки

⭐Remote Mob Programming
Mob-programming переводится буквально как программирование толпой (насколько я помню английский). Это как парное программирование, только вместо пары разработчиков за одним экраном и клавиатурой сидит вся команда. Сайт рассказывает про лучшие практики проведения моб-программирования в условиях распределенной разработки. Также там есть бесплатная книжка, где все описано подробнее.

——————————————

Спасибо что читаете, ставите реакции и отмечаетесь в комментариях. Если вы хотите помочь каналу - расскажите о нем своим коллегам, друзьям. Также оставляйте фидбек по формату, материалу и чему-угодно еще 🙂