Development

Статья в блоге Мартина Фаулера про 2 pizza team. В статье кратко рассказывается откуда пошел термин и что он вообще значит.

2 pizza team - это команда, которую можно накормить двумя пиццами (по крайней мере американскими, говорят они там большие). Этот термин пошел из Amazon т.к. там этот принцип и зародился. В переводе на обычные числа это обычно означает 5-8 людей, хотя Мартин Фаулер говорит что предел около 15 человек

2pizza team должна быть самодостаточной и автономной - она должна уметь выпускать и сопровождать продукт собственными силами (т.е. иметь все необходимые компетенции и уметь работать как продуктовая команда (строить гипотезы, понимать желания пользователя и переводить их в код)).

Т.к. такие команды маленькие, то следовательно их очень много. Поэтому команды должны также уметь общаться друг с другом, а лучше четко делить ответственность за сервис между друг другом и предоставлять друг другу удобные API и документацию

Статья про комбинирование React Query и React Context. Сам по себе React Query очень удобен - он позволяет одновременно сделать компонент самодостаточным, но при этом абстрагировать логику запроса и кеширования данных, а также позволяет переиспользовать один кеш для нескольких компонентов. Но в случае с несколькими компонентами возникает проблема неявной зависимости - они могут использовать данные, предполагая, что другой компонент их уже запросил. Для решения этой проблемы автор предлагает использовать React Context

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

В статье также разбираются альтернативные паттерны для решения подобной проблемы, например Suspense

Статья на хабре про новый синтаксис using, который призван упростить работу с объектами, которые требуют исполнения кода при прекращении работы с ними (например, соединения к БД).

В статье достаточно просто и наглядно объясняется зачем это нужно, как это использовать и какие подводные камни могут быть.

В целом новый синтаксис призван превратить это:

в это

Кажется, что это не такое уж и важное дело, но в реальности код может быть намного сложнее, нам может потребоваться несколько ресурсов, а люди могут забыть вызвать close.

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

Чтобы использовать эту фичу, resource должен реализовать у себя поле Symbol.dispose или Symbol.asyncDispose (в этом случае нужно использовать async using), в котором как раз будет реализовано освобождение ресурса

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

Чем платформенные команды отличаются от продуктовых? Основное различие в определении пользователя. Для продуктовых команд пользователи - это внешние пользователи продукта. Для платформенных команд пользователи - это другие команды компании

Есть 3 стадии развития платформы:

• Миграция на платформу
• Использование платформы
• Эволюция платформы

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

• Завести задачу в продуктовую команду
• Внедрить инженера платформенной команды в продуктовую (чтобы он сделал изменения). Это называется Tour of Duty
• Сделать изменения самим. Тут есть 2 варианта - если продуктовая команда доверяет платформенной, то это паттерн Trusted Outsider и платформенная команда просто вносит изменения. Либо же продуктовая команда не доверяет внешним инженерам в достаточной мере и будет проверять, что они делают, тогда это Internal Open Source

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

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

Рано или поздно у продуктовых команд возникает потребность в изменении функциональности платформы. Это, как правило, горящие изменения т.к. продуктовая команда узнает о необходимых изменениях тогда, когда они ей уже нужны. В этом случае платформенная команда опять же заинтересована, чтобы продуктовая команда сама могла сделать все необходимые изменения (т.к. иначе процесс не масштабируется). Однако новые изменения внедрить может не так то просто, поэтому платформенная команда должна предоставлять подробные гайды и хороший DX для внедрения изменений, а также проводить консультации, рекомендовать пути решения задачи, ревьюить дизайн получившегося решения.

В общем, непросто быть платформенной командой - постоянно нужно думать о том, как лучше построить коммуникации с продуктовыми командами - одновременно следить за тем, чтобы коммуникации не требовалось, но предоставлять возможность активной коммуникации в отдельных случаях