为什么我不建议中小企业使用 TypeScript

此博客内容，包含【极端的个人主观因素、极端的个人主观因素、极端的个人主观因素】，如不喜欢，请轻喷......

不知道从什么时候开始，前端开发者中出现了一种 唯 TS 至上论 的思想。

如果你的项目中使用的 是JavaScript 而 不是TypeScript，那么就会被打上 很low 的标签。同时也会被立刻质疑：“你为什么没有使用 TS？”

我为什么一定要使用 TypeScript 呢？

TypeScript 真的有那么的完美，值得我们在任何的场景下都优先使用吗？ 恐怕不是的。

任何的一门技术都是一把双刃剑，它在带来一定优势的同时，必然也会带来一定的不便性。

所以，咱们今天就来聊一聊：“为什么我不建议中小企业使用 TypeScript！”

01：不要让 TS 沦为 个人KPI

有很多中小企业的 “技术Leader”，本身并没有对 TS 进行过深入的了解。只不过是因为老板的一句：“我听说人家现在都在用 TS 啦？” 而强行在团队中推行 TS 。完全不考虑团队目前的技术方向以及团队的加班时长，这是 不可取的。

所以 不要让 TS 沦为 个人KPI

当你想要在团队中推行 TS 时，你应该首先评估团队中是否有人使用过 TS，研究下大家学习 TS 所需要花费的时间。如果团队中都不熟悉 TS ，并且你也没有令人信服的理由，就不要强制团队使用 TS 啦。

02：大多数的中小企业很难适应它

说真的，“你（中小企业）花了多少钱招人，你自己心里没点 B 数吗？” 怎么着？还真打算拿着买“粉条”的钱去买“鱼翅”不成？

面试的时候，想尽办法的压薪资。工作的时候，又期望大家为你发挥出远超TA当前薪资的能力，好处都让你占了呗？

所以，别那么天真了！你的开发人员现阶段真的很难适应 TS。

如果，你真的想要在团队中推行 TS，并且希望它可以为你带来好的结果。

那么 请先培训你的团队！

拿出一定的时间和金钱，来提升你团队的技术能力和技术深度。为他们提供学习 TS 所需要的时间和课程，询问团队的意见，正确的评估你们团队的技能组合。否则你的 自私 决定，只会损害你们团队的利益，最终也会损害到你自己的利益。

03：容易出现 “伪 TS”

所有以 .ts 结尾的文件，都是使用了 TypeScript 的。

由此，项目中就有可能会出现大量的 “伪 TS”。也就是：“以 .ts 结尾的文件，但是内容都是 js。”

这样的项目，除了可以让你们老板拿出去“吹牛逼”之外，对技术个人是毫无意义的。

当然，让老板可以拿出去 “吹牛逼” 对很多 “所谓的 Leader” 而言，就是TA们价值的体现

04：更容易出现屎山

其实 “伪 TS” 还好，因为它毕竟 不需要 我们花费更多的 时间和头发 来了解它的心路历程。

而比 “伪 TS” 更可怕的是：屎山一样的 TS 代码。

相信我，一旦 TS 屎山起来，那个味道要比 JS 重的多！

不知道大家有没有接手过一些 “所谓的 TS 项目”。我有幸在多个 训练营的同学 那里见到过很多次。

过度的类型声明、过度的类型封装，以及那些明明被定义但是 “好像” 从来都没有使用过的属性们。偏偏你还不敢动它们。就问你晕不晕。

将来当你想要去定义一个属性时，发现好像已经有了一个类似的，但是你又不确定的时候怎么办呢？最安心的办法就是 “再创建一个”。

所以，我曾经有幸在一个接口中见到了这样的代码（以下为伪代码）：

interface User {
name: string;
name2: string;
username: string;
username2: any;

}

就问你刺激不刺激。

通常情况下，当我们遇到这样的代码时，根据 “尽量遵守前人代码习惯” 的规范下，很快这里就可能会出现 name3、name4 以及 name-next...

总结

任何的一门技术都是一把双刃剑，它在带来一定优势的同时，必然也会带来一定的不便性。

所以，我们真的没有必要去跟风追逐所谓的强类型。适合自己团队的，才是最好的！

这是第二次发了，虽然我啥也没改......