我用1个月，把一个3个人做了1个月的全TS项目，用JS重做了一遍。
不是优化，是重写。
而且那时候，AI 还帮不上什么忙。
我讲一个我自己经历过的项目。
公司不大，但一开始，是想“做规范”的。
项目启动的时候，我们走的是完整流程：
需求评审、方案文档、项目设计文档，全都有。
光前期这些，就花了1个多月。
前后端配置也很“标准”：
前端全 TypeScript，后端 Java，严格按文档开发。
一开始看起来，非常理想。
但问题很快就来了。
开发过程中，领导和销售不断提新需求。
按流程，这些需求应该排到后续版本。
但现实是，公司小，谁能带来收入，就听谁的。
于是所有新需求，只能一边开发，一边硬加。
接下来发生的事情，其实很多人都经历过。
文档开始失效。
设计开始被绕开。
原本定义好的结构，被一层一层打破。
等到第一版做完的时候：
代码，和最初的设计文档，已经完全是两套东西。
更现实的是，从那之后：
没有需求评审了。
没有文档更新了。
也没有什么流程了。
基本就是一句话：
“这个需求加一下。”
然后直接改代码。
再往后，问题开始失控。
因为没有统一设计，也没有文档约束。
TypeScript，反而变成了混乱的源头。
一个 Goods 类型，出现了好几份定义。
字段差不多，但总有细微差别。
每个人写一份，用的时候再各自改一点。
类型越来越多，但系统却越来越乱。
最讽刺的是后面的事情。
项目最开始，是我们3个前端，一起用全TS开发了1个月。
后面另外2个被调走，这个项目变成我一个人接手。
我做了一件很简单的事：
把整个项目，用JS重写了一遍。
花了1个月。
也就是说：
3个人 + 全TS + 完整流程，用了1个月。
1个人 + JS，重做一版，也用了1个月。
你说老板会怎么想？
他只会觉得：
“你们之前是不是在谎报开发周期？”
但实际情况是：
前面那1个月，我们也在天天加班。
只是时间，大量耗在了：
流程、文档、以及不断被打破的类型系统上。
这个项目让我彻底想明白一件事。
在一个需求不稳定、随时变更的环境里：
流程、文档、TS，本来是用来提升效率的工具。
但一旦环境不匹配，
它们就会反过来，成为负担。
后来我面试新同事，都会问一个问题：
怎么看待 TS 和 JS？
大多数人给的，都是八股标准答案。
但真正做过这种项目的人，其实不会这么回答。
