最近入职了一家公司 领导在 review 代码的时候有一些分歧，我跟他聊了一些问题
- 使用最新的 vue3 技术，而用着老旧的 vue2 的写法
- 能 1 行代码解决 10 行代码，但是非要用 10 行代码的写法
- 长达 1000 行请求（定义请求 url 的）的代码文件，不做任何拆分处理，页面上所有请求都写到这个文件中
- 目前我维护的几个前端项目每个项目都是不同的写法
对于以上几点，以下是我跟领导的讨论记录
-
使用最新的 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 行代码解决 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 } -
长达 1000 行请求（定义请求 url 的）的代码文件，不做任何拆分处理，页面上所有请求都写到这个文件中
我： 请求文件中代码量已经非常大，快接近 1000 行，继续往里写可读性会越来越差
export default { async getListData = () => { return axios.get(xxx) }, async getUser = () => { return axios.xxx }, xxx... }xxx: 現階段我不覺得這是個問題，我也不覺得可讀性有變差，而且對 reviewer 來說沒有多的心智負擔，只要順順看過去就知道在做什麼了。你可能會問說：「那之後變到 3000 行怎麼辦？」，我會說，到那個規模的時候，這個項目很多寫法都不適用了，那時八成會打掉重做，因此現階段這不是個問題
-
目前我维护的几个前端项目每个项目都是不同的写法
我： 之前前端这块没有前端规范是因为项目都在不同的人手里，每个人开发会有差异，那既然现在项目都是我们自己人在维护了，为什么不统一一下写法和规范呢（ PS: 大概 3-4 个项目，每个项目的写法都不一样）
xxx： 做任何事情都是需要成本的，如果沒有考慮到成本跟帶來的效益，那就只是種自我滿足而已 現在的前端系統不會常出 bug ，代表功能上沒太大問題，那會很難維護嗎？不會，雖然幾個項目彼此的風格可能有差，但盡可能維護項目內的風格是一致的，就算以前沒有一致之後，之後也會盡量一致 再來還需要考量項目之後的發展以及生命週期，之後還有很多新功能嗎？還是已經差不多了？那如果已經進入維護期了，重構的必要性是什麼？有些人只是覺得代碼看起來不順就要重構，沒思考過這個理由是不是合理，是不是符合效益 總結一句話大概是我認為目前沒有制定開發規則的必要性，現有代碼也暫時不需要大規模的重構
最后是领导对于团队规范的总结： 不同階段/規模的項目有不同的做法，1 個人的、10 個人的或是 100 人合作的項目，做法都不同，如果硬要把 A 項目的做法直接套到 B 項目上面，或是直接把以前習慣帶進來覺得這一套之前很好用，現在一定也很好用，那通常是有問題的
我理解这句话的意思一个公司中的团队规范如果在 A 项目中好用，然后套用到 B 项目上还是很好用的话，那么这通常是有问题的
欢迎大家理性讨论，不知是我过于追求代码洁癖了还是什么
第 1 条附言 · 4 天前
补充一下领导对于制定规范的长远看法：
xxx： 我可以很肯定告訴你現在如果訂了規範之後會怎麼發展 ，大概是花了一兩週訂規範，訂完之後過三個月發現訂規範的人離職了，然後新來的人不知道有這規範，於是就照自己的習慣開發，接著知道有規範的人也都離職了，大概是這樣
86 条回复 • 2024-09-17 23:54:31 +08:00
 |
1
murmur 4 天前
1000 行能跑就行，现代的 ide 都有代码折叠和函数大纲预览功能，vue 的好处就是模版=html ，不像 react 如果不拆分组件，连基本的代码对齐都没法保证，
vue2 除了不够时尚，有完善的生态，没有严重 bug 和性能问题，选词填空写法更适合外包项目 |
 |
3
tool2dx 4 天前
公司项目不都是要妥协的嘛。什么都能顺心写的，那是个人项目。
xxx 说的也没错，代码写那么飘，哪天你走了，谁来维护这一堆屎山。 |
 |
4
ali233 OP @murmur 怎么说呢 也不外包项目，当然也可以理解 vue2 的写法，介意的点是已经用了 vue3 了但是不惜专门写一个函数来把 setup return 的值包裹成类似 vue2 的写法
|
|
5
ali233 OP @tool2dx 这句话确实没错，但是现在的情况就是好几个项目都是杂乱无章的写法，现在好几个项目都在我们这里维护，想着为什么不可以在开发的时候把这几个项目统一一下写法和规范
至于屎山和后续维护，在统一代码和规范之前肯定会先跟团队一起讨论出统一的写法 |
 |
6
vikaptain 4 天前
最后是领导对于团队规范的总结： 不同階段/規模的項目有不同的做法，1 個人的、10 個人的或是 100 人合作的項目，做法都不同，如果硬要把 A 項目的做法直接套到 B 項目上面，或是直接把以前習慣帶進來覺得這一套之前很好用，現在一定也很好用，那通常是有問題的
|
 |
7
NoobNoob030 4 天前  1
年纪越大，越固守成规
|
 |
10
liaozzzzzz 4 天前 via iPhone
这属于公说公有理婆说婆有理的问题了，我建议还是好好定一下团队规范，新的模块可以按照新规范来玩，旧的部分需求没大变化的场景下就维持稳定…
|
 |
11
Vegetable 4 天前
xxx 说的都很有道理
我认可的理由是：尊重现有项目的一致性是很有必要的，你的理念都是对的，但是对于一个稳定项目，在不打算根治的情况下，尽量先别打破他。你想写更好的代码，第一步不是先把代码写进去，而是制定新的规范。 |
|
12
ali233 OP @vikaptain #8 关键点就是项目团队中现在没有统一的规范， 如果一个规范在一个项目中适用，然后在另一个项目中也适用的话我会认为这是一个蛮不错的规范，再基于实际情况做调整也是可以理解的
|
 |
13
bojackhorseman 4 天前
等一个 vue4 把 options 写法支持砍掉
|
|
14
ali233 OP @liaozzzzzz 最后讨论的结论是不需要团队规范，继续按照之前的各个项目中不同的形式来开发
|
 |
15
shintendo 4 天前
Options Api ≠ Vue 2
如果不用 TypeScript 的话，我认为大多数情况下 Options Api 的可读性和可维护性比 Composition Api 要好。不过如果是在 Setup 函数里写 Composition Api 的话确实有一点乱。 1000 行感觉也不是大问题，代码复杂程度不是用行数衡量，只是单纯罗列的话，多少行也不会影响可读性。 |
|
17
ali233 OP @shintendo 了解，我之前的开发理念是认为请求文件大部分情况是需要按照页面改拆分，如果某一块页面的相关请求都是会定义在单独的文件里，而不是整个项目中的请求全写在一块。这有利于在查看请求的时候，在一个文件中即可看到当前页面全部
|
 |
18
yor1g 4 天前
review 的人怎么说
|
 |
19
otakustay 4 天前
我觉得对方是比较有理的
3 这个问题，如果 1000 行代码里每个函数是独立且行数不多的，那么就不应该存在可读性问题，按函数名找就行了 4 这个事，你干你也麻，它是现实 |
 |
20
ivvei 4 天前 via Android 1
台资？既然最后说现阶段不要求规范，那还唧唧歪歪个啥，怎么跑你这规范来规范去的。明明每个人风格都不一样，为什么又要让你保持和别人一致？这领导说了一大堆，一个站得住脚的理由都没有。1000 行能维护，3000 行就重写，理由呢，凭什么是 3000 不是 5000 。他就是得过且过型的吧，对技术毫无追求，所有的理论只是给自己不想变化不想接触新的东西硬拗罢了
|
|
22
ali233 OP @otakustay 主要还是先解决了 4 其他其实都迎刃而解了，现在就是每个项目写法都不一样，但是领导也不准备说制定统一的规范
我的想法是可以先制定统一的规范，在迭代需求的时候慢慢就按照规范来统一写法了 |
 |
24
aolyu 4 天前
看 review 的重点是什么，是语法规范问题还是代码漏洞问题（我想大部分都是为了避免代码漏洞）
这个项目大概率是从 vue2 迁移为 vue3 ，项目比较久远但稳定，大部分人是不会因为新增或修改一个需求而去动所有逻辑，更倾向选择一个更加简单且不容易出错的写法，从项目层面来说没什么问题。 确实，vue3 可以使用一些好的写法来完成需求，但是对于一个项目来说，稳定才是最重要的（想要使用更加简洁且方便的语法没问题，你改了，没人会知道，老板也不会认为你多牛；但是如果改出问题了，所有人都会知道，老板会认为你能力有问题） 补充：框架只是一个工具，不管是纯前端三剑客、angular 、vue 、react ，它们没有好坏，没有优劣，它们的目的都只是完成页面搭建，完成业务以及交互，只要能解决问题的都是好技术好工具。 最后：有好的想法和好的写法并提出是值得鼓励的，是我我也会提出你的这些问题，新需求和新业务我会使用简洁、高效的写法，但是大项目，老项目需要谨慎。 |
 |
25
HTML001 4 天前
又是老项目，你又没有话语权，那就按着之前的写法继续写。
后面又新项目你再建议用新方式来写。 领导会比较担心： 1.新写法出现问题没人能解决 2.团队里面都不接受新写法，你写了会让其他同事跟进不了 如果是情况 1 ，你就说你有把握解决这些问题；如果是 2 ，我会选择跑路。 |
 |
29
Felldeadbird 4 天前
1 ，2 ，3 都不是大问题。风格沿用即可。重构起来需要时间，吃力不讨好的事情。
第四点来说，无解。新旧项目你无法统一他们的风格了。已成事实，你推不动。 |
 |
30
shizhibuyu2023 4 天前
没毛病，要么尽量与原有风格保持一致，要么当个 OKR 来做，定下新规范并统一风格之后全部重构，并配好代码检验规则来强制执行，否则都是扯淡
|
 |
31
webmrxu 4 天前 via Android
1 、团队成员技术栈，习惯 vue2 写法
2 、项目进度赶，没时间重构，遇到新写法，有问题还得查资料影响进度 3 、很多第三方 npm 包还是 vue2 的写法，安装引入能不能适配？例如，别人的代码 vue2 写法，copy 过来，还得改一遍。 如果不是我的项目，我绝对不会重构，改架构，要不就是你工作量不饱和，闲的。 |
 |
32
iOCZS 4 天前
写法问题不大，但是大文件拆分还是必要的
|
 |
33
aker91 4 天前
你的领导更合理，也更符合实际，他负责项目的时间比你更长，以后大概率也比你长，重构的代价非常大，之前的项目使用什么规范就尽量沿用，你想用更新的写法或规范是开发感受问题，但你想想以后接替你维护的人他们会有什么感受
|
|
34
ali233 OP @webmrxu 1. 如果是习惯 vue2 的写法最开始搭建项目就不会直接搭建 vue3 的项目了
2. 现在项目中只有我一个人在开发维护，所以说不会影响进度 3. 其实和第一个问题是同样的解法，项目中搭建之初就是用的 vue3 ，没有什么需要适配的 关于最后重构的观点，其实并不算是在重构项目，只是在开发新功能的时候顺手改掉了老写法而已，写的更简洁了 |
|
35
ali233 OP @aker91 有一个前置条件是现在前端这块只有我跟领导在开发维护，所以我其实想表达的意思就是既然都是我们在维护，后续统一一下写法不是更好的事嘛
而且并不是直接全部重构，只是说先统一一下，后续新需求的写法都可以按照这个规范来实施 |
 |
36
zcf0508 4 天前
我之前接手的旧项目，我直接来一个大重构，补 ts ，拆包拆组件，调整 eslint 规范，调整 vuecli 配置，前前后后用了不到一个星期，git 记录有 3w 行+ 和 2.6w 行- 。既然你项目到我手里了，那我就按我的习惯调整。
如果有人把这种脏活累活干了，领导还是不愿意接受，那就是领导的问题了。 --- 1. options 和 composition api 各有优势，包括 jsx/tsx ，都不是互相排斥的，需要在对应的场景使用适当的方案。 2. 逻辑耦合度高，或者复用性比较强的，可以提取和抽象。没有必要只是为了代码行数做优化。 3. api 写在一起问题不大，但是最好改造成 esm ，有利于构建工具进行 tree-shake 。既然改造了，按模块拆分一下也是合理的。 3. 每个项目有自己的情况，在没有通用的脚手架或者统一规范前是没有办法避免代码风格不一致的问题的。只能尽力去优化。 |
|
37
zcf0508 4 天前
另外 vue2 升级到 2.7 可以使用 composition-api 。我的 vue2 项目都是混着写的。
|
 |
38
yhxx 4 天前
其实很简单，核心就是，做这件事对他有什么收益吗？
他给他的老板的汇报 PPT 上写“把一个 1000 行的文件拆分成 4 个” 你觉得他老板会认为他做了有价值的事吗？ |
 |
39
SanjinGG 4 天前
接口拆分下就行了，其他的你无能为力。如果你没话语权，维护好自己的模块就行。
|
 |
40
Cu635 4 天前
1 和 2：恐怕是之前有过用代码行数评定 kpi 的时期。
|
 |
41
jjwjiang 4 天前
评估你的方案、effort 和收益。
本质上是你没能说服你上级，没能说服的原因是这些点上他都有能自洽的道理而你的道理也自洽，但是并不能取得压倒性的胜利。 比如你那个 hooks 的例子，你能看到有人曾经因为这个写法产出过 bug ，最后增加了多少工时，那这就是一个可以说服的点，相比你的写法的心智负担，降低了 bug 产生率，等等等，而心智负担你可以通过注释、wiki 之类的东西来降低影响。 或者说哪次扩展功能，结果需要修改大量重复代码等等。 如果你发现你列不出合理的例子和收益，那说明这事他说得对，你自己没想明白。 代码是为项目服务的，你又不是在做开源。 |
 |
42
Hanser002 4 天前
如果团队和领导对于 `review` 这件事的导向是维持项目稳定，那就不要折腾了，毕竟人是要“合群”的。
4 里面说了 `目前我维护的几个前端项目每个项目都是不同的写法`，但是 2 用了更现代的方案反而被打回。我理解之前的团队和领导也没有做好团队规范，领导给你描述的只是他认为/习惯的方式。说不好听点，就像国内很多团队一样，我升级到 vue3 ，但我还用 vue2 的写法；我引入 ts, 但是只用 any 。如果不能接受升级框架带来的新的规范、新的写法、新的库，那就没有必要升级，更何况 `vue2` 已经停止维护了。 对于 2 而言， `useQuery` 就是 `vue3` 请求的范例，你领导的代码就是繁琐、过时、低效，为什么有封装好的不用要自己写。如果一个组件有多个请求，参数之间有竞争，是不是还要手动去处理这些关系？我 review 碰到这种请求方式都是直接打回，自己手动去管理这些状态往往会出问题。这么看下来 “做任何事情都是需要成本的，如果沒有考慮到成本跟帶來的效益，那就只是種自我滿足而已” 这句话只是你领导不学不会不练的托辞。 |
|
43
ali233 OP @jjwjiang 本质就是理性在跟领导讨论这个话题，但是后面他越说越有点厌烦的感觉，所以我也没有再深入讨论下去了
对于 hooks 的列子我在跟他讨论的时候已经列了好几个收益和示例了其实还是他最后的那一句话 ： 不愿意使用新写法 |
 |
44
kiroter 4 天前 1
就是老古董不接受新事物而已，看不懂又不好意思问。
|
 |
45
colorcat 4 天前
没有太大意义，卷要向能给项目赚钱的方向卷
|
 |
46
zy0829 4 天前
能跑就行了，打工人别难为打工人
|
 |
49
Daotin 4 天前
1,2,3 问题不大，但改起来麻烦，需要成本，大可不必，而且对自身成长没有啥帮助。
4 ，领导说的对，老项目不动它，既没成长，亦无收益，动它作甚。 以后的新项目，再采用统一的标准。 以上为个人观点。 |
 |
51
1094705286 4 天前
领导不去学习吗？墨守成规，固步自封。
|
 |
52
wtf12138 4 天前
代码重构，没出问题领导没啥好处，出了问题领导背锅
|
 |
53
lisongeee 4 天前
示例有问题， <script setup> 里面不能写 export default
|
 |
55
iyaozhen 4 天前
楼主你说这些没用，还不如找机会去大公司
至少我所在的团队，提这些是没人反对你的，最多只是细节上的问题 |
 |
56
Razio 4 天前
2 我也确实不能理解，就算 useRequest 这个写法加进来又怎样呢，和 4 是不是自相矛盾。
其他的没办法，凑合干吧，理想和现实的差距。有时候要学会说不，但大部分情况还是多一事不如少一事来的顺心，学会放下 |
 |
57
iceprosurface 4 天前
对于问题 1：
要么直接用 option 要么直接用 setup ，目前看这个写法出了麻烦没什么好处，如果是老项目我建议不改，如果是新写，就不要沿用了。 对于问题 2: 对于老项目，重构价值不大的，你领导说的对，不要改，对于新维护，维护频率高的，你可以据理力争改改 对于问题 3: 对于 api 请求我的观点是多少行都无所谓, 应该尽量自动生成，有类型（ PS: 我们项目里面的请求文件目前有 13300 行, 反正 idea 自动折叠无所谓,而且一般不用点进去看） 如果手动写的，确实应该是分模块封装起来用，你领导说的也对，过早的优化是没有必要的 对于问题 4: 按照你们现在这个情况，你领导说的对。因为要执行需要满足下面几个条件： 1. 严格执行 review ，且 review 要求高，必须是交叉 review ，review 不通过不给合并 2. 项目时间安排合理 3. 整个前端所有人达成共识才能执行的 4. 要有对应的规范指南，每个新人进来前两天必须熟读 5. 所有项目的 code style 、lint 规则一致 |
 |
58
pulengba 4 天前
领导”懒政“而已，做多错多，稳定是第一位的。
|
 |
59
AtlantaANiu 4 天前
如果贵司要求必须写单元测试，并以代码覆盖率作为考核目标，就能解决所有问题。风格再好，代码再漂亮，不写测试最终都会变成一坨大便。
|
 |
60
mikawang 4 天前
你们领导不注重开发体验，我们公司就很注重开发体验
|
 |
61
wusheng0 4 天前
1 不说了，vue3 主推的就是 hook 写法，用了 vue3 又因循守旧
2 见仁见智了 3 在一开始就应该考虑按照功能模块去拆分。再怎么清晰，放在一个文件也不如拆开来清晰 4 我赞同你领导的说法，任何事情都得考虑成本 |
 |
62
yeziqing 4 天前
事情都有多面性，每个人看问题（比如成本、产出）的角度不同而已。既然他是领导，那就以他为准，而且客观地说，领导说的也都没问题。
|
 |
63
sgiyy 4 天前
1 ，2 ，4 无解，作为领导，考虑项目的稳定性是第一位的，如果改动大组内其他人适应性如何也是一个问题。如果感觉提升不明显，建议跳槽...
3 我倒是想提一下：我觉得问题最大的点不在于上千行，原因在于这个文件没有什么复杂度，其实定位找个接口很容易。问题在于都封装在一个对象里，命名问题很大，到最后起名很麻烦和命名很长。 我习惯于按后端接口模块封装在若干对象里面，比如： ```javascript export const userAPI = { update: () => {}, get: () => {}, } export const todoAPI = { update: () => {}, get: () => {}, } ``` |
 |
64
jackding1208 4 天前
谁维护按谁的习惯来就好...
公司项目除了你自己没人会在意这些 |
 |
65
saviorjiang 4 天前
1.如果说你开发的页面，使用了 vue3 写法，后续有新人入职，因为之前的页面开发大部分都是用 vue2 的写法，你又没法约束的情况下，大概率会按照之前的写法去写。如果是项目开始就是 vue3 ，用 vue2 的写法，那确实很难理解。
按照新写法去优化，大概率后续是两种写法会共存，新人接手，我觉得会挺混乱的，就像 jquery 到 vue2 ，再到 vue3 ，三种写法共存（混乱至极）。 问题 2 ，我觉得加了也没啥啊，就当是封装了一个请求，项目里肯定也有各种封装。 问题 3 ，我个人觉得可能就是最开始规范制定的统一存放吧。 问题 4 感觉就是这种情况了，大家都是觉得有更好的写法，在不同项目导致不一样。这个也不能避免，规范也不能预判到技术的发展，从简单 ajax 请求，到封装请求，再到 useRequest ，后面或许有更好的写法也说不定，统一写法，就要对老项目进行重构或者优化，大部分公司都不愿意花时间专门去做的，毕竟收益不能提高 当然我个人更像 op ，更愿意优化。 |
 |
66
xz410236056 4 天前
“會沿用像 vue2 的寫法純粹是因為當時我們幾個一致覺得這種寫法比較好，比 vue3 那種自由奔放，全部宣告的變數都放進 view 裡面好”
纯粹懒得学习找的借口罢了，年纪大了后大多数人都懒得学新东西了 |
|
67
aker91 4 天前
@ali233 #35 项目长期维护基本只有两种情况，要么一直在更新，要么一直停留在某个版本，你如果能坚持更新的话，就先选一个项目把相关的某个规范全改掉，然后再去和你领导谈，大概率会通过
|
 |
68
dfkjgklfdjg 4 天前
如果做不到固定的开发工作流，确保每一个 MR 都会 review 通过后才会被合并。
那么 OP 你关注于“技术”部分的规范，确实会补充中领导的长远看法一样。 --- 关于团队开发规范一般都是开发团队中互相理解认可，最终达成一致的规范。而不是一两个人拍脑袋确定下来的。 至于项目 A 使用，不代表项目 B 也适用。其实和团队 A 认可，不代表团队 B 也会认可一样的。 比如你的举例就很“技术”，并不是一个对于开发流程的规范，更像是 Lint 相关的规范（也就是 Coding Style ），那么确实并不一定适用所有项目。 --- 比如你可能会觉得<问题 1>很不爽，但是可能项目开始时期 `script:setup` 并没有实现，所以当时只是使用了 `setup` 并没有使用 `script:setup`。 那么按照你<问题 4>的认定，你多半也不会认可在一个项目中同时出现选项式和组合式两种写法。那么比较合适的情况就是延续旧有的“开发规则”，继续使用 `setup` 开发而不是 `script:setup`，而不是全部重构成 `srcipt:setup`。 至于<问题 2>和<问题 3> 是出于一个中间地带，首先代码量少并不一定就是“好代码”，举个很极端的例子 `const result = condition1 ? condition2 ? 'A' : 'B' : condition3 ? 'C' : 'D';` 虽然示例和 OP 你表达的并不一样，我这样举例有一点抬杠的意味，但想表达的是 代码结构清晰，可以让所有人都可以快速理解的代码，才是真的“好代码”。 不知道你举例的 `useRequest` 是 [VueUse]( https://vueuse.org/core/useFetch/) 这种比较大众的工具类库提供的，还是自己内部实现的工具类库。 API 都声明在一个 `index.js` 文件中，我也觉得会是一个问题，但是可能开发团队已经习惯了直接使用 `import { xx } from '@api' 中引入对应的接口了。 可以贡献一个模块化拆分后 API 维护的 MR ，并且提供和原本一样的聚合后的 `@api/index.js`出口（`export * from './modulesA'`）。 这个 MR 就可以当成首次 review 的一个样例。 --- 但是 OP 你得和你的领导确定好，你们想要制定的规范是什么，是开发流程的规范，还是编码风格的规范。 开发流程的规范当形成习惯之后是可以随团队一直延续、传承下去的，但是编码风格的规范会随着不同项目的主导人而不同的。 |
|
69
ali233 OP @dfkjgklfdjg 现在工作流就是这样的 需要 approve 后才可以合并代码进主分支，且团队现在就我跟领导两人开发前端
举例的 useRequest 就是比较大众的工具类库提供的，我是感觉写法会比之前那种写法简洁许多而且也方便阅读 API 声明在文件中并不是用的时候 直接 `import { xx } from '@api' ` 而且在 index.js 中写了一个 class instanceClass ，在各个地方调用接口的时候需要 await instanceClass.getAxios.getData() 我尝试过拆分这个文件，被直接打回了。 最终是全部删掉重写了这块代码 |
 |
70
vaporSpace 4 天前
我们团队 vue 的写法就已经有好几种了，用 tsx 、jsx 、composition api 、Options Api ，还有看心情混着用的，再加上不同项目 vue2 、vue3 都有，有的用 vue-cli 有的用 vite ，没点前端基础哪玩得转 vue 呀，还没提开发组件怎么兼容 vue2 、3 呢。哪怕是用 composition api ，有的人是 script setup ，有些人还是保持 component setup 。随便怎么写吧，我已经无所谓了，我自己写就偷偷用 tsx 哈哈
|
 |
71
beidounanxizi 4 天前
绝大部分时候 review 是政治斗争 是话语权
先听你领导的 他说了算 除非你觉得那领导 那那都特傻 x 都是打工的 何必呢 刚入行 觉得别人写的 看不顺眼 或者有些轴的人 特别喜欢追求自己心中的 当然也有特傻逼的 绕开走就行了 既然是你领导的 先听他的 让他舒服了 再提些自己的小意见 领导也能接受 你说的这些 何况也不都是你对 |
 |
72
Terryx 4 天前 via iPhone
你一来就要重构，还要重新定规范，我感觉你更像领导。
真重构，定了规范，有好处你出头，出了问题你领导背锅，而且你这是在抢领导力，傻叉领导才会同意。 你有本事自己弄个厉害的，让别的同事佩服不已，自愿来找你求教，这才能正道。别对老代码指手划脚，你不知道当年的妥协。 年轻要有敬畏之心。 |
 |
73
yanqing07 4 天前
@ivvei #20 我也觉得这领导没水平，而且还“懒”。
明显前后回答就有矛盾。最后那个理由非常没水平，规范定了就要写下来文档，后面进来的人就是要按规范开发，代码审核人也是按规范审核。什么人走了规范就没了，他明显就没“水平”做技术管理。 按他说的，eslint 里面那么多大厂风格大家都不套用呗。基本规范就应该是要有的，具体项目具体分析也是要有的。 这领导就是技术水平不够，全靠一张嘴。 而且，看到 await 再加 then 的写法，就知道没人 review 才出现这种乱七八糟的代码 |
 |
74
Garwih 4 天前
看起来你领导好像不知道 ESLint 这种工具的存在。
另外，用 Vue 3 还坚持用 Options API 本质上就是不想学新东西，Composition API 有更好的 TS 支持，关联逻辑可以放到一起，而不用必须分散到各个 option ，会用的话应该写得比 Options API 更清晰易懂。 |
 |
75
iidear2015 4 天前
制定规范是为了保持统一，便于交流和协作。大家都觉得简单易懂的代码就是好代码。
对技术有热情，挺好的。布道技术是一件难事。 领导虽然不认同，但还是认真和你讨论，也挺好的。不妨试试和团队其他人聊聊，或者内部做做分享讨论 |
 |
76
irisdev 3 天前
老项目就用老写法，不觉得有什么问题
|
 |
77
darkengine 3 天前
如果是线上项目，改完之后有测试人员把所有 use case 回归一遍不？
|
 |
79
dingyaguang117 1 天前 via iPhone
你们领导说的对，是个实用主义和返璞归真的人
|
|
80
dingyaguang117 1 天前 via iPhone
|
 |
81
slmaaw 1 天前 via Android
从纯开发角度考虑你的结论是没有问题的，但是代入管理者角度，你还是听领导的，他说的对，你觉得不对，只能是你没做过管理，或者做管理的经验不够丰富
|
|
83
ali233 OP @iidear2015 嗯嗯 感谢回复的建议
|
|
84
Garwih 1 天前
@dingyaguang117 #80 比如你一些 data 、computed 、watch 和 method ，他们之间只是互相关联并且跟其他的没关联，用 composition api ，你是可以放到一块的。而你用 options api ，你只能分别分散到每个 option 里。抽出去你如何组合起来？还不是得引用进来，最终跟直接用 options api 也没多大区别。
看官方这部分其中的对比图就清楚了。 https://vuejs.org/guide/extras/composition-api-faq.html |
|
85
dingyaguang117 1 天前
@Garwih 是的 这个图我也看过（毕竟是官方文档里的），不过 IDE 里可没有这种智能的染色，看别人代码还是一样的觉得乱。 当然也可能只是因为看别的代码的原因。
|
|
86
dingyaguang117 1 天前
代码清晰我觉得最大的影响因素在于 变量的命名、结构的组织（包括文件拆分和文件内组织， 以及单一职责）、注释。
可能我觉得 vue3 不好用的主要原因是概念太多，引入的复杂度不足以弥补 块内聚的好处。也有可能是 vue3 写得少吧。 |
Select Language