Все публикации подряд на Хабре [expanded by feedex.net]

Почему Go-сервисы начинают тормозить без ошибок (и при чём тут goroutines). Часть 1

iik_812 — Mon, 27 Apr 2026 05:27:53 +0000

4 минуты назад

9 мин

Часто про Go говорят: «это язык, где конкурентность почти бесплатная».

И знаете что? Это правда. Почти.

Но «почти» — это самое опасное во всей истории, так как либо ты управляешь системой, либо она управляет тобой руками runtime'а.

В трёх статьях я разберу путь, через который проходит почти каждый Go-разработчик от наивного «я добавил go — получил параллельность», до взрослого «я проектирую concurrency-систему с понятными границами».

Погнали.

Иллюзия первая: «Горутины дешёвые — значит можно сколько угодно»

Новички в Go рассуждают примерно так:

Горутина весит 2 КБ стека. Поток — 1 МБ. Значит, я могу создать 500 000 горутин вместо 2000 потоков. Отлично, пишу go на каждый чих!

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

Ниже приведен совершенно классический код:

func handleRequest(req Request) {
    go processAsync(req)  // Эмитируем асинхронность
    respondOK()
}

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

лимита на количество одновременно работающих горутин
очереди
контроля завершения
backpressure'а

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

В метриках это выглядит примерно так:

Число горутин:      1000 → 10000 → 50000
Время ответа:       50ms → 200ms → 800ms
CPU:                30%  → 70%   → 95% (полезной работы — всё меньше)
Ошибки:             0    → 0     → 0

То есть формально наш сервис жив, но мёртв для пользователя.

Заглянем под капот

Планировщик Go (GMP-модель: Goroutines, Machine, Processor) начинает страдать:

G (горутины) — их слишком много, очередь runqueue растягивается
M (основные потоки ОС) — пытаются всё вывезти
P (процессоры логические) — мечутся между горутинами чаще, чем выполняют полезную работу

Если говорить простыми словами, то планировщик тратит больше времени на переключение между задачами, чем на выполнение самих задач, это как если бы вы меняли инструменты каждые 10 секунд вместо того, чтобы работать. Однако, здесь может быть использован паттерн worker pool + ограниченная очередь, варианты его реализации мы разберем в части 3. Код одной из реализаций приведу ниже:

type WorkerPool struct {
    tasks chan func()
}
func (p *WorkerPool) worker() {
    for task := range p.tasks {
        task()
    }
}
func NewWorkerPool(workers int, queueSize int) *WorkerPool {
    pool := &WorkerPool{
        tasks: make(chan func(), queueSize),
    }
    for i := 0; i < workers; i++ {
        go pool.worker()
    }
    return pool
}
func (p *WorkerPool) Submit(task func()) error {
    select {
    case p.tasks <- task:
        return nil
    default:
        return ErrQueueFull // backpressure — важнейшая вещь
    }
}

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

У нас есть канал tasks — это очередь задач. Туда мы будем складывать функции, которые нужно выполнить, далее создаём пул:

func (p *WorkerPool) worker() {
    for task := range p.tasks {
        task()
    }
}
func NewWorkerPool(workers int, queueSize int) *WorkerPool {
  pool := &WorkerPool{
    tasks: make(chan func(), queueSize),
  }
  for i := 0; i < workers; i++ {
    go pool.worker()
  }
  return pool
}

Что здесь происходит:

queueSize — это максимальный размер очереди
workers — сколько задач может выполняться одновременно

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

Теперь самое интересное — добавление задачи:

func (p *WorkerPool) Submit(task func()) error {
  select {
    case p.tasks <- task:
    return nil
    default:
    return ErrQueueFull
  }
}

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

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

Инцидент первый: «подождём секундочку »

Код ниже, ломает 50% наивных реализаций:

func main() {
    go doWork()
    time.Sleep(1 * time.Second)  // "Ну, за секунду точно успеет"
}

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

Почему под нагрузкой такой код даст сбой мгновенно? Это происходит из-за ряда причин:

doWork() начинает тормозить
1 секунды перестаёт хватать
горутины накапливаются
программа завершается до завершения работы

Формально код «рабочий». Но в реальности — это просто отложенный баг.

Правильное ожидание

func main() {
    done := make(chan struct{})
    go func() {
        defer close(done)
        doWork()
    }()
    <-done  // Ждём реального завершения
}

done := make(chan struct{})

Это обычный канал, который используется как сигнал: «работа закончилась»

Тип struct{} выбран не случайно — он ничего не занимает в памяти, а нам не нужно передавать данные, нам нужен сам факт.

Еще одна важная деталь — defer close(done) как только doWork() закончится (не важно — успешно или с ошибкой) канал будет закрыт и это наш сигнал наружу об окончании.

Как происходит ожидание

<-done

Здесь main-поток просто блокируется и ждёт и разблокируется он только в одном случае — когда канал закроют и это реальное ожидание, а не «подождём секунду и надеемся».

Мы больше не гадаем:

хватит ли времени
успеет ли задача
не зависла ли она

Чем это лучше time.Sleep

Sleep — это всегда предположение: «я думаю, этого времени хватит», а канал — это гарантия: «я точно знаю, что работа завершилась»

Можно также реализовать с контекстом (если работа может занять слишком много времени):

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
    defer cancel()
    done := make(chan struct{})
    go func() {
        defer close(done)
        doWork()
    }()
    select {
    case <-done:
        fmt.Println("успели")
    case <-ctx.Done():
        fmt.Println("не успели, но не утекли")
    }
}

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

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

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

Инцидент второй: нагрузка выросла в 2 раза — латенси улетела

Симптомы, знакомые многим, сервис наш работает корректно, ошибок нет, падений сервиса тоже нет, однако у нас растет время ответа сервиса 50ms → 800–1000ms CPU: 90–100%

Например такая схема, убивающая production:

func handleFanOut(req Request) {
    results := make(chan Result, len(req.SubTasks))
    for _, task := range req.SubTasks {
        go func(t Task) {          // Нет лимита! Каждый запрос плодит N горутин
            res := callExternalService(ctx,t)
            results <- res
        }(task)
    }
    for i := 0; i < len(req.SubTasks); i++ {
        <-results
    }
}

Переводя это в цифры:

1 запрос → 10 горутин
100 запросов → 1000 горутин
1000 запросов → 10 000 горутин (работает… пока работает)
2000 запросов → 20 000 горутин — всё падает

Причём падает не в момент, когда вы ожидаете, а когда планировщик говорит: «Ребята, я больше не могу.»

Диагностика и как это увидеть

Одним из вариантов запуск в консоли:

# Посмотреть число горутин
curl http://localhost:6060/debug/pprof/goroutine?debug=1
# Или через go tool
go tool pprof http://localhost:6060/debug/pprof/goroutine
# След планировщика — мастхэв
GODEBUG=schedtrace=1000 ./your-service

Вывод schedtrace:

SCHED 1005ms: gomaxprocs=8 idleprocs=0 threads=11 spinningthreads=1 idlethreads=0 runqueue=152 [3 2 1 0 0 0 0 0]

Ключевое на что нужно обратить внимание на runqueue=152 — это значит, что 152 горутины ждут выполнения, то есть наш планировщик захлёбывается.

Исправление

func handleFanOutControlled(ctx context.Context, req Request) error {
    sem := semaphore.NewWeighted(10) // максимум 10 одновременных вызовов
    var wg sync.WaitGroup
    for _, task := range req.SubTasks {
        wg.Add(1)
        go func(t Task) {
            defer wg.Done()
            if err := sem.Acquire(ctx, 1); err != nil {
                return
            }
            defer sem.Release(1)
            callExternalService(ctx,t)
        }(task)
    }
    done := make(chan struct{})
    go func() {
        wg.Wait()
        close(done)
    }()
    select {
    case <-done:
        return nil
    case <-ctx.Done():
        return ctx.Err()
    }
}

Мы начинаем контролировать параллелизм, а не количество запросов. Наша функция берет один запрос, разбивает его на подзадачи (SubTasks) и обрабатывает их параллельно, но тут есть важная оговорка: не более 10 задач и плюс есть нормальное завершение и таймаут через context

sem := semaphore.NewWeighted(10)

В любой момент времени можно выполнить не более 10 задач остальные будут ждать.

Внутри горутины - это будет работать так:

if err := sem.Acquire(ctx, 1); err != nil {
    return
}
defer sem.Release(1)

Acquire — «можно ли мне начать работу?»
если лимит достигнут → ждём
если context отменён → выходим

После завершенияRelease освобождает слот и следующая задача может начать выполняться. Мы не ограничиваем создание goroutines (они всё равно создаются), но ограничиваем реальный параллелизм выполнения. Это дешевле, чем бесконтрольный fan-out, но всё ещё может давать overhead при очень большом числе задач.

Ожидание задач проходит через классический механизм var wg sync.WaitGroup

wg.Add(1)
...
defer wg.Done()

Стоит подсветить важный нюанс: return ctx.Err() не останавливает автоматически горутины, они могут продолжать работать. Чтобы горутины реально останавливались, контекст должен прокидываться внутрь всех долгих операций (например: callExternalService(ctx, t)), иначе они продолжат выполняться даже после отмены.

Почему этот код — «правильный»

Потому что здесь есть всё, чего обычно не хватает:

1. Ограничение

Не больше 10 задач одновременно → система не захлёбывается

2. Ожидание

Мы реально знаем, когда всё закончилось

3. Таймаут

Мы не зависаем бесконечно

Инцидент третий: скрытая утечка горутин

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

func startWorker(jobs <-chan Job) {
    go func() {
        for job := range jobs {
            process(job)
        }
        // если канал не закроется — сюда никогда не попадём
    }()
}

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

Через неделю у нас 20k горутин, стек по 2-8 КБ каждая — уже ~100-150 МБ. Память растёт медленно и не бросается в глаза, потому что сами данные маленькие, но суммарно тысячи горутин начинают съедать десятки мегабайт, а вот планировщик Go начинает задыхаться. В pprof/goroutine мы увидим тысячи chan receive.

Правильное завершение

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

type Worker struct {
    jobs   chan int
    done   chan struct{}
    wg     sync.WaitGroup
}
func (w *Worker) Stop() {
    close(w.jobs)   // <- ключевой момент
    <-w.done        // ждём, пока worker закончит
}
func (w *Worker) Start() {
    w.wg.Add(1)
    go func() {
        defer w.wg.Done()
        defer close(w.done)
        for job := range w.jobs { // закроется, когда канал закроют
            process(job)
        }
    }()
}

Тут мы указываем явно два сигнала:

type Worker struct {
    jobs   chan int
    done   chan struct{}
    wg     sync.WaitGroup
}

jobs — откуда приходят задачи
done — сигнал, что воркер полностью завершился

for job := range w.jobs — это нормальный паттерн, но он работает корректно только, если канал когда-нибудь закроют. Как только jobs закрывается — цикл сам завершится после этого: вызывается wg.Done() закрывается done → внешний мир узнаёт: «воркер реально закончился»

Ну и конечно: close(w.jobs) — мы явно говорим: «новых задач больше не будет», воркер дочитывает всё, что уже было в канале и выходит из цикла, закрывает done мы дожидаемся этого через <-w.done

Ну и конечно, перед тем как написать go func() — нужн задать себе два вопроса: Кто и когда закроет её канал? и Что произойдёт, если этого не случится?

Если не знаем ответа — закладываем явный context с таймаутом или канал stop с select.

Инцидент четвёртый: внешний сервис начал тормозить, и мы упали вместе с ним

Код из разряда «работает годами, а потом бац»:

func fetchData(url string) (*Response, error) {
    resp, err := http.Get(url)  // А что, если 30 секунд?
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    return parse(resp)
}

Представим вполне обычную ситуацию: внешний сервис, к которому мы обращаемся, внезапно начинает подвисать, то есть вместо ответа 50мс получаем - 20-40 секунд. А следом за ним и у нас начинает деградировать сервис: наши запрос не падают, они просто висят.

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

Самое неприятное — это не выглядит как авария. Нет красных алертов «всё умерло». Есть тихая деградация, которая разъедает систему.

И тут вступает в действие Железное правило

Любой вызов внешнего сервиса должен иметь таймаут. Даже если он «локальный». Даже если «99.99% времени отвечает за 5 мс».

func fetchDataSafe(url string) (*Response, error) {
    ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
    defer cancel()
    req, err := http.NewRequestWithContext(ctx, "GET", url, nil)
    if err != nil {
        return nil, err
    }
    client := &http.Client{
        Timeout: 2 * time.Second,  // второй круг защиты
    }
    resp, err := client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    return parse(resp)
}

Два таймаута — не паранойя - это production. И если context ограничивает время жизни запроса, то http.Client.Timeout страхует на уровне клиента. Если один слой не сработал — сработает второй.

Как увидеть проблемы до того, как они увидят вас

1. Обязательные метрики

import "github.com/prometheus/client_golang/prometheus"
var (
    goroutines = prometheus.NewGaugeFunc(
        prometheus.GaugeOpts{Name: "go_goroutines_current"},
        func() float64 { return float64(runtime.NumGoroutine()) },
    )
    // И это обязательно
    scheduleLatency = prometheus.NewHistogram(...)
)

runtime.NumGoroutine() — это вообще одна из самых недооценённых метрик. В нормальной системе она ведёт себя примерно так: под нагрузкой выросла потом, вернулась обратно, но если она растёт и не падает, то это почти всегда сигнал, что что-то пошло не так.

scheduleLatency — ещё более продвинутая штука, если она начинает расти, то планировщик уже не справляется.

2. Профилирование в тестах

func TestNoGoroutineLeak(t *testing.T) {
    before := runtime.NumGoroutine()
    // ваш код
    time.Sleep(time.Second) // даём завершиться
    after := runtime.NumGoroutine()
    if after > before {
        t.Errorf("утечка: было %d, стало %d", before, after)
    }
}

Да, это не идеальный тест, это база и он может давать шум, но как ранний сигнал — работает отлично.

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

3. pprof в каждом сервисе

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

import _ "net/http/pprof"
go func() {
    log.Println(http.ListenAndServe("localhost:6060", nil))
}()

На практике открываем /debug/pprof/goroutine и видим, где реально зависли горутины, так нам за 2 минуты понятна причина, вместо того чтобы часами гадать.

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

gerpo: repository pattern для Go через указатели, без struct tags и кодогенерации

Insei — Mon, 27 Apr 2026 05:15:20 +0000

16 минут назад

4 мин

Я пять лет писал на .NET, и там у меня сложилась привычка держать доменную модель отдельно от инфраструктуры хранения. Repository pattern — не как догма из книги Фаулера, а как рабочий способ не тащить DbContext, маппинги и названия колонок в сущности. Домен остаётся доменом. Когда я перешёл на Go, меня сразу царапнули struct tags. Большинство библиотек работы с БД ожидает примерно такое:

type User struct {
    ID    uuid.UUID `db:"id"`
    Email string    `db:"email"`
    Age   int       `db:"age"`
}

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

Готового решения под такую постановку я не нашёл. Поэтому написал своё — gerpo. Это проект из моих потребностей и вкусов. Я не претендую, что он лучше существующих инструментов, я просто его сделал для себя и решил им поделится, 20 апреля 2026 года вышла версия 1.0.0, и я решил, что пора рассказать про неё публично. Я разрабатывал её довольно долго, с 2024 года - редко и потихоньку, но нашел силы довести до v1.0.0.

Парочка примеров, как это выглядит

Конфигурация репозитория под модель User.

type User struct {
    ID        uuid.UUID
    Email     *string
    Age       int
    CreatedAt time.Time
}
repo, err := gerpo.New[User]().
    Adapter(pgx5.NewPoolAdapter(pool)).
    Table("users").
    Columns(func(m *User, c *gerpo.ColumnBuilder[User]) {
        c.Field(&m.ID).OmitOnUpdate()
        c.Field(&m.Email)
        c.Field(&m.Age)
        c.Field(&m.CreatedAt).OmitOnUpdate()
    }).
    Build()

Никаких тегов в структуре. Никакого go generate. Модель остаётся чистой: четыре поля, четыре типа, ничего лишнего. Всё знание про то, как User кладётся в таблицу users, лежит в одном Columns(…)-блоке.

Запрос на выборку:

adults, _ := repo.GetList(ctx, func(m *User, h query.GetListHelper[User]) {
    h.Where().Field(&m.Age).GTE(18)
    h.OrderBy().Field(&m.CreatedAt).DESC()
    h.Page(1).Size(20)
})

Снова те же &m.Age, &m.CreatedAt. Это не переменные и не лямбда-выражения из C#; это буквальные указатели на поля структуры, полученные через &. Вся магия в том, что gerpo умеет сопоставить такой указатель с колонкой, которую вы сконфигурировали при сборке репозитория.
P.S. Ну вы понимаете откуда и почему такой стиль и способ - корни видны :)

Центральная идея — field pointers

На этапе Build() gerpo один раз обходит структуру User и запоминает смещение каждого поля через unsafe.Offsetof. Когда потом в запросе приходит &m.Age, gerpo смотрит на смещение и находит ту самую колонку, которую вы привязали к полю в Columns(…). Это не reflection на каждый запрос — на горячем пути идёт только указательная арифметика.Я специально не буду в этой статье копаться в том, как устроен внутренний модуль fmap, как работает unsafe.Offsetof на разных Go-версиях, как обеспечена безопасность при pointer receiver. Это отдельная история, и она потянет на вторую статью. Здесь важно одно: указатель на поле — первоклассный объект в API gerpo. Им идентифицируют колонку в Columns, в Where, в OrderBy, в Only/Exclude. Один и тот же лексический элемент — &m.X — везде означает одно и то же. Нет переключения между "строковым именем колонки" и "именем поля" — это теперь одно целое.

Что это даёт на практике

Компилятор ловит удаление поля. Если я уберу Age из User, все строки с &m.Age перестанут компилироваться. Для struct-tag-библиотеки это ошибка рантайма, вы должны пройти все места sql генерации у удалить эту колонку и там, и если что-то забыто - всё просто перестанет работать где-то после деплоя.

Линтер ловит смену типа. Если я поменяю Age int на Age string, тип указателя &m.Age меняется. Дальше помогает gerpolint — статический анализатор, который я написал специально для этого: он ловит Field(&m.Age).EQ("18"), когда поле int, и Field(&m.Age).Contains("x"), когда Contains применяется к нестроковому полю, и пр. кейсы, выдавая ожидаемые ошибки. Компилятор сам такой вызов пропустит, потому что EQ принимает any. Линтер — нет. Да это известное ограничение Generics в Go. Я решил обойти его тулингом линтера.

Нет тегов, нет кодогенерации. Структура чистая, go generate не нужен. IDE-рефакторинг переименования работает штатно, потому что &m.Age — обычная Go-ссылка на поле.И здесь я обязан честно сказать про компромиссом с которым придется считаться, но и на этот условий тоже найдется фикс:

Переименование поля меняет имя колонки. По умолчанию gerpo берёт snake_case от имени Go-поля. Если вы переименуете Age в YearsOld, колонка в запросе станет years_old. Это поведение convention over configuration: удобное, но ловушка, если вы переименовываете поле и миграция не переименовала колонку в БД. Компилятор здесь молчит.Для стабильности есть явное имя:
c.Field(&m.Age).WithColumnName("age")

Я держусь такого правила: для production-таблиц всегда ставлю .WithColumnName(...). В учебных примерах и в examples/todo-api/ полагаюсь на конвенцию — там переименование структуры и колонки должны идти синхронно, и это упрощает чтение. Выбор — ваш. Но тезис "рефакторинг полностью безопасен" — неправда, есть ложка дегтя в бочке с мёдом.

Важные ограничения

SQL, который gerpo на выходе генерирует, — PostgreSQL-шейп: плейсхолдеры $1, RETURNING, оконные функции, CAST(? AS text) в LIKE. Версия 1.0 поддерживает только PostgreSQL (и PG-совместимые базы — CockroachDB и подобные — "drop-in", без формального тестирования). Multi-dialect — в бэклоге.

Инфраструктурный оверхед над чистым pgx. На реальном PostgreSQL gerpo добавляет порядка 8% latency и около x2 аллокаций. В абсолютных числах — одна микросекунда на операцию, при запросе, который идёт 50–500 µс через сеть, это 0.2–2%. На горячих путях с сотнями тысяч RPS, где каждая аллокация критична, чистый pgx будет предпочтительнее. В умеренных нагрузках разница в шуме.

Что дальше

Первая публичная версия gerpo стабильна, с документацией и runnable-примером. Дальше я планирую несколько статей написать, если будет интересно:

Deep dive в fmap. Как на самом деле устроен механизм field pointers, почему unsafe.Offsetof безопасен в том контексте, в котором gerpo его использует, что происходит при embedded-полях и указателях.
gerpolint. Статический анализатор для WHERE-фильтров уже доступен как отдельный бинарь и как плагин к golangci-lint v2. Как он устроен, какие правила (GPL001–GPL006) реализует, как подключить в CI.

Ссылки для тех, кто захочет пощупать:

Если у вас есть вопросы, кейсы, где gerpo упадёт, или замечания к API — я читаю issues и благодарен за любой фидбек.

Служишь Jira? Понятно

octav47 — Mon, 27 Apr 2026 05:09:16 +0000

22 минуты назад

2 мин

Вступление

Замечаю, что часто люди подстраиваются под инструменты для работы, а не наоборот: процессы и поведение в целом деформируется под ограничения и логику треккеров и других методологических инструментов

Хотел бы в свободной форме порассуждать в статье о том, почему так происходит, и что с этим делать

Что происходит?

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

Если инструмент делает что-то сложным — люди перестают это делать, даже если это важно. Если делает что-то лёгким — делают это чаще, даже если это не нужно

Привычка подменяет целесообразность. "Мы так делаем, потому что так работает наша система" — это становится достаточным обоснованием

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

Ритуалы обслуживания инструмента становятся самоцелью — обновление статусов, заполнение полей, ведение отчётов — работа ради работы

Метрики определяются не тем, что важно, а тем, что инструмент умеет считать. Измеримое побеждает значимое

Почему так происходит?

Адаптироваться к инструменту проще, чем настраивать инструмент под себя — это раз

Инструменты предлагают готовую модель мира — легче принять чужую модель, чем строить свою — это два

Когда команда адаптировалась — отклонение от "инструментальной нормы" воспринимается как отклонение от командной нормы — это три

На мой взгляд это основные, но не единственные причины

Что с этим делать?

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

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

В-третьих, не путать "работу в инструменте" с "работой". Двигать карточки по доске — не работа. Заполненный отчёт — это не результат сам по себе. Если команда тратит ощутимую часть времени на обслуживание инструмента — что-то пошло не так

И последнее — выработайте в команде принципы, которым все будут придерживаться. Инструменты меняются, практики адаптируются, принципы остаются. Если команда не может сформулировать свои принципы отдельно от названия инструмента (jira, youtrack etc) — она уже подчинена ему

Облава на инсайдеров с Polymarket, а также уход Тима Кука на почетную пенсию

RationalAnswer — Mon, 27 Apr 2026 05:01:07 +0000

30 минут назад

7 мин

Дайджест

Самые интересные новости финансов и технологий в России и мире за неделю: ЦБ снизил ставку до 14,5%, Швеция не верит в 6% инфляцию в РФ, очередное покушение на Трампа, xAI Илона Маска не умеет правильно использовать видюхи, а также массовые сокращения у Цукерберга.

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

🐌 На того самого чела, который заработал $400к на ставках про арест Мадуро, американская прокуратура завела уголовку. Вопреки ожиданиям, это оказался не сын Трампа, а один из спецназовцев, принимавших участие в спецоперации – теперь ему может грозить 20 лет тюрьмы. Кстати чел очень глупо попался: зарегистрировал аккаунт на Полимаркете на свою электронную почту (я писал вот здесь, почему так делать не стоит).

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

🐌 В Твиттере, тем временем, все угорают над тем, что по всем признакам главными любителями побаловаться инсайдами на фондовом рынке являются кореша и приближенные президента США – но показательно арестовали в итоге только какого-то низового солдатика. Хотя, справедливости ради, в Нью-Йорке на этой неделе сотрудникам правительства официально запретили инсайдер-трейдить на рынках предсказаний.

🐌 Polymarket прогрели на $34к. Один чувак сделал несколько крайне маловероятных ставок на максимальную температуру в самый жаркий день недели в Париже. А так как источником данных для этого пари является один-единственный датчик «Meteo France» в местном аэропорту, челу пришла гениальная идея каждый день просто разогревать датчик с помощью фена. Итог – ставочки зашли, «прогрев рынка» прошел успешно, а темщика теперь ищет полиция Франции.

Как шутят в Твиттере, «похоже, невидимая рука рынка держит фен»

🐌 Polymarket и Kalshi запустят бессрочные фьючерсы на курсы криптовалют. Polymarket заанонсил новый функционал прямо у себя в Твиттере вместе с интерфейсом фьючерсов. Про старт такого же проекта у Kalshi говорят инсайдеры The Information. Это жирнейший кусок рынка, интересно – получится ли у этих площадок отжать долю у традиционных игроков, типа Hyperliquid?

Россия: Споры вокруг инфляции

🐌 ЦБ ожидаемо снизил ставку на полпункта до 14,5% – это уже восьмое снижение подряд с июня 2025 года. В пресс-релизе Центробанка раздали немного аналитики по состоянию российской экономики: в падении ВВП в начале года в том числе виновато повышение налогов, а также пишут о риске ускорения роста цен из-за войны на Ближнем Востоке, роста зарплат быстрее производительности труда, и высоких расходов при дефиците бюджета.

Это цитата из официальной прессухи, если что. Эльвира Сахипзадовна, вы такими тейками народ по поводу победы над инфляцией не сильно успокаиваете, если честно!!

🐌 Глубокая аналитика подъехала откуда не ждали: разведка Швеции заинтересовалась инфляцией в России. Глава ведомства заявил, дескать, реальная инфляция в РФ на самом деле болтается где-то под 15% годовых (близко к ключевой ставке), а наш ЦБ искусственно улучшает стату, заявляя лишь о 6%. Все конспирологи из секты «заниженной в три раза инфляции» (это, кстати, не только российская тема – таких в каждой стране полно) ликуют, но со шведскими тезисами согласны далеко не все.

🐌 Рубрика «Новые налоги и сборы»: на этот раз под раздачу попали продавцы электроники. Минпромторг определил размер технологического сбора с иностранных смартфонов и ноутбуков на уровне 250 и 500 руб. Всё во имя поддержки отечественного производителя.

🐌 Ну и наконец: Евросоюз релизнул новый пакет санкций против России. Из интересного: там почикали Челябинвестбанк – который был известен тем, что оставался одним из немногих российских банков, позволяющих нормально принимать валюту из Interactive Brokers. А ребята из OhMySwift еще добавляют, что для жителей Евросоюза использование белорусских криптобирж теперь забанено. Забавно, что эту самую «Цифру» (которая была одним из основных каналов беспроблемного вывода рублей из РФ через крипту) практически одновременно запрещают в ЕС, и собираются прикрыть с другой стороны тоже – в новом российском крипторегулировании.

Новое покушение на Трампа

🐌 Дональд Трамп пришел на ужин с корреспондентами Белого Дома, и туда же пытался прорваться чел с дробовиками, пистолетами и ножами (правда, безуспешно – его задержали еще на подступах). Нападавшим оказался Коул Томас Аллен, 31-летний школьный учитель из Калифорнии. В прошлый раз перед выборами, кстати, на Трампа покушался чувак по имени Томас Крукс. Что все Томасы имеют против Трампа??

К слову, у чувака была награда «учитель месяца». Иногда складывается впечатление, что все новости в США делятся на два типа: «ученик школы пришел куда-то со стволом» и «школьный учитель пришел куда-то со стволом»

Чё там в Иране

🐌 Продолжаем мониторить ситуацию на Ближнем Востоке: Дональд Трамп в одностороннем порядке объявил о продолжении перемирия с Ираном на неопределенный срок, но вообще – никакой долгосрочной сделки на горизонте пока не видно. По сути, иранская сторона особо не горит желанием даже пытаться вести переговоры в том формате, которого хочется Трампу.

🐌 По самому Ормузскому проливу всё стабильно: Иран продолжает обстреливать танкеры, а Штаты поддерживать ответную блокаду против иранских и заплативших пошлину Ирану кораблей. Тем временем, всей ситуацией вдохновились мошенники: неизвестные под видом иранской стороны предлагают судоходным компаниям заплатить в крипте «за безопасный проход через пролив», а потом таких бедолаг обстреливают на локации уже настоящие иранцы.

🐌 Кстати, Tether тут на днях забанил пару кошельков на Троне с рекордными $344 млн в USDT. И чуть позже США официально заявили, что это на самом деле такая спецоперация Economic Fury, а кошельки принадлежали иранскому режиму. У меня один вопрос: иранцы, вы чё, серьезно в этой ситуации юзаете централизованные стейблкоины, а не шифропанковский биткоин? Вы там вообще нормальные? 🤔

🐌 И еще на этой неделе WSJ сообщила об экономических переговорах между США и ОАЭ. Эмираты сильно недовольны всей движухой в регионе и требуют от Штатов хотя бы финансовой подстраховки (в виде открытой линии предоставления долларовой ликвидности) на случай, если всё это дело затянется и у арабов начнется дефицит баксов. В случае провала переговоров, намекают, что могут в кризисной ситуации даже начать торговать нефтью за юани.

Тим Кук покидает свою джобс

🐌 В понедельник Apple объявили, что 1 сентября этого года Тим Кук перейдёт с поста главы корпорации на должность исполнительного председателя совета директоров, где будет заниматься международными связями. Интересный факт: за период нахождения в должности CEO (2011–2026) Тим Кук смог увеличить капитализацию компании с $0,35 трлн до нынешних $4,0 трлн.

Кстати, недавно Bloomberg слили внутренний созвон Apple, где Тим Кук назвал свои главные ошибки на посту CEO: Apple Car, AirPower (зарядный коврик для айфона), а также Apple Maps. По картам прошелся особенно жестко: продукт был сырой и тестился чуть ли не на одних сотрудниках и на окрестностях Купертино.

Новым CEO станет 50-летний Джон Тернус. В Apple он занимался разработкой всяких железок: ИИ-очками, умным кулоном с камерой, домашней робототехникой и прочее прочее. Чуть подробнее про него см. в канале «Радиорубка Лихачёва».

LinkedIn-профиль Тернуса. Это что же, получается, тезис «чтобы найти хорошую работу в IT, важно иметь правильно оформленный и прокачанный профиль на LinkedIn» всё это время был одной большой ложью??

Новости AI: Нейропроблемы Маска

🐌 Весной выяснилось, что показатель утилизации мощностей GPU при обучении моделей у xAI Илона Маска составляет всего 11%, а у конкурентов он находится на уровне 35–45%. Это значит, что на обучение модели Икс приходится тратить в 3 раза больше времени при прочих равных. Дошло до того, что они свои мощности начали сдавать в аренду чувакам из Cursor, которые используют их эффективнее.

Твое лицо, когда накупил дорогущих видеокарт, а рукожопы-инженеры используют их всего на 11%

Так вот, продолжение такое: SpaceX, в которую теперь входит xAI, заключила сделку о праве приобретения Cursor за некислые $60 млрд. Сейчас компании вместе работают над эффективной нейронкой для вайб-кодинга. Если Маска устроит результат, то до конца года покупку завершат, а если решат отказаться от слияния, то придется за выход из сделки заплатить штрафные $10 млрд.

🐌 OpenAI выпустили ChatGPT Images 2.0. Улучшенную версию того самого генератора, который был виновен в гиблификации мирового инета. OpenAI нейронку сейчас рекламят, по большей части, через то, что модель научилась исправно ладить с генерацией текста на картинках (причем не только на английском), а также еще точнее следовать инструкциям. Возможно, эпоха всратых мемных нейроазбук на разные темы уйдет в прошлое – т.к. современные модели уже способны нагенерить что-то внятное.

Попросил вот ЧатГПТ сделать мне азбуку финансистов – даже никакой очевидной лажи навскидку не видно (ну, разве что, вместо Когана на картинку какой-то Гуриев прокрался)

🐌 Anthropic объяснила, почему у Claude Code в последнее время просело качество кода. Оказалось, что внутри случайно поменяли настройки «глубины размышления», еще был баг, который удалял часть размышлений модели в старых сессиях, а также разрабы попросили нейронку писать короче – из-за этого она стала хуже соображать. Вместе с выходом отчёта пользователям сбросили лимиты и пообещали больше так не лажать (в целом – похвально, что они вообще такой подробный пост-мортем разбор опубликовали).

🐌 Экстремистская Meta сокращает 10% своих работяг, затронет примерно 8 тысяч человек. Причина простая: корпорация тратит очень много денег на ИИ, надо теперь где-то экономить! Кстати, помимо Цукерберга пытаться массово избавляться от сотрудников на этой неделе стала Microsoft: она направила нескольким тысячам работников письма с просьбой выйти на пенсию досрочно.

Новости крипты: Взлом Kelp/Aave

🐌 Еще в конце позапрошлой недели произошел крупный хак в DeFi-сообществе на ~$200 млн – была затронута в том числе крупнейшая платформа для DeFi-лендинга под названием Aave. Подробнее про всю эту историю я написал у себя на канале, а сейчас давайте про то, чем всё завершилось: участники эко-системы DeFi решили скинуться на покрытие образовавшейся дырки, сейчас она уже закрыта практически полностью (но осадочек остался, ну и все голосования участников протоколов должны состояться еще).

Там кажется скинулись практически все, кто мог, – но немного иронично, что взносы от проштрафившихся пацанов из KelpDAO / Layer Zero (которых изначально и ломанули) не самые крупные

🐌 Журнал Le Monde выпустил статью с интересной статистикой: в настоящий момент во Франции предъявлены обвинения 88 людям (из них 10 несовершеннолетних) по делам, связанным с похищениями криптанов ради выкупа; а всего таких инцидентов за последние три года было больше 130. Написал у себя на канале про то, как всё это связано с грядущим созданием «реестра криптанов» в РФ (который должен начать действовать с июля 2026-го).

Интервью недели: Лудоман здорового человека

В этой рубрике я обычно рассказываю об одном подкасте, который я послушал на прошлой неделе. На этот раз это свежее интервью успешного (анонимного) Polymarket-трейдера gopfan2 на канале Евгения Фельдмана. Это на самом деле математик из России – он рассказывает про особенности рынка предсказаний и про то, как он там заработал больше $1,5 млн за последние несколько лет. Завтра еще выложу у себя в ТГ разбор самых интересных моментов из интервью.

Хорошая новость недели

В Японии начался сезон цветения голубой немофилы. Красиво!

Бонусные посты недели из моих ТГ-каналов:

🐌 Взлом Kelp/Aave, или почему я не инвестирую в DeFi.

🐌 Чем рынки предсказаний лучше фондового рынка (я там уже перевалил за $2000+ прибыли).

🐌 Разбор тревожной ситуации с криптанами во Франции (и что в этой связи ожидать в скором будущем в России).

🐌 Как работают законы США против инсайдерской торговли: там всё немного не так, как многие думают.

🐌 Мини-разбор реф-программы Interactive Brokers.

SDD на масштабе FullStack-приложения: 17 спринтов, две конституции, три чата

zahaand — Mon, 27 Apr 2026 05:00:14 +0000

31 минуту назад

11 мин

В первой статье я писал про SDD за один вечер — Telegram-бот, шесть команд Spec Kit, восемь часов от первого speckit.constitution до рабочего MVP. Это была проверка методологии на маленькой задаче.

С тех пор я прошёл 17 спринтов SDD на FullStack-приложении: B2C-трекер привычек и целей, два репозитория (backend и frontend), 251 тест на бэке и 77 на фронте, релиз в продакшен. Это уже не вечер — это полный цикл разработки FullStack-приложения по одной методологии.

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

Что построено за 17 спринтов

Чтобы дальше говорить о методологии — короткий контекст того, что под ней.

LifeSync — пет-проект, B2C-трекер привычек и целей. Backend на Spring Boot 3.5 + Java 21, Hexagonal Architecture на 6 Maven-модулях, jOOQ вместо JPA, Apache Kafka с шестью независимыми консьюмерами и идемпотентностью через таблицу processed_events, JWT RS256 с ротацией refresh-токенов, OpenAPI 3.1 как источник правды для API. Frontend на React 19 + TypeScript 5.9, Vite 8, Tanstack React Query, Zustand, shadcn/ui + Tailwind CSS, тёмная тема, двуязычный интерфейс через react-i18next, мобильная адаптация до 375px.

В цифрах:

17 спринтов SDD — 7 на backend, 10 на frontend.
Два репозитория — lifesync-backend (v1.0.2) и lifesync-frontend (v1.3.0). Деплой: backend на Railway, frontend на Vercel.
149 000 слов спецификаций. На backend — около 61 000 слов на 6 фич (где третий спринт прошёл без SDD-артефактов), на frontend — около 89 000 слов на 10 фич. Это не считая constitution.md обоих репозиториев и кода как такового.
251 тест на backend (170 unit + 81 integration на Testcontainers с PostgreSQL и Kafka) и 77 на frontend (55 unit на Vitest + 22 E2E на Playwright).
19 Liquibase-миграций, JaCoCo подключён.
Релиз в продакшен — backend на Railway (без Kafka в demo-окружении ради бесплатного тира), frontend на Vercel: lifesync-frontend-ten.vercel.app.

Дальше — про то, что не дало этому всему разъехаться.

Опора 1. Три чата вместо двух

В первой статье я зафиксировал схему «два чата»: отдельный чат с Claude — для думания (обсуждение архитектурных решений, подготовка промтов), Claude Code в терминале IDE — для исполнения (генерация спек, написание кода, запуск команд).

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

В итоге сложилась схема «три чата», не считая Claude Code в терминале IDE — он по-прежнему остаётся исполнителем в каждом репозитории:

Думающий чат для backend. Здесь живёт всё, что касается серверной части: Hexagonal-структура, Kafka-консьюмеры, JWT, jOOQ-запросы. Контекст этого чата — lifesync-backend/constitution.md + OpenAPI-спецификация + актуальная фича в работе.
Думающий чат для frontend. Сюда уходят React, TypeScript, React Query, shadcn/ui, темизация, i18n. Контекст — lifesync-frontend/constitution.md + ссылки на backend-репо и Swagger UI, чтобы я мог обращаться к актуальному API-контракту.
Третий, координационный чат. Для тем, которые касаются обоих репозиториев одновременно: деплой (Railway + Vercel + переменные окружения), кросс-репо фичи (например, сложная серверная валидация пароля с зеркальной клиентской), ретроспективы. В этом чате я готовил промты для двух других чатов, чтобы решения по общим фичам были согласованы.

То есть концепция «два чата на проект» из первой статьи сохраняется — думающий чат плюс Claude Code в терминале. Просто к ним добавился координационный, общий для двух репозиториев. Итого пять рабочих контекстов: думающий + Claude Code на backend, то же на frontend, и координационный на двоих.

Когда я открывал второй чат для frontend, я переносил в него контекст backend через явные промты: ссылку на репозиторий, ссылку на Swagger UI, файл OpenAPI-спецификации, краткое описание архитектуры. Это работает как информационный мостик — frontend-чат получает не «общую идею», а конкретные точки опоры.

Что важно про этот мостик: он однонаправленный. Backend-чат не получает обратной связи от frontend-чата автоматически — если в процессе разработки UI я обнаруживал несоответствие в API, я возвращался в координационный чат, прорабатывал там, и оттуда уже шёл новый промт в backend-чат. Это медленнее, чем «один чат на всё», но это и есть та структура, которая не даёт двум стекам перепутаться.

Третий чат — это не просто удобство. Это разделение зон ответственности на уровне ИИ-собеседника. Когда вопрос конкретно про backend — backend-чат уже в контексте, не надо его поднимать с нуля. Когда вопрос про деплой — координационный чат знает обе стороны.

Опора 2. Две конституции, живущие по-разному

Конституция в SDD — это .specify/memory/constitution.md, документ-договор между мной и проектом: какие архитектурные принципы соблюдаются, какие технологии в стеке, какие правила разработки. Spec Kit генерирует на её основе подсказки для всех остальных команд: speckit.specify, speckit.plan, speckit.tasks опираются на конституцию, чтобы не предлагать решения, противоречащие зафиксированным правилам.

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

Backend constitution. Стартовая ратификация — пустой шаблон в первый день проекта, затем версия 1.1.0 с полным набором принципов. Дальше — 12 правок, документ вырос от 50 строк до 437. Что добавлялось:

v1.2.0 — стандарт работы с Liquibase (формат миграций, нумерация, структура changelog).
v1.2.1 — правила атомарных коммитов.
v1.2.2 — порядок code style правил.
v1.2.4 — naming convention для веток.
v1.3.0 — стандарт документирования OpenAPI как двенадцатый принцип.
v1.3.1, v1.3.2 — execution rules: как именно интерпретировать tasks.md при имплементации.

После Sprint 5 (Kafka) constitution.md backend больше не правился. Это не значит, что он умер — это значит, что в раннюю фазу я зафиксировал все правила, которые регулируют дальнейшую разработку. Когда правила работают, документ перестаёт расти. Это и есть здоровое состояние.

Frontend constitution. Стартовая версия — 50 строк, затем ратификация 1.0.0 со всеми пятью принципами (API-Layer Isolation, Server State via React Query, Component-Logic Separation, Type Safety NON-NEGOTIABLE, Design System Fidelity). Дальше — всего 4 коммита. Финальный размер — 137 строк.

Эволюция точечная: смена React Router v6 → v7 в Technology Constraints, позже — расширение под i18n с добавлением src/locales/ в обязательную структуру (Sprint 9). Никаких больших переписываний.

Почему две конституции эволюционируют так по-разному? Потому что бэкенд решает больше неочевидных вопросов на старте. Какой формат миграций? Как нумеровать коммиты? Какая структура OpenAPI? Каждый раз, когда в спринте всплывал новый вопрос, к которому конституция не давала ответа — я добавлял туда правило. На фронте таких вопросов было меньше: shadcn/ui задаёт паттерны, React Query — серверное состояние, TypeScript строгий — а остальное оказалось в существующих принципах.

Здесь важен один тезис: конституция — это живой документ. Когда в проекте появляется новая ситуация, не покрытая правилами — документ адаптируется. Это не «нарушение» — это часть методологии. Spec Kit прямо об этом пишет: конституция должна быть живой, иначе она становится мёртвой буквой, которую все игнорируют.

Adapting the rule, not breaking it. Разница принципиальная.

Опора 3. speckit.analyze как контур обратной связи

speckit.analyze — одна из шести команд Spec Kit, и формально она называется «cross-artifact consistency analysis report». На практике это команда, которая проверяет согласованность между четырьмя артефактами фичи: spec.md, plan.md, tasks.md, и фактическим кодом после имплементации. Если в спецификации описано требование, которое не отражено в плане, или в плане есть фаза, не разложенная на задачи, или код реализован в обход того, что было спланировано — analyze это находит.

Я запускаю speckit.analyze после реализации задач спринта — это обязательная часть моего цикла. Иногда — ещё и перед реализацией, после того как появился tasks.md, когда хочется убедиться, что задачи действительно закрывают спецификацию. За 17 спринтов analyze ловил несколько критичных вещей и регулярные мелкие. Самый яркий пример — Sprint 5 backend, события через Kafka.

Я закончил имплементацию шести консьюмеров со встроенной идемпотентностью, прогнал тесты, всё зелёное. Запустил speckit.analyze post-impl. Нашёлся неочевидный недочёт: в нескольких use case'ах публикация события в Kafka шла внутри транзакции, без try-catch вокруг publishEvent. Это значило, что если Kafka в моменте недоступна — исключение поднимается наверх и откатывает успешно зафиксированную транзакцию БД.

То есть данные сохранились, потом откатились, событие не отправилось — система в неконсистентном состоянии.

Я бы это в комит-ревью пропустил. Тесты были зелёные, потому что в Testcontainers Kafka всегда доступна. Сценарий «Kafka недоступна, БД доступна» в integration-тестах не покрывался. speckit.analyze это поймал не потому, что прогнал какой-то умный тест — а потому, что прошёлся по спецификации, увидел требование «события публикуются после успешной транзакции», и сравнил его с фактом «публикация внутри транзакции». Расхождение.

Поправил try-catch, добавил тест на DLQ retry, и заодно — асинхронный IT-тест на streak-расчёт, который тоже всплыл в этом анализе.

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

Ключевое наблюдение про analyze: он не заменяет тесты или ревью. Он работает на другом уровне — на уровне согласованности артефактов между собой. Тесты проверяют, что код делает что-то. analyze проверяет, что код делает то, что было обещано в спецификации. Это разные слои.

Опора 4. API-first как договор между двумя репозиториями

Когда два репозитория существуют отдельно, главная угроза согласованности — API-контракт. Если backend выкатывает новый endpoint и забывает про frontend, или frontend ожидает поле, которое в API называется иначе — координация ломается. На обычной командной разработке это решается переписками, JIRA-тикетами, ревью. У меня была другая опция: API-first.

В backend я завёл отдельный Maven-модуль lifesync-api-spec, в котором лежит единственный файл — lifesync-api.yaml, OpenAPI 3.1 спецификация на все endpoint'ы. На сегодня это 2669 строк YAML, 32 endpoint'а. Backend генерирует Java-интерфейсы из этого YAML через openapi-generator-maven-plugin (контроллеры реализуют сгенерированные интерфейсы — писать их вручную запрещено конституцией). Frontend читает тот же YAML как источник правды и пишет TypeScript-типы в src/types/ руками: 5 файлов, около 230 строк типов.

Почему frontend пишет типы руками, а не генерирует? Это сознательное решение. Генератор TypeScript-типов из OpenAPI — рабочая опция (openapi-typescript, orval, @hey-api), и я её рассматривал. Не пошёл по двум причинам:

Контроль над формой типов. Сгенерированные типы часто буквально повторяют структуру API, со всей nullability и opt'ами. Для UI часто удобнее немного перекомпонованный тип, который ближе к тому, что отрисовывается на экране. Ручное написание оставляет это под контроль.
Типов мало, изменений ещё меньше. 230 строк типов на 32 endpoint'а — это контролируемый объём. Каждое изменение API сопровождалось ручной правкой типов на фронте, и это не превращалось в трудоёмкую задачу.

Внутри specs/ каждой фичи фронта лежит локальный contracts/-каталог с markdown-описанием endpoint'ов, которые эта фича использует — auth-api.md, goals-api.md, habits-api.md. Это не дублирование YAML и не альтернативный контракт, а навигационный срез под конкретную фичу для думающего чата: какие endpoint'ы я зову, какие поля жду, какие ошибки могут прилететь. Источник правды — по-прежнему YAML на 2669 строк, но его не нужно держать перед глазами целиком, когда работаешь над одной фичей.

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

Что важно понимать про эту схему: speckit.analyze не проверяет согласованность между репозиториями автоматически. Каждая команда Spec Kit работает в пределах одного репозитория. Я делал кросс-репо проверки руками: после изменений API в backend — в координационном чате готовил промт «вот изменения в API, проверь типы и компоненты frontend на необходимость правок», и проходил по этому промту в frontend-чате.

Где было трудно

Несколько мест за 17 спринтов, где SDD пробуксовывал — и где я остановился, переразобрался, продолжил.

Sprint 8 backend, рассинхрон plan.md vs spec.md. speckit.analyze показал расхождение: plan.md описывал три фазы имплементации, в spec.md была упомянута четвёртая. По коду я уже сделал все четыре, но в плане — синхронизации не было. Случай несложный (одна правка в plan.md), но показательный: методология не позволила мне забыть про эту синхронизацию. Без analyze я бы заметил это только в ретроспективе спустя три спринта.

Sprint 10 frontend, релизный с накопленными доработками. Это был последний спринт фронта, и он отличался от предыдущих: не одна большая фича, а набор мелких UX-улучшений и багфиксов, которые накопились перед релизом. SDD-цикл здесь работал иначе — короткий spec.md, плотный tasks.md на список доработок, обычный analyzeв конце. Главный урок: не каждый спринт идёт по идеальному циклу. Иногда фича — это «накопленные мелочи перед релизом», и она требует своих tasks.md и analyze, но без больших спецификаций.

Backend Sprint 3, который прошёл мимо SDD. В backend между Sprint 2 и Sprint 4 был короткий спринт настройки локального окружения для разработки — один fix-коммит, без specs/003-*/. Тогда я не делал спецификацию: задача казалась слишком технической для SDD-цикла. Сегодня бы я сделал спеку даже на это — specs/003-local-dev-setup/spec.md со списком требований к dev-окружению занял бы 50 строк, но дал бы фиксацию: какие порты, какие переменные окружения, какой docker-compose. Урок на будущее: SDD одинаково полезен на больших фичах и на маленьких настроечных задачах.

Что я забрал из этого опыта

Чувство контроля на 17 спринтах сохранилось до последней фичи. Это не потому, что я какой-то особенный — это потому, что методология даёт систему обратной связи на нескольких уровнях одновременно.

Спецификации фиксируют намерение. Что я хотел построить.
Конституция фиксирует правила. Как я договорился это строить.
speckit.analyze ловит расхождения. Что разъехалось между намерением, правилами и кодом.
Три чата разделяют контексты. Backend, frontend, общая координация — каждый со своим документальным фундаментом.
API-first — договор между двумя репозиториями. Один YAML, два потребителя.

Когда эти пять компонентов работают вместе, масштаб проекта перестаёт быть угрозой управляемости. Спринтов может быть 17, может быть 50 — структура контроля не меняется. Меняется только содержание.

Главный сдвиг от первой статьи: методология масштабируется без потери качества. Один вечер с Telegram-ботом и 17 спринтов с FullStack-приложением — это одна и та же методология, отличающаяся в деталях (третий чат, две конституции вместо одной), но не в сути. Это и есть тот ответ на вопрос «работает ли SDD за пределами игрушек», который у меня после первой статьи был ещё открытым.

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

Что дальше

Это третья статья в серии материалов из моих проектов:

Первая — про SDD на одном вечере на примере Telegram-бота.
Вторая — технический разбор архитектурных решений на парсере бизнес-формул через ANTLR4.

В следующих статьях планирую разбирать конкретные технические темы из LifeSync:

Hexagonal Architecture на Maven Multi-Module — как разложить backend на шесть модулей с чистым domain без Spring и use case'ами через @Bean в конфигурации.
jOOQ вместо Hibernate — почему я отказался от ORM и где это окупается, а где нет.

Репозитории проекта:

Backend — github.com/zahaand/lifesync-backend
Frontend — github.com/zahaand/lifesync-frontend
Демо — lifesync-frontend-ten.vercel.app

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

На каком масштабе вы пробовали SDD?

0%Не пробовал — пока изучаю0

0%Маленький проект (один вечер / один спринт)0

0%Несколько спринтов0

0%Длительная разработка (10+ спринтов)0

0%Использую SDD регулярно как основной процесс0

Никто еще не голосовал. Воздержавшихся нет.