Когда меня спрашивают, стоит ли тратить время на типизацию, я обычно вспоминаю не абстрактные доводы из докладов, а конкретный проект, который чуть не утопил нашу команду. Это был обычный B2B-сервис для логистики, написанный на чистом JavaScript ещё до того, как мы вообще начали задумываться о типах. Продукт работал, клиенты платили, но каждая новая фича превращалась в русскую рулетку.
Самая дорогая ошибка в моей практике случилась именно там. Мы выкатили обновление, где в одном месте вместо суммы заказа в копейках передали рубли. Тесты покрывали всё, кроме этой одной ветки, потому что никто не ожидал, что кто-то перепутает единицы измерения. В итоге клиенты получили счета в сто раз больше положенного, бухгалтерия встала на два дня, а мы — на уши. Прямые потери, компенсации и репутационный ущерб потянули на очень круглую сумму, которую я до сих пор не люблю называть вслух. Именно тогда я понял простую вещь: типы — это не про красоту кода, это про деньги.
Когда мы начали постепенно переводить проект на TypeScript, чуда в первый месяц не произошло. Наоборот, стало больнее: пришлось описывать контракты, разбираться с любыми, терпеть красные подчёркивания в местах, которые годами жили припеваючи. Но именно этот период вскрыл десятки скрытых багов, о существовании которых мы даже не догадывались. Компилятор спокойно нашёл то, что ревьюеры пропускали месяцами.
Дальше началась экономика. Рефакторинг, который раньше занимал неделю со страхом сломать соседний модуль, стал занимать два дня. Онбординг нового разработчика сократился с месяца до примерно двух недель, потому что типы сами рассказывают, как устроена система. Количество инцидентов в проде упало в разы, а вместе с ними — ночные дежурства и стоимость поддержки. Если посчитать зарплаты инженеров, потери от простоев и стоимость откатов, набегает именно тот самый миллион, о котором говорят на конференциях.
Честно скажу: TypeScript не спасёт плохую архитектуру и не заменит нормальные тесты. Если писать везде any, вы получите JavaScript с лишним шагом сборки и без единого преимущества. Типизация — это инструмент для команд, где код живёт годами, где людей больше трёх и где цена ошибки измеряется не нервами, а деньгами. В маленьком прототипе на выходные она действительно избыточна.
Поэтому мой совет простой. Начинайте с новых модулей, включайте строгий режим постепенно и не пытайтесь переписать всё разом. Договоритесь в команде, что any — это временное решение с комментарием, а не стиль жизни. Автоматизируйте проверку типов в пайплайне, чтобы типы стали частью процесса, а не личной инициативой энтузиаста. И обязательно считайте, сколько вам стоила каждая ошибка в проде — эти цифры отлично убеждают руководство лучше любых аргументов о чистоте кода.
Спустя несколько лет я могу уверенно сказать: TypeScript окупился у нас многократно, и не только деньгами, но и спокойным сном всей команды. Код стал предсказуемым, релизы перестали быть лотереей, а бизнес получил то, что ему нужно больше всего — надёжность по разумной цене. А как у вас в команде: типизация уже спасла хотя бы один спокойный вечер, или вы всё ещё смотрите на неё как на лишнюю бюрократию?
Самая дорогая ошибка в моей практике случилась именно там. Мы выкатили обновление, где в одном месте вместо суммы заказа в копейках передали рубли. Тесты покрывали всё, кроме этой одной ветки, потому что никто не ожидал, что кто-то перепутает единицы измерения. В итоге клиенты получили счета в сто раз больше положенного, бухгалтерия встала на два дня, а мы — на уши. Прямые потери, компенсации и репутационный ущерб потянули на очень круглую сумму, которую я до сих пор не люблю называть вслух. Именно тогда я понял простую вещь: типы — это не про красоту кода, это про деньги.
Когда мы начали постепенно переводить проект на TypeScript, чуда в первый месяц не произошло. Наоборот, стало больнее: пришлось описывать контракты, разбираться с любыми, терпеть красные подчёркивания в местах, которые годами жили припеваючи. Но именно этот период вскрыл десятки скрытых багов, о существовании которых мы даже не догадывались. Компилятор спокойно нашёл то, что ревьюеры пропускали месяцами.
Дальше началась экономика. Рефакторинг, который раньше занимал неделю со страхом сломать соседний модуль, стал занимать два дня. Онбординг нового разработчика сократился с месяца до примерно двух недель, потому что типы сами рассказывают, как устроена система. Количество инцидентов в проде упало в разы, а вместе с ними — ночные дежурства и стоимость поддержки. Если посчитать зарплаты инженеров, потери от простоев и стоимость откатов, набегает именно тот самый миллион, о котором говорят на конференциях.
Честно скажу: TypeScript не спасёт плохую архитектуру и не заменит нормальные тесты. Если писать везде any, вы получите JavaScript с лишним шагом сборки и без единого преимущества. Типизация — это инструмент для команд, где код живёт годами, где людей больше трёх и где цена ошибки измеряется не нервами, а деньгами. В маленьком прототипе на выходные она действительно избыточна.
Поэтому мой совет простой. Начинайте с новых модулей, включайте строгий режим постепенно и не пытайтесь переписать всё разом. Договоритесь в команде, что any — это временное решение с комментарием, а не стиль жизни. Автоматизируйте проверку типов в пайплайне, чтобы типы стали частью процесса, а не личной инициативой энтузиаста. И обязательно считайте, сколько вам стоила каждая ошибка в проде — эти цифры отлично убеждают руководство лучше любых аргументов о чистоте кода.
Спустя несколько лет я могу уверенно сказать: TypeScript окупился у нас многократно, и не только деньгами, но и спокойным сном всей команды. Код стал предсказуемым, релизы перестали быть лотереей, а бизнес получил то, что ему нужно больше всего — надёжность по разумной цене. А как у вас в команде: типизация уже спасла хотя бы один спокойный вечер, или вы всё ещё смотрите на неё как на лишнюю бюрократию?