TypeScript和JavaScript在过去几年中得到了改进，我们在过去几年中建立的一些做法可能已经过时了。有些可能永远都说不通，下面我列出了很多=开发人员可能犯的一些错误！1.不使用严格模式通过使用tsconfig.json不使用严格模式。使用严格模式后。为什么要使用严格模式？严格模式可以剔除一些语法上不合理、不严谨的部分，可以让TS向更合理、更安全、更严谨的方向发展：通过将一些TS静默错误改为抛出错误，剔除一些TS错误。Silenterror可以更有效的保证代码运行的安全性；提高编译效率，提高运行速度；禁止某些可能在未来版本的ECMAScript中定义的语法。2.使用||确定默认值那么它应该是什么样子呢？使用最新的？？运算符或最好在参数级别定义返回值。这？？operator是去年才引入的，如果在长函数的中间使用值，可能很难将它们定义为参数默认值。？？与||不同，它只返回null或undefined而不是所有的假值。3.使用any作为类型当我们不确定数据类型时，我们会使用any类型的数据。在我们不确定类型的所有情况下，我们应该使用未知。你为什么这样做？any很简单，因为它基本上禁用了所有类型检查。通常，甚至在官方类型中也会使用any（例如，上面示例中的response.json()被TypeScript团队键入为Promise）。为什么你不能使用任何？它实质上禁用了所有类型检查。通过any传入的所有值将完全放弃任何类型检查。这会变得很难捕获错误，因为只有当我们对类型结构的假设与运行时代码匹配时，代码才会失败。4.val作为SomeType强制告诉编译器它无法推断的类型。这就是类型守卫的用途。当我们想要从JavaScript转换为TypeScript时，现有的代码库通常会对TypeScript编译器无法自动识别的类型做出假设。在这些情况下，使用fastasSomeOtherType可以加快转换速度，而不会放松tsconfig.xml中的设置。尽管现在可以保存断言，但当有人移动代码时，这可能会改变。类型保护将确保所有检查都是明确的。5.测试用例中any的表现是写测试的时候：如果测试需要mock数据，需要把mock逻辑移到我们mock的一边，让它可以复用。虽然在尚未具有良好测试覆盖率的代码库中编写测试时经常会出现复杂的大型数据结构，但只有其中的一部分被测试的特定功能需要。短期内不用担心其他属性更简单。最近一次是当其中一个属性发生变化时，我们必须在所有测试中而不是在一个中心位置更改它。此外，在某些情况下，被测代码依赖于我们之前认为不重要的属性，因此必须更新针对该功能的所有测试。6.可选属性将属性定义为有时存在有时不存在的可选属性。清楚地表达哪些模型组合存在，哪些不存在。将属性定义为可选的而不是划分的更容易并且生成更少的代码。它还需要对正在开发的产品有深入的了解，并能够在产品假设发生变化时限制代码的使用。类型系统的最大好处是它们可以用编译时检查代替运行时检查。通过更快速的输入，可以在编译时检查可能被忽视的错误。7、用字母作为泛型参数，用字母作为名称，比如常用的T作为泛型名称！应给出一个完整的描述性类型名称。我猜很多人都有这个坏习惯，因为连官方文档都用单字母命名。按T??而不是写全名可以更快更省心地输入。通用类型是变量，就像其他变量一样。当IDE开始向我们展示这些技术细节时，我们已经放弃了在变量名称中描述变量技术细节的想法。例如。我们通常只写constname='Daniel'而不是conststrName='Daniel'。此外，单字母变量名通常会引起轰动，因为如果不查看它们的声明就很难理解它们的含义。8.非布尔检查通过将值直接传递给if语句来检查值是否已定义。我们可以明确地检查我们关心的案例。简而言之，写支票看起来更干净，让我们不用去想我们真正想要检查的是什么。也许我们应该考虑一下我们真正想要检查的是什么。例如，上面给出的示例以不同方式处理countOfNewMessages为0的情况。9.！！运算符将非布尔值转换为布尔值。清楚勾选我们关心的条件。对于我们中的一些人，理解！很简单。它看起来简短明了，如果你已经熟悉它，你就知道它是关于什么的。这是将任何值转换为布尔值的简单方法。尤其是在null、undefined和""等假值之间没有明确语义分离的代码库中。使用！！通过促进内部知识来混淆代码的真正含义。这使得新开发人员更难访问代码库，无论是一般开发新手还是JavaScript新手。引入细微的错误也很容易。“非布尔布尔检查”中countOfNewMessages为0的问题仍然存在！！
