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

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

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

来源:https://v2ex.com/t/1072868