Development

Хорошая статья про добавление своего пост-процессинга в Three.js. В статье рассказывается про то, как добавить эффект типа "скетч, нарисованный ручкой" в рендер Three.js. Если вам интересна анимация - можно почитать. Такие статьи меня цепляют тем, что показывают, какие возможности у нас сейчас есть при работе с JS в браузере. Не просто формочки или простые задачи, а вот 3d-рендер с кастомным интересным эффектом.

Статья про Intl.Segmenter - API, которое позволяет разделить текст на предложения, слова или графемы. В статье описывается, почему обычный `str.split` не подходит и почему нужно более умное API, которое само умеет корректно разделять текст на составные части.

Сейчасть есть модный тренд на переписывание инструментов для сборки на Rust или Go. Типа если мы перепишем инструмент на язык, который ближе к железу, то он будет работать быстрее. Однако JIT в текущих JS движках тоже достаточно быстрый, и возможно проблема не в языке, на котором написан инструмент, но в самом коде. В статье автор разбирает, как он с помощью профайлера находил проблемы с перформансом в текущих библиотеках и как исправлял код в них, чтобы они работали быстрее. В статье достаточно подробное описание, что за проблема, почему это проблема и как её решать. Также есть ссылки на PR-ы в инструменты Честь и хвала таким героям, которые оптимизируют инструменты, которые афектят на все сообщество. Основной посыл статьи - вместо того, чтобы переписывать инструменты на другие языки, следует все таки посмотреть, что можно оптимизировать в текущем стеке. Рекомендую к прочтению

Вышел выпуск подкаста "QAk-QAk — и в продакшен", где я полчаса рассказываю про TDD, BDD и автотесты в целом. Еще немного задеваем DDD. Достаточно коротко и ёмко, на мой скромный взгляд :) По ссылке лежат ссылки на разные платформы для подкастов. Для тех кто не слушает подкасты в приложеньках, ссылка на ютуб ютубе https://www.youtube.com/watch?v=zicVvaU4S44&feature=youtu.be

История про ускорение React приложения с таблицами в 4 раза. Инженеры из Casual - приложения, которое умеет показывать таблицы с большими данными, поделись историей профилирования React кода и ускорения приложения. Т.к. таблицы должны показывать достаточно большие данные, то приложение должно работать быстро и нужно следить за перформансом. Сначала они искали долгие вызовы в Chrome DevTools и обнаружили кучу ререндеров React. Для отрисовки таблиц используется библиотека AG Grid. После нахождения нужного вызова в Chrome DevTools они решили посмотреть его в React Profiler. Автор также описывает, почему сначала искали в Chrome DevTools. Искать глобальные проблемы лучше в Chrome DevTools. И только после обнаружения конкретного источника следует обращаться к React Profiler. В рамках React Profiler находится конкретная причина ререндар конкретного компонента. Дальше автор уже дебажит через console.time. Таким алгоритмом они нашли несколько проблем. Некоторые порешались реорганизацией хуков. Другие, применением достаточно интересными хаками. Например, была проблема перезапуска `useEffect` при изменении переменных для автокомплита, когда они поменялись для JS, но не по смыслу. Например, были `['one', 'two']`, а стал новый массив `['one', 'two']` или `['two', 'one']`. В обоих изменениях не нужно перезапускать useEffect. Решение немного грязное, но хорошее ``` useEffect(() = { // ... }, [gridApi, Object.keys(autocompleteVariables).sort().join(',')]); ``` Также, из интересных приёмов, была найдена проблема в AG Grid. Ребята решили ее достаточно интересным способом - воспользовались yarn patch. Для тех кто не знает что это - yarn позволяет делать изменения в пакетах в `node_modules`. Этот же патч ребята предложили в AG Grid, но AG Grid не принимает PR от сообщества. Также из интересных техник можно отметить замену `useSelector` на `useStore`. `useSelector` подписывается на изменения стора, что ведет к ререндеру компонента. Однако, компоненту не нужны были данные из `useSelector` для рендера, они использовались в колбеке `onChange`. Чтобы избежать лишнего ререндера, компонент получал весь стор через `useStore` и доставал нужные поля прямо в `onChange`. На текущем проекте мы решаем такие проблемы тем, что логика взаимодействия, которая не связана напрямую с UI, выносится в отдельные action'ы. А они уже достают данные откуда им удобно. Это как раз решает эту проблему by design - компонент не тянет данные и логику, которые ему не нужны. Еще из интересного: в приложении используется protobuf. Это бинарный протокол передачи данных, поэтому он требует парсинга. Если данных много - парсинг моет идти долго (400-800мс в статье). Этот парсинг - отличный кандидат на вынос в web workers. Применение воркера вынесло обработку в отдельный тред, но общение с воркером - не бесплатное. Т.к. нужно передать между приложением и воркером много данных, эта оптимизация особо не ускорила приложение. Вот такими разными способами инженеры из Casual ускорили отображение модели из 100 категорий в 4 раза. Статья - отличный показатель того, как можно заниматься ускорением приложения - показаны разные инструменты и разные подходы.

Простая анимированная шпаргалка объясняющая, что происходит, когда применяются хуки в React. Можно проследить за каждым шагом применения хука - от старта рендера до отрисовки в браузере

Очень хороший гайд по созданию анимаций. Объясняется, как Framer делает такие плавные анимации и как достичь таких же плавных анимаций в своем коде. Все это с подробными примерами кода (css + React) и с хорошими примерами анимаций. Объясняются проблемы с анимацией (почему css анимация не всегда подходит, проблемы анимации изменения размера элемента) Также подробно объясняется методика анимации FLIP. Если коротко: - First - запомнить позицию элемента, где он находится в начале анимации - Last - запомнить позицию элемента, где он находится в конце анимации - Inverse - применить такое изменение, которое превращает состояние Last в First - Play - Убрать применение inverse. Таким образом элемент будет анимирован от First к Last. Рекомендую к прочтению

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

Законы Лармана об организационном поведении Это наблюдения, сделанные Крейгом Ларманом в результате десятилетий наблюдений за организациями. 1. Организации неявно оптимизированы избегать изменения статуса кво менеджеров и специалистов 2. Следствие первого закона, любая инициатива по изменению статуса кво будет заторможена переопределением или переосмыслением новой терминологии так, чтобы статус кво не изменился 3. Следствие первого закона, любая инициатива по изменению статуса кво будет высмеяна как революционная, теоретическая, религиозная и будет предлоожено приземлить ее в реальный мир так, чтобы не менять статус кво 4. Следствие первого закона, если менеджеры или специалисты все таки изменили свой статус, то они становятся коучами/тренерами, которые курируют изменения и усиливают действие второго и третьего законов. 5. В больших организациях культтура следует за структурой. В мальеньких организациях структура следует за культурой. Как следствие 5го закона, нельзя изменить культуру большой компании, не меняя ее структуры. Поэтому, например, скрам меняет структуру чтобы изменить культуру.

15-минутное видео про роль Product Owner в Agile разработке. Кроме роли PO также рассказывается про agile разработку в целом: важность коммуникации, коротких циклов обратной связи, мелких историй, накоплению знаний. При этом это все очень хорошо визуализировано и автор хорошо поясняет за основные концепции. Рекомендую к просмотру.

Typescript совершил большой внутренний рефакторинг, в рамках которого код перевезли на ESM модули, отказались от namespaces, начали собирать код через esbuild (т.к. пользователи TS ожидают 1 выходной файл), выкинули немного лишнего (дублирующего) кода и это значительно улучшило показатели перформанса проекта: - Компилятор на 10-25% быстрее - tsc стартует на 30% быстрее - npm пакет стал на 43% меньше По сути, основной код typescript не был никак изменен, просто выкинули namespace и заменили их на честные импортые, которые забандлили через esbuild. Namespace давали просадку перформанса из-за сложных доступов к объектам, а esbuild дал еще оптимизаций на уровне сборки бандла. Хорошая история про рефакторинг проекта, который значительно улучшил проект для пользователей.

Библиотека, которая эмулирует dev-tools в браузере. Библиотека пробует решить проблему недоступности браузерных devtools при тестировании сайта в настоящем смартфоне в мобильном браузере с помощью создания своих devtols. Выглядит очень интересно, хотя не могу представить, чтобы я это где-нибудь использовал в реальной жизни. В readme проекта есть ссылка на демо, где можно поиграться с самописными девтулами

Вышел новый веб-фреймворк для nodejs - Hyperstack. Вдохновлен rails и уже имеет в себе всё, что нужно разработчику для комфортной и быстрой разработки: - контроллеры - orm (если я правильно понял) - апи для написания автотестов - апи для создания джоб

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

James Sinclair выложил 1 короткую главу из своей пока неизданной книги "A skeptic’s guide to functional programming with JavaScript". Данная глава объясняет основные концепции функционального программирования. Немного про композицию, про алгебраические структуры, про монады и все такое. На простых примерах показывается, как ФП помогает делать простой и понятный код. Рекомендую к прочтению.

Очень хорошая статья от James Sinclair про генератор-функции в JS. Автор коротко объясняет, как генератор-функции оказываются незаменимы при обработке огромных массивов данных (позволяют реализовать ленивую обработку), почему async/await не закрывает все потребности работы с асинхронными функциями и как можно сделать бесконечную последовательность. Генераторы не очень нужны в обычном коде приложения, но могут оказаться незаменимыми в "инструментальном" коде. Рекомендую к прочтению

Новый опенсорс от гугла в JS экосистему. Встречайте, wireit! У библиотеки достаточно ёмкое описание: wireit улучшает npm scripts делая их умнее и эффективнее. Нативные скрипты в npm имеют очень простую реализацию и что-то сложнее, чем проксирование команд из других пакетов, делать неудобно. Собственно npm никогда и не хотел быть хорошим task-manager'ом, оставляя это на откуп сообществу. Wireit как раз инструмент, который позволяет удобно делать непростые скрипты для проекта. Wireit умеет: - указывать какой скрипт от какого зависит, что позволяет wireit запускать их максимально эффективно - запускать скрипты при изменении файлов - определяет, когда скрипт не нужно запускать - с точки зрения пользователя, интерфейс не меняется - все команды также запускаются через npm run Вместо тысячи слов просто положу пример, как тул подключается в проект через package.json файл ``` { "scripts": { "build": "wireit", "bundle": "wireit" }, "wireit": { "build": { "command": "tsc" }, "bundle": { "command": "rollup -c", "dependencies": ["build"] } } } ```

Вышел 4.0.0 релиз либы для логирования tslog в котором либу полностью переписали: - без зависимостей - работает в node.js и браузере - ESM - Большие возможности кастомизации Честно говоря, даже не слышал об этом логере до этого. Но интересно, что мейнтейнеры решили полностью все переписать. Судя по доке, логгер действительно достаточно фичастый и гибкий.

Вышел Deno 1.28 Как и обещала команда Deno - в этом релизе стабилизировали совместимость с npm экосистемой. Это значит, что теперь все пакеты из npm можно свободно использовать в Deno. При этом получая все плюшки Deno, связанные с безопасностью. На самом деле большой шаг для Deno т.к. собственная экосистема пакетов сильно сдерживала возможности для внедрения Deno в проекты. С совместимостью же появляется возможность пересесть с nodejs на deno за пару вечеров, меняя минимум в своем проекте. Также из нового и интересного: - lock-файл создается автоматически если есть конфиг deno - Стабилизировали несколько старых API и добавили новое единое экспериментальное API для запуска команд (напримре, для запуска какой-то консольной утилиты из deno-рантайма)

Статья про сложность (complexity) и простоту (simplicity). Статья сильно разбавлена водой, из-за чего её сложно пересказать в рамках поста в телеге. Но я попытаюсь. Сложность выглядит впечатлающе, а простота - обыденной (в статье приводится пример с египетскими пирамидами - для захоронения человека есть способы и попроще). Поэтому во многих аспектах жизни люди между простыми и сложными решениями выбирают сложные. Хотя следует наоборот. Почему нужно выбирать простые решения? Из-за природы складывания сложностей. Если взять 2 сложные вещи и связать их, то в сумме получится намного более сложная система. Сложность растет экспоненциально. В разработке ПО это особенно заметно - когда система сплошь состоит из сложных вещей, то она сама становится дико сложной. И в случае появления проблем все становится совсем плохо. Поэтому все лучшие практики написания кода, проектирования, создания интерфейсов, организаций, материальных вещей стремятся к простым решениям. Простоту легче поддерживать. Хотя, иногда, для того, чтобы начать упрощать систему, необходимо сначала добавить сложность. Основные поинты: - Между сложным и простым, следует выбирать простое. - Сложность растет экспоненциально - Чтобы уменьшить сложность в системе, скорее всего потребуется сначала её добавить (миграционный период)

Состоялся релиз Gatsby 5.0.0! Во первых, добавили Slice API, который позволяет выносить переиспользуемые компоненты или решения в отдельный слайсы, что ускоряет инкрементальные билды и деплои в Gatsby Cloud. Во вторых, добавили частичную гидрацию. Т.е. будут гидрироваться только те компоненты, которые нужны для работы текущего функционала в браузере. Это значительно ускоряет перформанс метрики. Т.к. эта фича построена вокруг React Server Components, то он, как и RSC - пока будет в бете. Также вышла вторая верся IDE GraphiQL. Это IDE в которой удобно разрабатывать Gatsby сайты и есть встроенная интеграция с GraphQL тулзами.

Вышел первый стабильный релиз инструментария Rome после начала переписывания на Rust. Напомню, что Rome - это инструментарий для веб-проектов, который решает проблему зоопарка инструментов в экосистеме, когда каждый инструмент реализует одно и то же много раз (например, babel, eslint, prettier, typescript не могут переиспользовать результаты обработки кода друг-друга). За счет этого планируется создать быструю единую экосистему инструментов с очень хорошим DX. В релизе поставляется линтер и форматтер. Линтер вдохновлялся eslint'ом и содержит 60 стабильных правил. Форматтер вдохновлялся prettier и, вроде как, можно без проблем заменить prettier на rome forammter Также авторы выделяют принципы, которым они следуют при разработке инструментария. Во первых, инструмент должен быть устойчив к ошибкам. Как пример приводится то, как eslint и rome linter обрабатывают ошибку синтаксиса. Если eslint встречает ошибку синтаксиса - то он не может обработать файл т.к. не может распарсить его в AST. Rome Linter же обрабатывает все, что может обработать (что смог распарсить в корректный AST). В статье есть прям гифка, покказывающая разницу для разработчика. Во вторых, высокая планка для диагностики ошибок. При обнаружении ошибки нужно сообщить разработчику: почему это ошибка, что будет если её не исправить, как её исправить. Среди текущих инструментов в этом весьма неплохо продвинулся typescript. А вот правила eslint, как правило, ничего не объясняют, а просто запрещают. В статье приводится пример, когда линтер сообщает, что есть код, который недостижим и линтер объясняет, почему он решил, что код недостижим. Выглядит круто! Выглядит неплохо, но в проекты вносить пока рано. Пока не выглядит, что у Rome есть серьезные преимущества против prettier и eslint. Ну работает быстрее. Но eslint и prettier и так достаточно быстрые чтобы успевать отрабатывать прямо в IDE на каждый введенный символ. Хотя если Rome сделает более удобную систему для конфигурирования линтера, то я бы задумался о попытке внедрения.

Интересная заметка, где автор описывает свой опыт замены jest на vitest. vitest позволяет небольшими изменениями перевести весь проект с jest на vitest. Поэтому попробовать vitest достаточно просто. В данной заметке интересны конкретные цифры. У автора jest оказался быстрее чем vitest (14 секунд против 16 секунд). И поэтому автор принял решение остаться на jest. Однако автор отмечает что vitest намного быстрее в watch режиме. Результаты показались мне интересными, потому что я пока не встречал кейсов, где vitest оказываелся бы медленнее jest тестов. На текущих моих проектах перезд на vitest ускоряет тесты, которые получилось перевезти. Из минусов - далеко не все тесты легко удается перевезти.

Статья про эволюцию и организацию работы команды Developer Experience. Что такое DX Team? Это паттерн команды, которая занимается улучшением опыта разработчика. Она улучшает внутренние инструменты, адаптирует процессы, строит системы удобного мониторинга и прочие интересные штуки, которые позволяют обычны м разработчикам делать свою работу лучше. Т.е. это команда разработчиков внутри компании, которая делает жизнь других разработчиков внутри компании лучше. Как появляются DX команды? 1. Сначала какая-то существующая команда находит у себя проблемы и решает её своими силами. 2. В какой-то момент появляется крупная проблема и её нельзя решить в фоновом режиме. Появляется отдельная внутренняя рабочая группа по устранению проблемы. После решения проблемы, если он актуальная для других команд, решение масштабируется на другие команды 3. Организация понимает ценность работы над DX и выделяет отдельную централизованную команду. Эта команда работает в двух направлениях: стратегическое развитие (решают проблемы всей органиации) и обработка запросов от разработчиков. Эта работа идет достаточно хаотично 4. Команда организует свой родмап и приоритезирует работу. Здесь может появится отдельный PM или PO. Также у команды появляются четкие критерии по определению приоритетов разработки. В статье также подробно описывается как приоритезировать задачи, но я тут останавливаться не буду. Также описано как проводить эксперименты для новых инструментов или процессов. Как известно, слона едят по частям, поэтому при внедрении больших изменений нужно их внедрять итерационно. Это же касается и DX команд. Как внедрять новые процессы и инструменты: 1. Найти early adopters. Это, как правило, команды у которых либо сильно болит текущая проблема, либо очень гибкие и открытие к новому люди 2. Сделать функционал для них и отдать им в пользование 3. Собрать фидбек 4. Если эксперимент удачный (адоптером помогло) - раскатить на всю организацию. Иначе либо отказаться от идеи, либо внести исправления и снова отдать их в early adopters команды. Рекомендую статью к прочтению всем, кто интересуется платформенными командами

Неплохой обзор QUIC в сравнении с TCP. Рассматриваются основные проблемы TCP и как QUIC их обходит. Также в статье рассматривается, из чего состоит QUIC соединение и как формируются пакеты. Предыстория QUIC для тех, кто пропустил все новости о нем. (Очень упрощенно, но не буду против если вы попинаете меня в комментариях, где я черезчур все упростил и пересказал неправильно) Есть 2 низкоуровневых протокола передачи данных: TCP и UDP. TCP реализует в себе гарантию доставки, т.е. посылая данные другому участнику сети, вы гарантировано получете от него ответ "получил". Это упрощает передачу данных (т.к. есть гарантия что другой участник взаимодействия получил или не получил данные), но в то же время замедляет весь процесс. UDP - это протокол без гарантии доставки данных. При его использовании участники обмена данных сами должны решить проблему потери пакетов. Но зато сама коммуникация очень быстрая (не нужно дожидаться ответа второго участника) Отсюда и популярные шутки вида "Я бы мог вам рассказать анекдот про UDP, но боюсь он до вас не дойдёт" HTTP и HTTP2 построены поверх TCP. Игры же, как правило, делаются поверх UDP. И вот относительно недавно (год-два назад) инженеры из Google пришли с идеей нового протокола для передачи данных на замену HTTP2 - QUIC. QUIC - это HTTP3. Все, что можно было выжать из TCP уже выжали. Поэтому QUIC построен вокруг UDP протокола, что позволяет ему быть супер быстрым, секурным и вот это вот всё.

Сначала storybook добавили для историй поле play, в которое можно складывать необходимые взаимодействия с компонентом Потом они добавили возможность писать там асерты и использовать истории как тесты Теперь же выходит статья про то, как собирать test coverage с этих тестов. В общем-то по ссылке доступна очень короткая инструкция про сбор test coverage у storybook тестов. Достаточно интересная возможность. Радует, что команда развивает storybook не только как песочницу или витрину для компонентов, но и как инструмент тестирования. О том что storybook - инструмент тестирования в первую очередь, я говорил на своих докладах последние пару лет. Но теперь storybook сам делает удобное API для тестирования и костылить что-то самому нужно намного реже.

Статья в блоге James Sinclair про неприятие командой введения функционального стила программирования. На мой взгляд, достаточно частая проблема, когда люди изучают функциональное программирование на ютубе, в статьях, книжках. Заряжаются на чистый код, композицию, частичное применение, монады. Приходят на проект и начинают писать код "как там". А потом, при открытии МР-а получают критику от коллег что всё непонятно, сложно, как это дебажить и вот это вот всё. В статье хорошо объясняется, что это не коллеги такие вредные, не хотят святой код в кодовой базе иметь. А просто нельзя вот так залететь с ноги и начать делать всё по своему. Даже из благих намерений. В статье приводятся следующие вопросы, на которые необходимо ответить при залетании с ноги (не только с функциональной ноги): - Как мы будем обучать команду новым подходам? - Если что-то случится на продакшне, сможем ли мы быстро пофиксить? Сможем ли мы быстро поставить дебаг-логи? - Как это масштабируется в нашем окружении? - Как мы будем поддерживать единообразие в структуре и стилистике кода? Ведь мы хотим, чтобы любой человек мог начать править любой код - Что случится, если ты (человек, влетающий с новыми порядками) уйдешь из проекта? Сможет ли команда это поддерживать? Поэтому внедрять новые подходы надо итеративно, чтобы все плавно обучались и эксперименты были небольшими (в случае неудачи их легче откатить). Дальше в статье идет гайд по рефакторингу от нечитаемого ФП-кода к читаемому ФП-коду Код, который, скорее всего, будет непонятен тем, кто не погружался в ФП ``` const renderNotifications = flow( map(addReadableDate), map(addIcon), map(formatNotification), map(listify), wrapWithUl ); ``` Код после рефакторинга, который остается чистым и композируемым, но при этом понятен всем ``` const renderNotifications = (notifications) = { const withDates = notifications.map(addReadableDate); const withIcons = withDates.map(addIcon); const formattedItems = withIcons.map(formatNotification); const listItems = formatedItems.map(listify); return wrapWithUl(listItems); }; ``` От себя добавлю что в фронтенд-сообществе ФП натурально "одурманивает" разработчиков и они начинают писать чистый ФП-код в перемешку с обычным кодом, что сильно усложняет чтение кода. Каюсь, сам таким был. Теперь же я предпочитаю сразу быть как Груг - бить дубиной за безосновательное радикальное применение ФП там, где ему не место. Впрочем, как и за другие ярые эксперименты, которые сильно усложняют код, но применяются потому что это "круто".

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

Я немного запаздываю относительно других каналов, но вот анонсировали новый бандлер от команды vercel - turbopack. Последние года идет тренд на переписывание инфраструктурных инструментов с JS на более низкоуровневые и производительные (хотя бенчмарки показывают разное) языки. Вот пришло время переписать бандлер на Rust. Обещают, что новый бандлер быстрее чем Vite в 10 раз и быстрее чем Webpack в 700 раз. Как я понял, Turbopack разрабытавался под next.js и начиная с 13 версии next.js проекты будут собираться на нём. Примечательно в этой истории также то, что "хоронит" webpack один из основных контрибьюторов webpack - Tobias Koppers. Я не помню с какого времени он разрабатывает webpack, но точно знаю, что вся глобальная деятельность в webpack c версии 2 по версию 5 - дело, в первую очередь, его рук. Так что можно расчитывать, что Turbopack будет очень хорош т.к. Тобиас очень хорошо понимает, как следует делать бандлеры.

Хорошая статья от Виталия Шароватова про то, что парное программирование позволяет делать продукт одновременно быстро и качественно. В статье разбираются 2 типичных проблемы команд разработки: - Индивидуальная работа ведет к тому, что второе мнение появляется слишком поздно (во время код-ревью, тестирования или уже на проде) - Оптимальный размер команды 6-7 человек, т.к. дальше уже слишком большой штраф синхронизации Обе эти проблемы решает парное программирование. Первая проблема решается by design - при парном программировании всегда есть второй участник, который даёт второе видение решения. Сразу происходит обмен мнениями, синхронизация, исправление. Работа в паре также положительно влияет на психологическую безопасность в команде. Вторая проблема решается тем, что для менеджера нет разницы - синхронизировать 6 человек со своими задачами или 6 пар со своими задачами. Это значительно упрощает коммуникацию. Не смотря на то, чо статья очень короткая, она хороша тем что имеет множество ссылок на другие статьи и исследования. В частности, там есть ссылки на 2 исследования, которые говорят следующее: - в результате парного программирования временные затраты возрастают на 15%, но повышается качество, уменьшается количетсво дефектов, устраняется бас-фактор, улучшаются технические скилыи коммуникация в команде - при командной работе повышается продуктивность, удовлетворение от работы и уверенность в решении Так что, если вы где-то услышите, что парное программирование - это дорого, вы можете ссылаться на исследование, которое указывает что это дороже всего на 15, но зато снимает многие другие риски