Decomposition 2026 11 05

Ориентировочно: **от 1 до 5 рабочих дней**, в зависимости от сложности модуля. «400 строк» — не главный фактор; важнее, сколько там логики, типов, async, зависимостей и неявных контрактов.

### Быстрая оценка

| Сложность модуля | Что внутри | Оценка |
|---|---|---|
| Простой | Линейная логика, мало зависимостей, нет async, простые типы | **6–12 часов** / ~1–1,5 дня |
| Средний | Классы, generics/typing, обработка ошибок, несколько библиотек | **2–4 дня** |
| Сложный | Async/concurrency, работа с сетью/БД, сложные типы, интеграции, неочевидные побочные эффекты | **5–10 дней** |
| Очень сложный | Доменная логика, много неявных контрактов, нет документации и тестов | **1–3 недели** |

### Из чего складывается время

Для среднего случая:

- понять текущий модуль и его контракты — **2–4 ч**;
- перенести код на Python — **6–16 ч**;
- разобраться с библиотеками/async/типами — **2–8 ч**;
- отладить и проверить вручную — **4–12 ч**;
- ревью и доработки — **1–4 ч**.

Итого: **2–4 дня** на средний модуль.

### Почему отсутствие тестов — риск

Без тестов нельзя быстро проверить эквивалентность поведения. Это добавляет **20–50% времени** и повышает вероятность, что часть поведения потеряется. Особенно если в TS были:

- `async/await`, Promise, event loop;
- строгая типизация, generics, union types;
- неочевидная обработка `null/undefined`;
- npm-библиотеки с неочевидными аналогами в Python;
- особенности сериализации, дат, regex, ошибок.

### Практический совет

Перед переписыванием я бы заложил **2–4 дня** и сделал хотя бы минимальный smoke/characterization-набор: несколько сценариев «вход → выход». Это часто экономит больше времени, чем стоит.

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