Fedkin is thinking

С большинством людей все в порядке

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

Первая интерпретация проблемы обычно персональная, мол "какая безответственная команда". Но прямо-таки все одновременно такие безответственные?

——

На самом деле, люди обычно действуют рационально в рамках системы, в которой они существуют

И в такой картине мира дальше возникает вопрос — а почему система поощряет затягивание ревью?

Причина может быть очень простой — у разработчика есть две задачи: "закончить свою фичу" и "поревьюить фичу соседа". За срок своей фичи его спросят на дейли, если будет продалбываться — повлияет на perfomance review. А за скорость чужого кода скорее всего не спросят

А в такой системе откладывать ревью — совсем не безответственное поведение, а вполне рациональное для конкретного человека

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

——

Как в общем случае дебажить такие ситуации? Предлагаю такой алгоритм

1. Описать наблюдаемый паттерн, без оценок

За последний месяц 40% PR ждали первого ревью больше рабочего дня. Проблема возникает у большинства разработчиков

2. Описать поведение через устройство системы

Задаемся вопросом "Почему нормальному человеку выгодно себя вести именно так?"

Ответом будет гипотеза — например, система может сильнее вознаграждать завершение собственной задачи, чем скорость общего флоу команды

3. Провести эксперимент

Меняем предположительное свойство системы и смотрим что происходит

——

Поэтому когда в следующий раз покажется, что все люди какие-то странные, попробуй предположить, что люди действует рационально:)

Чему техлиду научиться у Tinder

На днях стало интересно, как запускаются сервисы с "сетевым" эффектом. И это навеяло интересные аналогии с работы...

Представьте запуск нового дейтинг-приложения: приложение готово, можно создать профиль, можно свайпать людей

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

Это и есть Cold start problem — проблема запуска продукта, ценность которого зависит от других участников. Через этот этап проходили все сервисы, которые держатся на участниках, типа аирбнб, тиндера, фейсбука и тд

——

В книжке The cold start problem разбирается такой запуск через 5 фаз, из которых нам интересны первые 3:

Фаза 1: Cold start

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

• Hard side — кто является дефицитным участником, создающим ценность для остальных?

• Hard problem — какую проблему надо решить, чтобы hard-side остались?

• Zeroes — как выглядит ситуация, когда обещанная ценность у пользователей не возникает?

• Magic moments — как выглядит ситуация, когда система реально работает и дает "вау эффект"?

У тиндера первым маленьким сообществом стал кампус University of Southern California. Hard side — привлекательные люди. Их hard problem состоял в том, что старый онлайн-дейтинг создавал слишком много нежелательного внимания. Тиндер это решает свайпами и метчами

Фаза 2: Tipping Point

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

Фаза 3: Escape Velocity

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

——

Поворот сюжета: представь, что ты техлид, который хочет внедрить clean architecture в подразделение разработки

Провел презентацию, всем рассказал какую это даст пользу и... ничего не поменялось. На самом деле, это и есть нечто похожее cold start problem

Люди не будут применять практику, пока вокруг неё нет примеров, инструментов и общего понимания. Но всё это не появится, пока люди не начнут её применять

И если попробовать это переложить на фазы выше:

Фаза 1: Cold start

Нужно, чтобы практика заработала внутри какого-то небольшого связного контура: одной команды / одного сервиса

• Hard side — активные разработчики, которые начнут применять практику и распространять ее другим

• Hard problem — конкретная боль, ради которой надо менять привычный способ работы. Например, что изменение бизнес-правила затрагивает кучу модулей

• Zeroes — разраб пытается применить подход, но не находит рабочих примеров

• Magic moment — "вау" эффект, когда практика облегчает работу. Фичу получается сделать быстро, изолированно и легко протестировать

Для техлида cold start пройден, когда любой разработчик внутри пилотной команды может применять и сопровождать практику без постоянной помощи от автора

Фаза 2: Tipping point

После того как получен опыт с пилотной командой нужно научиться распространять практику на следующую команду

Для техлида tipping point пройден, когда следующая команда внедряет практику быстрее первой и без полного повторения ручной работы

Фаза 3: Escape velocity

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

Больше участников → больше примеров, инструментов и экспертизы → дешевле следовать практике → проще подключать следующих участников

Для техлида escape velocity достигнута, когда новый разработчик осваивает практику через окружение: код вокруг, ревью, инструменты. Без отдельной помощи инициатора

——

И на самом деле, прогнав в голове опыт различных внедрений изменений, в основном они так и выглядели: перевезти узкий контур → научиться распространять на другие контуры → распространяется само

Пользуйтесь!

Почему рабочие встречи превращаются в балаган

— Раскатываем эксп на 100%?
— Я бы не раскатывал, у нас p95 ответа подрос на 100мс
— Да это наверняка из-за того что железа не хватает, мы заявку оставляли, нам так и не выдали
— Говорят пока не дадут, бюджеты зарезали
— Блин, а у нас в другом сервисе нагрузка на пределе уже, как мы без железа будем?
...

И дальше 20 минут обсуждали, как экономить железо. Разумеется, жди в календаре встречу "Надо ли раскатывать эксп pt.2"

——

Вероятно странная аналогия, но я любые рабочие обсуждения представляю как стек вопросов

1. Есть исходный вопрос
2. Появился новый — проверяем: помогает ли он решить текущий вопрос?
• Да — кладем на стек, обсуждаем, возвращаемся к предыдущему
• Нет — паркуем на будущее

Иными словами, в обсуждении всегда есть некоторая цепочка "активных" вопросов, где каждый должен помогать решить предыдущий

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

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

Перед автоматизацией выясни, существует ли процесс

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

• Разработка — проходит ли каждая задача один и тот же путь от постановки до прода?

• Саппорт — оператор действительно следует инструкциям из базы знаний или половина решений держится на опыте?

• Инциденты — порядок работы от возникновения инцидента до выполнения action items всегда один и тот же, или держится абы как на паре инициативных человек?

В противном случае становится невозможно сказать, какую именно часть процесса мы автоматизировали (и автоматизировали ли вообще), и как замерять качество этой автоматизации

Полезно понимать, какие проблемы решает твой руководитель

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

Думаю все слышали эту формулировку, но мало кто знает, что это за мифические задачи следующего уровня

На самом деле задачи следующего уровня часто находятся в зоне ответственности твоего руководителя: конфликтующие приоритеты, проекты между командами, технические риски, передача контекста, рост людей, предсказуемость результата

И при таком взгляде на вещи механика становится довольно простой:

Повышение обычно происходит, когда ты стабильно забираешь на себя часть проблем своего руководителя

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

А это и есть те вещи, которыми регулярно болят у твоего руководителя

Про проблемы тимлидов будем разгонять с ребятами из Стратоплана на завтрашнем интенсиве в 18:00 по мск. Можно будет послушать и потом обсудить со своим руководителем, что у него из этого болит:)

Все заняты, а продукт не двигается

— Миш, вижу у тебя десять задач по бэку, какой статус?
— Пять сделал, приступаю к шестой
— Круто!

— Лен, а у тебя как дела со фронтом?
— Я почти все сделала, но вот тут заблокировалась
— Давай пока заблочены, вот эту задачку еще возьмем
— Окей

А какие фичи дошли до прода? Да хрен знает:)

——

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

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

Бэкендер берёт следующую задачу, фронтендер — следующую. Количество одновременно начатых фич растёт, и по закону Литтла вместе с WIP растёт и Cycle Time

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

——

Вместо этого попробуйте ограничивать кол-во user story, которые одновременно в работе, и на дейликах смотреть именно на них

Например, в работе одновременно три user story. Проходимся по каждой из них и выясняем:
• что сейчас мешает довести фичу до пользака
• кто заблокирован
• кто может помочь
• какой следующий шаг

Таким образом меняется и смысл дейлика. Мы не пытаемся убедиться, что каждый чем-то занят. А вместо этого пытаемся понять, что нужно сделать команде, чтобы закончить начатое и с чистой совестью перейти к следующей user story

Примерно год назад меня позвали поучиться на одном из курсов Стратоплана (почитать можно тут), что мне неплохо помогло прокачаться в управленке и на тот момент сдвинуть мозги в нужное русло)

Сейчас ребята проводят курс-интенсив про четыре управленческие позиции: тимлид, рук. отдела, CTO, COO. В каждый из дней будет про то, как вкатиться в роль, какой основной инструментарий, и что делать в первые несколько месяцев после получения позиции

Я буду участвовать в тимлидском блоке — поразгоняем про топ факапов начинающего тимлида

Так что если вы либо планируете, либо только вкатились в новую роль, приходите послушать!

Регистрация (link) — бесплатная по подписке на каналы, но есть и платный вариант

Даты и время — 1–4 сентября, с 18:00 до 21:00 GMT+3

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

Если твоя постгря много весит, на то есть две причины:
1. Сам по себе датасет большой
2. Table bloating

... table bloating — это ситуация, когда физический размер таблицы существенно превосходит размер датасета. Это происходит из-за:

2.1. Накопления dead tuples
2.2 Фрагментации таблицы, когда текущих "дырок" не хватает для записи новых данных и приходится выделять новые страницы

——

Чисткой dead tuples занимается autovacuum, а как бороться с фрагментацией — сильно интереснее. Схематично она выглядит так:

page 1: [row][free][row][free]
page 2: [free][row][row][free]
page 3: [row][free][free][row]
...

То есть когда данные по страницам расположены не плотно, а разреженно.

Наша цель — освободить место, для этого нужно "уплотнить данные", чтобы они выглядели так:

page 1: [row][row][row][row]
page 2: [row][row][row][row]
page 3: [row][row][row][row]
...
page 999: [free][free][free][free]

В таком случае autovacuum сможет физически освободить место:

The standard form of VACUUM ... will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free

——

Как этого достичь?
1. vacuum full — долгая блокировка на таблицу и перезапись ее в новый файл. Требует даунтайма
2. pg_repack — копирует таблицу без блокировки, доливает дифф, под локом подменяет таблицы. Требует х2 диска от размера таблицы, генерирует burst IO нагрузку, держит долгую транзакцию
3. pgcompacttable

pgcompacttable построен на простой и красивой идее. Вспомним, что update в postgres создает новую версию строки, а старую помечает dead

На основе этой механики и работает pgcompacttable:

1. Он берет последние страницы:

page 1: [row][free][row][free]
page 2: [free][row][row][free]
...
→ page 998: [free][row][free][row]
→ page 999: [row][row][free][row]

2. Делает у строк с этих страниц фиктивный апдейт, который текущие версии пометит dead, а новые запишет в свободные дырки в начале таблицы:

page 1: [row][row][row][row]
page 2: [row][row][row][row]
...
→ page 998: [free][dead][free][dead]
→ page 999: [dead][dead][free][dead]

3. vacuum помечает dead tuples как свободные

page 1: [row][row][row][row]
page 2: [row][row][row][row]
...
→ page 998: [free][free][free][free]
→ page 999: [free][free][free][free]

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

И так далее для следующей пачки

Такой способ работает медленно, но
• не требует даунтайма
• не требует доп места на диске
• не генерирует burst нагрузки

Пользуйтесь!

upd: в комментах сделали хорошее дополнение
• по умолчанию pgcompacttable помимо того, что описано выше, начнет пересобирать индексы у таблицы, что уже потребует значительного свободного места. Чтобы индексы не трогать, нужно запускать с флажком --no-reindex
• чтобы vacuum физически освободил место от пустых страниц в конце таблицы, ему нужна будет короткая access exclusive блокировка

Меня так умиляет риторика "ллмный код не надо читать, достаточно почитать спеку! вы же машинный код компилятора не читаете"

Ну да, компилятор же тоже может удалить тебе тест, потому что "ну чето он не проходит, а надо чтобы все зеленое было"

Ну мы вроде договорились

— когда сделаете задачку?
— в четверг

... наступает четверг

— привет, доделали?
— да
— а где можно потыкать?
— ну мы код со своей стороны написали, передали в тестирование

Как бы это глупо ни выглядело, а ситуация реальная:) Даже слово "сделать" разные люди могут интерпретировать по разному. Поэтому если у тебя возникает подозрение, что тебя могли не так понять, переспроси то, как ты понимаешь договореннсть, только другими словами

— когда сделаете задачку?
— в четверг
— то есть в четверг будет на проде и сможем пользоваться?
— нууу, не совсем

... передоговариваются на другую дату

—

Это актуально примерно для любых взаимодействий:

• "хочу роста" — зарплаты? грейда? экспертизы? ответственности?

• "я перегружен" — не хватает времени? слишком много параллельных задач? постоянно дергают?

• "возьми эту задачку на себя" — написать код? организовать работу? отвечать за результат целиком?

• "всё согласовано" — все сказали да? или просто никто явно не возразил?

Пару месяцев назад я ходил на конфу Тинька, посвященную в основном GenAI в поддержке

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

—

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

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

Встает вопрос — как этот контекст собрать

—

Предлагается такой подход:

1. Берем нашу базу знаний

2. Ставим агента, который смотрит на поток обращений и ответов операторов. Этот агент пытается пруфануть ответ оператора какой-то инструкцией из БЗ

2.1. Пруфануть получилось => отлично, контекста хватает

2.2. Не получилось => оператор ответил на основе какого-то знания, которого нет в базе. Заводится задачка на бизнес-эксперта, мол было такое-то обращение и такой-то ответ, текущих инструкций из БЗ не хватает, нужно добавить новую

То есть собирается feedback-loop между потоком, агентом и бизнес-экспертом, который позволяет обогащать базу знаний, и привести ее к виду, где на каждое обращение можно ответить правилом/инструкцией из БЗ

—

К чему это я все?) Как будто похожий подход можно применить к разработке. Аналогии примерно такие:
• тикет в поддержку => тикет с задачкой
• ответ оператора => пулреквест с кодом
• база знаний операторов => дока к системе
• бизнес-эксперт => разработчик

То есть ставим агента, который проходится по задачкам и пулреквестам к ним, пытается запруфать, почему надо было сделать именно так на основе документации, получилось => отлично, не получилось => заводится таска на разработчика, что надо обогатить доку

Что думаете? Мб кто то уже пробовал похожее

Первый шаг к хорошей техностратегии

Команда упорно работала 3 месяца и подняла аптайм системы с 99.9% до 99.99%, перепилив архитектуру сервиса, из-за которого еженедельно падали на 10 минут. Молодцы конечно, а это точно кому-то было нужно?

Вполне может оказаться, что бизнесу было ок и с этим 10минутным даунтаймом и "ваще на че вы потратили 3 месяца???"

—

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

Поэтому главный вопрос — во что вкладываться. Мне нравится такой фреймворк (возможно у него даже есть название):
• Выписать все свойства, которые для твоей системы имеют значение
• Вместе с бизнесом отранжировать их
• Выделить топ 3 — туда вкладываемся. Остальным сознательно жертвуем

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

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

Продукт, тех и взаимопонимание

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

На помощь приходят хорошие практики типа ubiquitous language, event storming, user story mapping, ...

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

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

Последнее время активно применяю с командой, работает офигенно

ВАЖНО!!!
• прототип может быть немасштабируемым, несекьюрным, непроизводительным — это окей, его задача снять продуктовую неопределенность
• поэтому не забудь его выкинуть, и нормально продумать НФТ для целевого решения

У меня иногда возникает желание почитать что-то эдакое забористое про бэкенд

И если бы меня попросили порекомендовать что-то русскоязычное по теме, я бы порекомендовал канал Лёши Рыбака (многие из вас его знают по курсам по сисдизу devhands)

Леша делает классные разборы:
- PostgreSQL на 800млн пользователей от OpenAI — что с ним не так https://t.me/rybakalexey/402
- SPDY, QUIC, HTTP/2 и HTTP/3: кратко: https://t.me/rybakalexey/479
- Бенч-порн: HAProxy vs Angie: https://t.me/rybakalexey/289

И пишет про насущные темы без булшита:
- Фриз найма и что на рынке: https://t.me/rybakalexey/514
- Про «пузырь в AI» и «несерьезность» кодинга с агентами: https://t.me/rybakalexey/457
- Критика исследования Гарварда про AI https://t.me/rybakalexey/461

Рекомендую начать с первой статьи про постгрю. Мне всегда интересно, что под капотом у таких неконвенциональых решений типо постгри почти на лярд юзеров:)

Длиннопост про сон

50 реакций набрали оч быстро, поэтому ловите!

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

Поэтому по-хорошему сначала надо сходить к врачу и удостовериться, что у тебя с этим все норм

Далее речь про мой опыт. Показатели сна трекаю кольцом oura, неплохо отражает реальную картину

Низкое влияние

• Витамины
Магний, железо, D3 — эффекта не было, т.к. не было больших дефицитов

• Бады
l-теанин, глицин, ашваганда, валериана — легкий седативный эффект, но не сильно заметно

• Ложиться рано (23:00 или раньше)
Не мое, почти всю жизнь ложился в час или позже

• Тяжелое одеяло
Есть такие одеяла, которые весят по 10кг (перестилать постель тот еще ад). Прикольно, но эффекта не заметил

Среднее влияние

• Беруши
Помогало не просыпаться, когда в соседней квартире кто то просыпается раньше и начинает шуметь

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

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

• Прогулки перед сном
Влияет, но не сильно. Спишь чуть крепче

Высокое влияние

• Отказ от кофеина
Мой tier s. Кофе/энергосы выпитые даже до 12 дня на меня прям плохо влияют — спать начинает хотеться сильно позже, чем надо

• Алкоголь
В ночь после посиделок/тусовок сон ужасный, что по ощущениям, что по показателям

• Не думать про что то сложное ~за час до сна
И куда-то в заметки выписывать, если что-то крутится в голове. Тоже отлично влияет

• Раскатываться на валике
Помогает расслабить мышцы шеи, спины, ног. Оч помогает как засыпать, так и поддерживать сон

• Стабильное время подъема
Не обязательно супер рано, просто в одно и то же время. Это + факторы выше = начинаешь и засыпать в одно и то же время

• Дефицит калорий
Очень плохо влияет на сон. Помогало переносить бОльшую часть калорий ближе к вечеру и ужинать "медленными" белками и углеводами

—

Если суммаризировать, то что сейчас использую на постоянной основе:

• Вставать +- в одно и то же время
• Силовые нагрузки утром
• Отказ от кофеина
• Раскатываться на валике перед сном
• За час до сна не думать о чем-то сложном + выписывать мысли
• Блэкаут шторы

В выходные чуть продалбываюсь и позволяю себе лечь/встать попозже

Есть простая ловушка, в которую легко попасть, если тебе нравится твоя работа - начать слишком сильно в нее вкладываться и забивать на остальное

Пока всё получается - кайф, ты растешь, получаешь постоянное позитивное подкрепление, вкладываешься еще больше

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

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

—

Сам я дольше всего разбирался со сном: несколько лет спал по 5-6 часов урывками, сейчас 7-8 достаточно качественно

Накидаете 50 реакций - расскажу, что помогло, а что нет

Как чуть меньше страдать от нейрослопа

Или небольшой полезный тех, который ты можешь сделать за пару дней

Давеча я писал, что агенты без должного контекста о системе склонны к локально оптимальным решениям. Это часто приводят к:
• нарушению направления зависимостей в коде
• смешиванию доменной логики и инфраструктурной
• странному неймингу и расположению классов

Хорошая новость — многое из этого можно ловить детерминированными тестами

Есть прекрасные инструменты, как например ArchUnit для Java (если знаете похожие инструменты для других языков, пишите в комменты), которые позволяют писать декларативные тесты на архитектуру приложения:

Домен не должен зависеть от инфры:

noClasses()
    .that().resideInAPackage("..domain..")
    .should().dependOnClassesThat()
    .resideInAPackage("..infrastructure..");

In-порты называются ...UseCase

classes()
    .that().resideInAPackage("..port.in..")
    .should().haveSimpleNameEndingWith("UseCase");

Все порты должны быть интерфейсами:

classes()
    .that().resideInAnyPackage("..port.in..", "..port.out..")
    .should().beInterfaces();

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

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

p.s.: зачем эти детерминированные проверки, если я могу дать агенту правила в виде текста:
• промпты не дают гарантий
• не проверяют уже написанный код

Несколько избитая тема, но мне кажется очень красивой идея, которая стоит за structured output в современных ллмках

Задача — пользователь передает json-схему, нужно сгенерировать ответ строго по переданной схеме

1. Наивный вариант

Подложить схему в контекст:

...

Return a JSON object that strictly matches the following schema:
{
  "type": "object",
  "properties": {
    "status": {
      "enum": ["SUCCESS", "FAILED"]
    }
  },
  "required": ["status"],
  "additionalProperties": false
}

Будет ли работать? Да, в большинстве случаев. Но без каких либо гарантий, что схема в итоге будет корректная

2. Добавляется constrained decoding

LLM генерирует ответ токен за токеном, на каждом шаге строя распределение вероятностей:

"{" = 0.75 
"status" = 0.20
":" = 0.04
"answer" = 0.01

А дальше в процесс вмешивается constrained decoding

Из json-схемы строится контекстно-свободная грамматика (CFG), которая позволяет понять, какие продолжения ответа в текущий момент всё еще могут привести к валидному результату

Например, для схемы выше грамматика могла бы выглядеть как-то так:

root ::= "{" ws "\"status\"" ws ":" ws status ws "}" 

status ::= "\"SUCCESS\"" | "\"FAILED\""

И, согласно грамматике, инференс-движок накладывает маску на распределение вероятностей следующего токена

"{" = 0.75 
"status" = 0.20
":" = 0.04
"answer" = 0.01

Превращается в

"{" = 0.75 
"status" = 0
":" = 0
"answer" = 0

Сгенерили {

—

"status" = 0.6
":" = 0.3
"answer" = 0.1

Превращается в

"status" = 0.6
":" = 0
"answer" = 0

Сгенерили {"status"

... и так далее

—

С относительно небольшим оверхедом это позволяет генерить ответ, строго соответствующий схеме

Если ты слишком хорошо решаешь проблемы — возможно, ты решаешь не те

Пост по мотивам одного из худших полугодий на работе:)

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

• Команды не договорились — синхронизировать
• Сроки едут — заовертаймить
• Где-то возник затык — лично прийти разблокировать
...

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

Что делать — вы и без меня знаете: остановиться и позадавать себе вопросов
• А почему проблема дошла до меня?
• Почему глобально система допускает возникновение таких проблем?
• Что сделать, чтобы починить корневую причину таких проблем?

В условиях горящих сроков и давления такое бывает сделать правда сложно, но нужно сделать волевое усилие и "zoom-out"-нуться

Поэтому если ты N-ый раз решаешь одну и ту же проблему, подумай, ту ли проблему ты решаешь

Очень грубо инженеров можно классифицировать на два типа:

1. Те, кто работает с техническими проблемами проактивно:
• Увидел плавное повышение cpu usage на БД => раздебажил из-за чего, добавил нужных индексов, предотвратил инцидент
• Увидел, что новая функциональность в модуль добавляется очень странным образом => инициировал и довел до конца рефакторинг, благодаря этому крупный проект сошелся в срок
• Сделал удобные алерты, что позволило видеть проблему раньше пользователей и предотвращать инциденты

2. Те, кто работает с техническими проблемами реактивно:
• TTM фичей вырос в два раза, постоянные баги => только тогда начинаем рефакторинг
• Количество инцидентов стало совсем неприемлемым => только тогда инициируем проект по стабилизации

(да, не существует чистых типов 1 и 2, это всегда спектр, и всегда нужно уметь работать в обоих режимах)

Но в чем неприятный парадокс — признание за технический вклад в основном получают люди, работающие во втором режиме

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

Если же чинить проблемы проактивно, то со стороны может показаться, мол ничего особенного, все так и должно работать — фичи делаются быстро, система работает стабильно

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

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