其实很简单，核心就是，做这件事对他有什么收益吗？
他给他的老板的汇报 PPT 上写“把一个 1000 行的文件拆分成 4 个”
你觉得他老板会认为他做了有价值的事吗？

接口拆分下就行了，其他的你无能为力。如果你没话语权，维护好自己的模块就行。

1 和 2：恐怕是之前有过用代码行数评定 kpi 的时期。

评估你的方案、effort 和收益。

本质上是你没能说服你上级，没能说服的原因是这些点上他都有能自洽的道理而你的道理也自洽，但是并不能取得压倒性的胜利。
比如你那个 hooks 的例子，你能看到有人曾经因为这个写法产出过 bug ，最后增加了多少工时，那这就是一个可以说服的点，相比你的写法的心智负担，降低了 bug 产生率，等等等，而心智负担你可以通过注释、wiki 之类的东西来降低影响。
或者说哪次扩展功能，结果需要修改大量重复代码等等。

如果你发现你列不出合理的例子和收益，那说明这事他说得对，你自己没想明白。

代码是为项目服务的，你又不是在做开源。

如果团队和领导对于 `review` 这件事的导向是维持项目稳定，那就不要折腾了，毕竟人是要“合群”的。

4 里面说了 `目前我维护的几个前端项目每个项目都是不同的写法`，但是 2 用了更现代的方案反而被打回。我理解之前的团队和领导也没有做好团队规范，领导给你描述的只是他认为/习惯的方式。说不好听点，就像国内很多团队一样，我升级到 vue3 ，但我还用 vue2 的写法；我引入 ts, 但是只用 any 。如果不能接受升级框架带来的新的规范、新的写法、新的库，那就没有必要升级，更何况 `vue2` 已经停止维护了。

对于 2 而言， `useQuery` 就是 `vue3` 请求的范例，你领导的代码就是繁琐、过时、低效，为什么有封装好的不用要自己写。如果一个组件有多个请求，参数之间有竞争，是不是还要手动去处理这些关系？我 review 碰到这种请求方式都是直接打回，自己手动去管理这些状态往往会出问题。这么看下来 “做任何事情都是需要成本的，如果沒有考慮到成本跟帶來的效益，那就只是種自我滿足而已”  这句话只是你领导不学不会不练的托辞。

就是老古董不接受新事物而已，看不懂又不好意思问。

没有太大意义，卷要向能给项目赚钱的方向卷

能跑就行了，打工人别难为打工人

1,2,3 问题不大，但改起来麻烦，需要成本，大可不必，而且对自身成长没有啥帮助。

4 ，领导说的对，老项目不动它，既没成长，亦无收益，动它作甚。

以后的新项目，再采用统一的标准。

以上为个人观点。

领导不去学习吗？墨守成规，固步自封。