我觉得对方是比较有理的
3 这个问题，如果 1000 行代码里每个函数是独立且行数不多的，那么就不应该存在可读性问题，按函数名找就行了
4 这个事，你干你也麻，它是现实

台资？既然最后说现阶段不要求规范，那还唧唧歪歪个啥，怎么跑你这规范来规范去的。明明每个人风格都不一样，为什么又要让你保持和别人一致？这领导说了一大堆，一个站得住脚的理由都没有。1000 行能维护，3000 行就重写，理由呢，凭什么是 3000 不是 5000 。他就是得过且过型的吧，对技术毫无追求，所有的理论只是给自己不想变化不想接触新的东西硬拗罢了

看 review 的重点是什么，是语法规范问题还是代码漏洞问题（我想大部分都是为了避免代码漏洞）
这个项目大概率是从 vue2 迁移为 vue3 ，项目比较久远但稳定，大部分人是不会因为新增或修改一个需求而去动所有逻辑，更倾向选择一个更加简单且不容易出错的写法，从项目层面来说没什么问题。

确实，vue3 可以使用一些好的写法来完成需求，但是对于一个项目来说，稳定才是最重要的（想要使用更加简洁且方便的语法没问题，你改了，没人会知道，老板也不会认为你多牛；但是如果改出问题了，所有人都会知道，老板会认为你能力有问题）

补充：框架只是一个工具，不管是纯前端三剑客、angular 、vue 、react ，它们没有好坏，没有优劣，它们的目的都只是完成页面搭建，完成业务以及交互，只要能解决问题的都是好技术好工具。

最后：有好的想法和好的写法并提出是值得鼓励的，是我我也会提出你的这些问题，新需求和新业务我会使用简洁、高效的写法，但是大项目，老项目需要谨慎。

又是老项目，你又没有话语权，那就按着之前的写法继续写。
后面又新项目你再建议用新方式来写。
领导会比较担心：
1.新写法出现问题没人能解决
2.团队里面都不接受新写法，你写了会让其他同事跟进不了
如果是情况 1 ，你就说你有把握解决这些问题；如果是 2 ，我会选择跑路。

1 ，2 ，3 都不是大问题。风格沿用即可。重构起来需要时间，吃力不讨好的事情。

第四点来说，无解。新旧项目你无法统一他们的风格了。已成事实，你推不动。

没毛病，要么尽量与原有风格保持一致，要么当个 OKR 来做，定下新规范并统一风格之后全部重构，并配好代码检验规则来强制执行，否则都是扯淡

1 、团队成员技术栈，习惯 vue2 写法
2 、项目进度赶，没时间重构，遇到新写法，有问题还得查资料影响进度
3 、很多第三方 npm 包还是 vue2 的写法，安装引入能不能适配？例如，别人的代码 vue2 写法，copy 过来，还得改一遍。

如果不是我的项目，我绝对不会重构，改架构，要不就是你工作量不饱和，闲的。

写法问题不大，但是大文件拆分还是必要的

你的领导更合理，也更符合实际，他负责项目的时间比你更长，以后大概率也比你长，重构的代价非常大，之前的项目使用什么规范就尽量沿用，你想用更新的写法或规范是开发感受问题，但你想想以后接替你维护的人他们会有什么感受

我之前接手的旧项目，我直接来一个大重构，补 ts ，拆包拆组件，调整 eslint 规范，调整 vuecli 配置，前前后后用了不到一个星期，git 记录有 3w 行+ 和 2.6w 行- 。既然你项目到我手里了，那我就按我的习惯调整。

如果有人把这种脏活累活干了，领导还是不愿意接受，那就是领导的问题了。

---

1. options 和 composition api 各有优势，包括 jsx/tsx ，都不是互相排斥的，需要在对应的场景使用适当的方案。
2. 逻辑耦合度高，或者复用性比较强的，可以提取和抽象。没有必要只是为了代码行数做优化。
3. api 写在一起问题不大，但是最好改造成 esm ，有利于构建工具进行 tree-shake 。既然改造了，按模块拆分一下也是合理的。
3. 每个项目有自己的情况，在没有通用的脚手架或者统一规范前是没有办法避免代码风格不一致的问题的。只能尽力去优化。