最近入职了一家公司 领导在 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 写法
````
1. > 能 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 项目上还是很好用的话，那么这通常是有问题的
欢迎大家理性讨论，不知是我过于追求代码洁癖了还是什么 |
|
