hackape

JS/TS 全栈确实是个大趋势，前后端通吃，是个性价比非常高的路径，可以说是现在年轻创业公司的技术栈首选。加上云原生厂商如 cloudflare, vercel 也都把科技树点在 JS 上，前景看好。

属于事物的一般发展规律了。相关阅读推荐： https://blog.visionarycto.com/p/my-20-year-career-is-technical-debt

有可行性，但只会在有限范围内。TS 的类型收窄，就是静态分析器有限度的做了一点运行时的工作：a) 读懂 if condition; b) 收窄的有效期需要跟踪变量是否在判断后没有改变。类似的，rust 的 lifetime 检查其实也是部分在做运行时的一些 context sensitive 的工作。

所以现在的问题就是，你愿意付出多大的代价维护这个 context ？从实用角度讲，你肯定不能要求静态分析器去追求运行时等效，那性能就没法保障。

咱还拿 TS 类型收窄举例

```ts
if (x === 10) {
x = 10
f(x)
}
```

加上 `x = 10` 就会报错，说明 TS 的实现逻辑就是，老子刚检查完你别动这变量啊，动了我就不保证了。那你说它读的懂 `x === 10` 能不懂 `x = 10` 吗？肯定不能啊，只是它选择不去懂。

思考一下 OP 想要的功能怎么实现，就是要求静态检查器跟踪变量的运行时赋值，除了检查 assignability 还要把 literal value 挨个记住。形如下例会付出多大代价呢：

```
x = 1
f1(x)

x = 2
f2(x)

x = 3
f3(x)
```

考虑性能，backtrace 大概率不会用因为慢，那就用 cache ，赋值几次 cache 几次，就算不考虑循环，赋值这么频繁出现的操作，内存肯定要爆炸。综上，我认为是有理论可行性的，但不经济。

反观类型收窄，是进入 if block 的时候才启用，并且只 cache 一个值，干净又卫生，所以就实现了。

请忽略柠檬精们的发言，你做的事情非常棒！维护过大项目的人都知道，核心技术有多牛逼真不是项目成功的重要标准，最终要的是日复一日的坚持，持续不断的维护打磨各方面的细节。commit chart 初始的几座山仅仅是开始，让项目成功的是后面那条长长的尾巴，以及数量不断增加的 contributors 。长期做好这件事本身比一周肝一万行代码难的多。

这事儿的本质跟 git 没有任何关系。

即便是不分叉、线性地去开发，想象一下张三开发 A 模块，改了通用服务 C，提交完了，然后李四接着开发 B 模块，然后也改了服务 C 。你看这里面没有分叉再合并、产生冲突的过程，但也不能保证李四改完了的 C 就完全不出问题，除非李四充分理解自己的改动，这包括他需要去看张三的那部分代码。

合并出现冲突，本质上面对的问题还是两个人分别改了同个东西如何保证不出错，要么是李四解决冲突的时候好好读代码，要么把张三叫过来，大家一起 review 一下。

再退一步讲，哪怕只有张三一个人写东西，照样不能保证不出错，相信大家都有过看不懂自己的老代码的经验。

所以说这事儿跟 git 没有半毛钱关系，而你说的问题，别的楼层提到的 CI/CD, TDD 都是有效的方法（如果不流于形式、好好执行的话），然而还是那句话 there's no silver bullet，这个话题没有最终答案的。