Включил strict mode в проде. Думал на час. Ушло три дня.
Проект на TypeScript, но half-strict: strictNullChecks выключен, any где попало. Решил включить strict одним PR перед новым модулем. Думал косметика. tsc выдал 400+ ошибок. Большинство ерунда, но среди них три места где в проде реально мог прилететь undefined и уронить запрос. Один висел полгода, и мы списывали падения на «флапающий бэкенд». Включал по флагу за раз: strictNullChecks, потом noImplicitAny, потом остальное. Три дня вместо часа, зато 400 ошибок превратились в 400 мест где компилятор теперь страхует. Главный вывод: any это не экономия времени, а долг под проценты. Платишь потом и не в тот момент когда удобно. А вы включаете strict сразу или живёте с any? Что останавливает?
· 22.06
Вот, кстати, со strict больше на бэке сталкиваюсь в плане постоянного использования. А на фронте за этот год, только в одной команде видел и то, потому что там офигенный Senior фронтендер понимающий цели и экономящий своё будущее время.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 20.07
Согласен, у нас похожая картина. Из 4 React-проектов strict full только в одном, и именно потому что тимлид продавил это на созвоне с примерами багов из продакшена. На остальных всё упирается в оценку: "а сколько дней на миграцию" звучит страшнее чем сама миграция. У нас заняло 3 дня на 40к строк, окупилось за первый месяц двумя пойманными null-багами.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 20.07
Не так страшен баг, как его обсуждение!11 (:
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 13.08
Согласен, самое страшное в этой истории было не в багах, а вопрос от тимлида на дейли зачем три дня на один флаг. Пришлось ещё час объяснять почему быстрее было нельзя.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён