关于前端代码规范的问题请教一下大家

最近入职了一家公司领导在 review 代码的时候有一些分歧，我跟他聊了一些问题

使用最新的 vue3 技术，而用着老旧的 vue2 的写法
能 1 行代码解决 10 行代码，但是非要用 10 行代码的写法
长达 1000 行请求（定义请求 url 的）的代码文件，不做任何拆分处理，页面上所有请求都写到这个文件中
目前我维护的几个前端项目每个项目都是不同的写法

对于以上几点，以下是我跟领导的讨论记录

使用最新的 vue3 技术，而用着老旧的 vue2 的写法

xxx: 會沿用像 vue2 的寫法純粹是因為當時我們幾個一致覺得這種寫法比較好，比 vue3 那種自由奔放，全部宣告的變數都放進 view 裡面好以下是具体代码举例

<script setup>
  export default defindComponent({
    component: xxx,
    setup:(){
        const listData = ref()
        const handleData = ()=>{xxx}

        return buildSetup({
          method:{},
          data:{ listData },
          handles: { handleData }
        })
    },
  })
<script>
// 页面上使用需要 
// {{ data.listData }}  {{ handles.handleData }}

// 还有些页面甚至全是 vue options API 写法

能 1 行代码解决 10 行代码，但是非要用 10 行代码的写法

我：当页面要获取请求的 loading 和 data 来展示的时候，老写法需要定义两个 ref 来存储接口的数据和状态，过于繁琐，所以使用了以下写法
```
const { data, loading} = useRequest(fetchData)
```
xxx： 現在項目的最優先考量是沒有必要的話，不要引入新的寫法，就算新寫法比較好用也是一樣, 因為只會造成新舊不一致，哪天你走了以後下個人又來一個寫法，久了就更難維護了所以有出現 useRequest 的地方，我都會退回
```
const data = ref()
const loading = ref(false)

const getData = ()=>{
    loading.value = true
     await getData(xxx).then(res=>{
          data.ref = res.data
     })
     loading.value = false
}
```
长达 1000 行请求（定义请求 url 的）的代码文件，不做任何拆分处理，页面上所有请求都写到这个文件中

我：请求文件中代码量已经非常大，快接近 1000 行，继续往里写可读性会越来越差
```
export default {
  async getListData = () => {
    return  axios.get(xxx)
  },

  async getUser = () => {
    return axios.xxx
  },

  xxx...
}
```
xxx: 現階段我不覺得這是個問題，我也不覺得可讀性有變差，而且對 reviewer 來說沒有多的心智負擔，只要順順看過去就知道在做什麼了。你可能會問說：「那之後變到 3000 行怎麼辦？」，我會說，到那個規模的時候，這個項目很多寫法都不適用了，那時八成會打掉重做，因此現階段這不是個問題
目前我维护的几个前端项目每个项目都是不同的写法

我：之前前端这块没有前端规范是因为项目都在不同的人手里，每个人开发会有差异，那既然现在项目都是我们自己人在维护了，为什么不统一一下写法和规范呢（ PS: 大概 3-4 个项目，每个项目的写法都不一样）

xxx： 做任何事情都是需要成本的，如果沒有考慮到成本跟帶來的效益，那就只是種自我滿足而已現在的前端系統不會常出 bug ，代表功能上沒太大問題，那會很難維護嗎？不會，雖然幾個項目彼此的風格可能有差，但盡可能維護項目內的風格是一致的，就算以前沒有一致之後，之後也會盡量一致再來還需要考量項目之後的發展以及生命週期，之後還有很多新功能嗎？還是已經差不多了？那如果已經進入維護期了，重構的必要性是什麼？有些人只是覺得代碼看起來不順就要重構，沒思考過這個理由是不是合理，是不是符合效益總結一句話大概是我認為目前沒有制定開發規則的必要性，現有代碼也暫時不需要大規模的重構

最后是领导对于团队规范的总结：不同階段/規模的項目有不同的做法，1 個人的、10 個人的或是 100 人合作的項目，做法都不同，如果硬要把 A 項目的做法直接套到 B 項目上面，或是直接把以前習慣帶進來覺得這一套之前很好用，現在一定也很好用，那通常是有問題的

我理解这句话的意思一个公司中的团队规范如果在 A 项目中好用，然后套用到 B 项目上还是很好用的话，那么这通常是有问题的

欢迎大家理性讨论，不知是我过于追求代码洁癖了还是什么

dfkjgklfdjg

5 天前

如果做不到固定的开发工作流，确保每一个 MR 都会 review 通过后才会被合并。
那么 OP 你关注于“技术”部分的规范，确实会补充中领导的长远看法一样。

---
关于团队开发规范一般都是开发团队中互相理解认可，最终达成一致的规范。而不是一两个人拍脑袋确定下来的。
至于项目 A 使用，不代表项目 B 也适用。其实和团队 A 认可，不代表团队 B 也会认可一样的。

比如你的举例就很“技术”，并不是一个对于开发流程的规范，更像是 Lint 相关的规范（也就是 Coding Style ），那么确实并不一定适用所有项目。
---

比如你可能会觉得<问题 1>很不爽，但是可能项目开始时期 `script:setup` 并没有实现，所以当时只是使用了 `setup` 并没有使用 `script:setup`。
那么按照你<问题 4>的认定，你多半也不会认可在一个项目中同时出现选项式和组合式两种写法。那么比较合适的情况就是延续旧有的“开发规则”，继续使用 `setup` 开发而不是 `script:setup`，而不是全部重构成 `srcipt:setup`。

至于<问题 2>和<问题 3> 是出于一个中间地带，首先代码量少并不一定就是“好代码”，举个很极端的例子 `const result = condition1 ? condition2 ? 'A' : 'B' : condition3 ? 'C' : 'D';`
虽然示例和 OP 你表达的并不一样，我这样举例有一点抬杠的意味，但想表达的是代码结构清晰，可以让所有人都可以快速理解的代码，才是真的“好代码”。
不知道你举例的 `useRequest` 是 [VueUse]( https://vueuse.org/core/useFetch/) 这种比较大众的工具类库提供的，还是自己内部实现的工具类库。

API 都声明在一个 `index.js` 文件中，我也觉得会是一个问题，但是可能开发团队已经习惯了直接使用 `import { xx } from '@api' 中引入对应的接口了。
可以贡献一个模块化拆分后 API 维护的 MR ，并且提供和原本一样的聚合后的 `@api/index.js`出口（`export * from './modulesA'`）。
这个 MR 就可以当成首次 review 的一个样例。

---

但是 OP 你得和你的领导确定好，你们想要制定的规范是什么，是开发流程的规范，还是编码风格的规范。
开发流程的规范当形成习惯之后是可以随团队一直延续、传承下去的，但是编码风格的规范会随着不同项目的主导人而不同的。

关于前端代码规范的问题 请教一下大家

关于前端代码规范的问题请教一下大家