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

最近入职了一家公司领导在 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 项目上还是很好用的话，那么这通常是有问题的

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

Hanser002

5 天前

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

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

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

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

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