[职场话题] 关于前端代码规范的问题 请教一下大家

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

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

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

1. 使用最新的 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 写法
   

2. 能 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
   }
   

3. 长达 1000 行请求（定义请求 url 的）的代码文件，不做任何拆分处理，页面上所有请求都写到这个文件中

   我： 请求文件中代码量已经非常大，快接近 1000 行，继续往里写可读性会越来越差

   export default {
     async getListData = () => {
       return  axios.get(xxx)
     },
   
     async getUser = () => {
       return axios.xxx
     },
   
     xxx...
   }
   

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

4. 目前我维护的几个前端项目每个项目都是不同的写法

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

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

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

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

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