TypeScript дает нам возможность улучшить архитектуру нашего приложения JavaScript с помощью типобезопасности и документации по коду. Однако он не включает "строгий режим" по умолчанию, чтобы снизить порог входа для новых адаптеров. Angular использует тот же подход. Он не переключает строгий режим при создании нового приложения Angular, если явно не указано иное. Это может помешать нам в полной мере воспользоваться строго типизированной природой TypeScripts, которая позволяет нам обнаруживать целый класс ошибок во время компиляции.

Существует способ сразу же воспользоваться преимуществами строгого режима, даже если у вас есть приложение с сотнями или тысячами файлов TypeScript. Читайте дальше, чтобы узнать больше!

Архитектура влияет на экономику программного обеспечения

Одно из популярных определений архитектуры программного обеспечения дает Мартин Фаулер:

«Архитектура программного обеспечения - это те решения, которые одновременно важны и трудно изменить». - Мартин Фаулер

Эти решения сильно влияют на стоимость и усилия, затрачиваемые на добавление новой функции в отношении времени (экономика разработки программного обеспечения).

Как инженеры-программисты / архитекторы, наша цель - поддерживать наивысший уровень качества внутреннего кода, чтобы обеспечить возможность сопровождения базы кода. Это гарантирует, что функции можно будет быстро разработать, подключив их к базе кода, как блоки лего, и постоянно отправляя их нашим конечным пользователям. Если вы хотите узнать больше об архитектуре программного обеспечения, ознакомьтесь с этой великой книгой, написанной Thought Workers.

Флаг strict - это зонтичный флаг, который одновременно переключает следующие шесть флагов:

  • noImplicitAny
  • noImplicitThis
  • strictNullChecks
  • strictPropertyInitialization
  • strictBindCallApply
  • strictFunctionTypes

Цель этих флагов - усилить безопасность типов, обеспечиваемую TypeScript, чтобы избежать целого класса ошибок во время компиляции. Вот статья, объясняющая эти флаги. Это может быть очень полезно для уменьшения потока ошибок в кодовой базе, снижения энтропии программного обеспечения и, как следствие, уменьшения усилий / затрат на добавление новых функций. Но на самом деле сделать это непросто.

Немедленное включение может вызвать тысячи ошибок.

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

Есть способ продолжить выпуск новых функций, одновременно улучшая безопасность типов и архитектуру вашей кодовой базы:

  • Используйте отдельный tsconfig.json файл для редактора кода с включенным строгим флагом
  • Установите в своей организации правило для исправления ошибок линтинга / компилятора, отображаемых редактором кода, когда разработчики обнаруживают их в файлах.
  • Совет от профессионалов: добавьте этап сборки в конвейер CI / CD, чтобы создать приложение с помощью файла strict tsconfig.json, чтобы генерировать отчет по каждому выпуску для построения графика и отслеживания количества ошибок компилятора, уменьшающихся со временем.

Хитрость

Было бы здорово, если бы мы могли установить собственный tsconfig.json для VSCode (я предполагаю, что большинство из нас использует vscode). Но поскольку это пока невозможно из-за этой проблемы с Github, есть обходной путь, который мы можем использовать. Предположим, вы используете приложение Angular, но этот трюк применим к любому приложению TypeScript в браузере или среде выполнения узла.

  • Переименуйте файл tsconfig.json в tsconfig.build.json
  • Запустите tsc --init --strict в корне вашего проекта, чтобы создать tsconfig.json файл со строгим флагом, включенным для строгой проверки типов.
  • Измените tsconfig.app.json файл, чтобы расширить tsconfig.build.json и tsconfig.spec.json, и сохраните их.

Вот и все 🎉🎉🎉

Мы подключили VSCode для использования только что созданного tsconfig.json

Теперь вы будете получать визуальную обратную связь о строгих типах ошибок в файлах TypeScript без нарушения сборки Angular / Webpack

Предостережения

Как и любое отличное решение, всегда есть компромисс. Используя это решение, мы заметим следующие предостережения:

  • Многие ошибки обнаруживаются в большинстве файлов TypeScript, и это может быть пугающим.
  • Труднее отличить новые ошибки в текущей разработке, которые могут нарушить сборку, от ранее существовавших ошибок из-за строгого режима.

Однако, на мой взгляд, преимущества появления ошибок в редакторе перевешивают его неудобства.

Резюме

Одна из наших главных целей как инженеров-программистов / архитекторов - поддерживать высокое внутреннее качество нашего приложения. В этой статье мы увидели, как включить параметры строгой проверки типов TypeScript в существующем приложении среднего и крупного масштаба. Мы узнали, как можно сразу же воспользоваться преимуществами строгой проверки типов, без рефакторинга сотен и тысяч ошибок. Мы узнали, как мы можем использовать это для обнаружения ошибок ввода в нашем редакторе кода, чтобы устранить многие ошибки во время компиляции. Мы также узнали, что при любых архитектурных решениях всегда есть компромиссы.

Спасибо за чтение, и я надеюсь, что это поможет вам, как помогло мне.

Я хотел бы узнать в комментариях ниже, было ли это полезно!

Вы можете подписаться на меня на GitHub или Twitter
Удачной разработки!