Строгий TypeScript на клиентских проектах: считаем, окупается ли

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

Что включает строгий режим

Флаг strict объединяет несколько проверок. Главные из них две: запрет неявного any и строгая проверка на null и undefined.

{
  "compilerOptions": {
    "strict": true,
    "noUncheckedIndexedAccess": true,
    "exactOptionalPropertyTypes": true
  }
}

Отдельно стоит noUncheckedIndexedAccess: он заставляет проверять результат обращения по индексу. Именно эта проверка ловит самый частый рантайм-баг — обращение к элементу пустого массива.

Сравнение двух проектов

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

• Время разработки: 19 дней против 23 — строгий режим добавил около 20%.
• Правки по багам за три месяца после сдачи: 14 против 4.
• Из них связанных с отсутствующими данными: 9 против 0.
• Суммарно время на поддержку: 21 час против 6.

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

Где строгость мешает

Данные из внешних источников

Ответ чужого API типизировать бессмысленно: реальность всё равно окажется другой. Мы валидируем такие данные на границе и внутрь пускаем уже проверенный объект.

import { z } from 'zod'

const OrderSchema = z.object({
  id: z.string(),
  total: z.number(),
  items: z.array(z.object({ sku: z.string(), qty: z.number() })),
})

// Дальше по коду тип известен и гарантирован
export function parseOrder(raw: unknown) {
  return OrderSchema.parse(raw)
}

Быстрые прототипы

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

Как переводить существующий проект

1. Включаем strict и смотрим количество ошибок — обычно их сотни.
2. Не чиним всё сразу: добавляем // @ts-expect-error с комментарием и датой.
3. Каждую неделю разбираем часть помеченных мест.
4. Запрещаем добавлять новые подавления через правило линтера.

Где типы не окупаются

Короткие лендинги (посадочная страница) с двумя формами. Проект живёт месяц, кода мало, читать его повторно никто не будет — настройка окружения займёт больше времени, чем сэкономит.

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

Частые вопросы

Через два-три месяца проект оказывается полностью строгим, и никто не тратил на это отдельный спринт.