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

64 天前
 ali233

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

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

4470 次点击
所在节点    职场话题
86 条回复
murmur
64 天前
1000 行能跑就行,现代的 ide 都有代码折叠和函数大纲预览功能,vue 的好处就是模版=html ,不像 react 如果不拆分组件,连基本的代码对齐都没法保证,

vue2 除了不够时尚,有完善的生态,没有严重 bug 和性能问题,选词填空写法更适合外包项目
ali233
64 天前
@murmur 并不是 vue 的代码文件,只是声明请求的文件,项目中所有的接口都定义到这个文件里了
tool2dx
64 天前
公司项目不都是要妥协的嘛。什么都能顺心写的,那是个人项目。

xxx 说的也没错,代码写那么飘,哪天你走了,谁来维护这一堆屎山。
ali233
64 天前
@murmur 怎么说呢 也不外包项目,当然也可以理解 vue2 的写法,介意的点是已经用了 vue3 了但是不惜专门写一个函数来把 setup return 的值包裹成类似 vue2 的写法
ali233
64 天前
@tool2dx 这句话确实没错,但是现在的情况就是好几个项目都是杂乱无章的写法,现在好几个项目都在我们这里维护,想着为什么不可以在开发的时候把这几个项目统一一下写法和规范
至于屎山和后续维护,在统一代码和规范之前肯定会先跟团队一起讨论出统一的写法
vikaptain
64 天前
最后是领导对于团队规范的总结: 不同階段/規模的項目有不同的做法,1 個人的、10 個人的或是 100 人合作的項目,做法都不同,如果硬要把 A 項目的做法直接套到 B 項目上面,或是直接把以前習慣帶進來覺得這一套之前很好用,現在一定也很好用,那通常是有問題的
NoobNoob030
64 天前
年纪越大,越固守成规
vikaptain
64 天前
@vikaptain 你领导说的段完全没问题,不要教条主义。规范都需要根据现在的实际情况做响应的调整。
ali233
64 天前
@vikaptain 是的 这是原话,不知是我后面的理解有问题还是他的本意其实就是这个
liaozzzzzz
64 天前
这属于公说公有理婆说婆有理的问题了,我建议还是好好定一下团队规范,新的模块可以按照新规范来玩,旧的部分需求没大变化的场景下就维持稳定…
Vegetable
64 天前
xxx 说的都很有道理
我认可的理由是:尊重现有项目的一致性是很有必要的,你的理念都是对的,但是对于一个稳定项目,在不打算根治的情况下,尽量先别打破他。你想写更好的代码,第一步不是先把代码写进去,而是制定新的规范。
ali233
64 天前
@vikaptain #8 关键点就是项目团队中现在没有统一的规范, 如果一个规范在一个项目中适用,然后在另一个项目中也适用的话我会认为这是一个蛮不错的规范,再基于实际情况做调整也是可以理解的
bojackhorseman
64 天前
等一个 vue4 把 options 写法支持砍掉
ali233
64 天前
@liaozzzzzz 最后讨论的结论是不需要团队规范,继续按照之前的各个项目中不同的形式来开发
shintendo
64 天前
Options Api ≠ Vue 2
如果不用 TypeScript 的话,我认为大多数情况下 Options Api 的可读性和可维护性比 Composition Api 要好。不过如果是在 Setup 函数里写 Composition Api 的话确实有一点乱。
1000 行感觉也不是大问题,代码复杂程度不是用行数衡量,只是单纯罗列的话,多少行也不会影响可读性。
ali233
64 天前
@Vegetable 是的,但是 xxx 的意思是不准备制定规范,而是继续按照之前不同项目中不同的写法来开发
ali233
64 天前
@shintendo 了解,我之前的开发理念是认为请求文件大部分情况是需要按照页面改拆分,如果某一块页面的相关请求都是会定义在单独的文件里,而不是整个项目中的请求全写在一块。这有利于在查看请求的时候,在一个文件中即可看到当前页面全部
yor1g
64 天前
review 的人怎么说
otakustay
64 天前
我觉得对方是比较有理的
3 这个问题,如果 1000 行代码里每个函数是独立且行数不多的,那么就不应该存在可读性问题,按函数名找就行了
4 这个事,你干你也麻,它是现实
ivvei
64 天前
台资?既然最后说现阶段不要求规范,那还唧唧歪歪个啥,怎么跑你这规范来规范去的。明明每个人风格都不一样,为什么又要让你保持和别人一致?这领导说了一大堆,一个站得住脚的理由都没有。1000 行能维护,3000 行就重写,理由呢,凭什么是 3000 不是 5000 。他就是得过且过型的吧,对技术毫无追求,所有的理论只是给自己不想变化不想接触新的东西硬拗罢了

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1072868

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX