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

5 天前
 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 项目上还是很好用的话,那么这通常是有问题的

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

3644 次点击
所在节点    职场话题
86 条回复
ali233
5 天前
@yor1g 反正最后的结论是不准备制定和统一规范 继续按照之前不同项目中不同的写法来开发
ali233
5 天前
@otakustay 主要还是先解决了 4 其他其实都迎刃而解了,现在就是每个项目写法都不一样,但是领导也不准备说制定统一的规范

我的想法是可以先制定统一的规范,在迭代需求的时候慢慢就按照规范来统一写法了
otakustay
5 天前
@ali233 #22 4 这个事,必须用 ROI 的视角谈,而不是“应该这样做”去谈。你要干,就和领导讲明白 ROI 是什么,长线收益啥时候能回来
aolyu
5 天前
看 review 的重点是什么,是语法规范问题还是代码漏洞问题(我想大部分都是为了避免代码漏洞)
这个项目大概率是从 vue2 迁移为 vue3 ,项目比较久远但稳定,大部分人是不会因为新增或修改一个需求而去动所有逻辑,更倾向选择一个更加简单且不容易出错的写法,从项目层面来说没什么问题。

确实,vue3 可以使用一些好的写法来完成需求,但是对于一个项目来说,稳定才是最重要的(想要使用更加简洁且方便的语法没问题,你改了,没人会知道,老板也不会认为你多牛;但是如果改出问题了,所有人都会知道,老板会认为你能力有问题)

补充:框架只是一个工具,不管是纯前端三剑客、angular 、vue 、react ,它们没有好坏,没有优劣,它们的目的都只是完成页面搭建,完成业务以及交互,只要能解决问题的都是好技术好工具。

最后:有好的想法和好的写法并提出是值得鼓励的,是我我也会提出你的这些问题,新需求和新业务我会使用简洁、高效的写法,但是大项目,老项目需要谨慎。
HTML001
5 天前
又是老项目,你又没有话语权,那就按着之前的写法继续写。
后面又新项目你再建议用新方式来写。
领导会比较担心:
1.新写法出现问题没人能解决
2.团队里面都不接受新写法,你写了会让其他同事跟进不了
如果是情况 1 ,你就说你有把握解决这些问题;如果是 2 ,我会选择跑路。
ali233
5 天前
@aolyu 大概率是语法规范,这个项目是直接 nuxt 搭建的 vue3 项目,所以我最开始是不太理解问题 1 的
ali233
5 天前
@otakustay #23 受教了 下次可以尝试一下
ali233
5 天前
@HTML001 现在团队就我跟领导开发前端
Felldeadbird
5 天前
1 ,2 ,3 都不是大问题。风格沿用即可。重构起来需要时间,吃力不讨好的事情。

第四点来说,无解。新旧项目你无法统一他们的风格了。已成事实,你推不动。
shizhibuyu2023
5 天前
没毛病,要么尽量与原有风格保持一致,要么当个 OKR 来做,定下新规范并统一风格之后全部重构,并配好代码检验规则来强制执行,否则都是扯淡
webmrxu
5 天前
1 、团队成员技术栈,习惯 vue2 写法
2 、项目进度赶,没时间重构,遇到新写法,有问题还得查资料影响进度
3 、很多第三方 npm 包还是 vue2 的写法,安装引入能不能适配?例如,别人的代码 vue2 写法,copy 过来,还得改一遍。

如果不是我的项目,我绝对不会重构,改架构,要不就是你工作量不饱和,闲的。
iOCZS
5 天前
写法问题不大,但是大文件拆分还是必要的
aker91
5 天前
你的领导更合理,也更符合实际,他负责项目的时间比你更长,以后大概率也比你长,重构的代价非常大,之前的项目使用什么规范就尽量沿用,你想用更新的写法或规范是开发感受问题,但你想想以后接替你维护的人他们会有什么感受
ali233
5 天前
@webmrxu 1. 如果是习惯 vue2 的写法最开始搭建项目就不会直接搭建 vue3 的项目了

2. 现在项目中只有我一个人在开发维护,所以说不会影响进度

3. 其实和第一个问题是同样的解法,项目中搭建之初就是用的 vue3 ,没有什么需要适配的

关于最后重构的观点,其实并不算是在重构项目,只是在开发新功能的时候顺手改掉了老写法而已,写的更简洁了
ali233
5 天前
@aker91 有一个前置条件是现在前端这块只有我跟领导在开发维护,所以我其实想表达的意思就是既然都是我们在维护,后续统一一下写法不是更好的事嘛
而且并不是直接全部重构,只是说先统一一下,后续新需求的写法都可以按照这个规范来实施
zcf0508
5 天前
我之前接手的旧项目,我直接来一个大重构,补 ts ,拆包拆组件,调整 eslint 规范,调整 vuecli 配置,前前后后用了不到一个星期,git 记录有 3w 行+ 和 2.6w 行- 。既然你项目到我手里了,那我就按我的习惯调整。

如果有人把这种脏活累活干了,领导还是不愿意接受,那就是领导的问题了。

---

1. options 和 composition api 各有优势,包括 jsx/tsx ,都不是互相排斥的,需要在对应的场景使用适当的方案。
2. 逻辑耦合度高,或者复用性比较强的,可以提取和抽象。没有必要只是为了代码行数做优化。
3. api 写在一起问题不大,但是最好改造成 esm ,有利于构建工具进行 tree-shake 。既然改造了,按模块拆分一下也是合理的。
3. 每个项目有自己的情况,在没有通用的脚手架或者统一规范前是没有办法避免代码风格不一致的问题的。只能尽力去优化。
zcf0508
5 天前
另外 vue2 升级到 2.7 可以使用 composition-api 。我的 vue2 项目都是混着写的。
yhxx
5 天前
其实很简单,核心就是,做这件事对他有什么收益吗?
他给他的老板的汇报 PPT 上写“把一个 1000 行的文件拆分成 4 个”
你觉得他老板会认为他做了有价值的事吗?
SanjinGG
5 天前
接口拆分下就行了,其他的你无能为力。如果你没话语权,维护好自己的模块就行。
Cu635
5 天前
1 和 2:恐怕是之前有过用代码行数评定 kpi 的时期。

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

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

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

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

© 2021 V2EX