前端如何尽可能多的减少 bug，大佬们讲讲你们的方法论呗

bug

方法论

末尾

计入

41 条回复 • 2022-05-30 10:27:14 +08:00

1

zyxyz123

2022-05-29 09:22:43 +08:00

1

开启各种规范检查（ eslint 、tsconfig ）
写充足的单测
做好 code review
小心重构

2

cmdOptionKana

2022-05-29 09:26:37 +08:00

交叉检查？

你搞业绩搞淘汰，把人搞走了，人手不够工期太紧，会不会产生更多 bug 喔

3

luckyrayyy

2022-05-29 09:50:34 +08:00

排期排长点，充分的设计、开发、自测时间能消灭大多数的 bug

4

estk

2022-05-29 10:19:12 +08:00 via Android

上线 bug 计入绩效，还是测试部门测出来计入绩效？

5

jiangshanmeta

2022-05-29 10:21:16 +08:00

1

都末位淘汰了还不找个律师朋友咨询一下
写 bug 写多了吧

6

bzw875

2022-05-29 10:26:42 +08:00

1

更新简历，寻找机会，开始摆烂，坐等 N+1

7

magewu1223ll

2022-05-29 10:29:47 +08:00

1

@zyxyz123 实践证明，即使使用 code review 和 typescript 也并不能减少 Bug 数量，绝大部分情况下不是代码问题，而是业务逻辑的 bug

8

FallenMax

2022-05-29 10:37:29 +08:00

bug 少 = 高质量的代码，高质量的代码和 bug 计入绩效这种有毒制度 /氛围是负相关。

9

Biwood

2022-05-29 11:18:41 +08:00 via iPhone

唯一要求：后端提供完整的接口文档和假数据即可

如果还是容易出 bug ，那可能基本功还不到位，试着写写静态类型语言，比如 TypeScript 或者 Go ，不要被 JavaScript 惯坏了

10

wenzichel

2022-05-29 11:39:27 +08:00

2

以 bug 量来考核绩效的，就是专门搞人走的，建议早点走。

如果实在走不了的，延长开发时间，写单元测试！

11

morize

2022-05-29 11:44:40 +08:00

复杂的 bug 没啥经验，就说最常见的两个低级 bug 吧。
1. typo 。完善的 typescript 类型可以很大程度上避免 typo 带来的低级 bug 。
2. xxx is undefined 。数据结构复杂的话，而且没信心的话，多用 ?. 吧。
另外，涉及到复杂接口调用的，抓包确认调用链没有问题。

12

pengtdyd

2022-05-29 12:16:10 +08:00

怎么不以代码行数考核绩效，哈哈

13

wzzzx

2022-05-29 13:02:29 +08:00

以 bug 来考核绩效，趁早润吧还是。。。

14

Baymaxbowen

2022-05-29 13:15:34 +08:00

没啥用,纯粹就是浪费精力,还不如好好的 review 这样至少之后出现 bug 了还能看懂写的什么

15

wd

2022-05-29 13:16:33 +08:00 via iPhone

3

给你说了你可能不信：功能越少 bug 越少..

16

Pastsong

2022-05-29 13:36:22 +08:00

3

写的越少 bug 越少，能复制粘贴就复制粘贴，不重构代码就不给自己创造写 bug 的机会。
这种考核方式就和按行考核没啥区别

17

Leviathann

2022-05-29 14:07:46 +08:00

那产品的考核里有没有产品设计的详尽性和稳定性？

18

shanejix

OP

2022-05-29 14:42:52 +08:00 via Android

@luckyrayyy 确实，自测场景没覆盖完

19

shanejix

OP

2022-05-29 14:43:39 +08:00 via Android

@estk 测试环境

20

shanejix

OP

2022-05-29 14:45:11 +08:00 via Android

@jiangshanmeta 并没有，挂 bug 这事影响心情

21

shanejix

OP

2022-05-29 14:46:33 +08:00 via Android

@magewu1223ll codereview 只会看风格和质量，业务逻辑管不了，还得自己消化

22

shanejix

OP

2022-05-29 14:47:04 +08:00 via Android

@FallenMax 确实

23

shanejix

OP

2022-05-29 14:47:55 +08:00 via Android

@Biwood 老项目，上 ts 不能了

24

shanejix

OP

2022-05-29 14:49:21 +08:00 via Android

@wenzichel 综合上面，也只能对每一行代码负责，写单测，花时间自测了

25

shanejix

OP

2022-05-29 14:50:38 +08:00 via Android

@Pastsong 是的，哈哈

26

shanejix

OP

2022-05-29 14:51:11 +08:00 via Android

@wd 没毛病

27

Planarians

2022-05-29 14:58:58 +08:00 via iPhone

还找什么 bug 赶紧找下家吧

28

danhahaha

2022-05-29 15:06:23 +08:00

香蕉越大香蕉皮越大

代码越少 bug 越少

29

liaozzzzzz

2022-05-29 15:49:01 +08:00

排期的时候把这种场景考虑进去, 花时间多覆盖测试场景吧; 单测前期需要投入更多的时间也挺麻烦的
(我们也是测试环境 bug 达到某种级后算绩效, 不过和测试关系搞好基本上也不提那种程度的 bug 了

30

creanme

2022-05-29 17:57:22 +08:00

你们测试写测试用例不？你开发完以后对着测试用例测一遍，然后举一反三，想想边缘情况，会不会出现 bug 。

31

IvanLi127

2022-05-29 20:02:45 +08:00 via Android

0 产出 = 0 Bug 。可以摸鱼了

32

haah

2022-05-29 20:08:28 +08:00

转后端

33

FreshOldMan

2022-05-29 21:18:01 +08:00

跑路🏃🏻‍♀️

34

fgk

2022-05-29 21:28:11 +08:00

1

TS ，单测，代码审核

35

Torpedo

2022-05-29 22:01:07 +08:00

这种问题的核心不是怎么样才算一个 bug 吗？一个 bug 这种东西本来就是没有标准的

前端文案也很多的。就比如我上面那句话，问好后面多了一个空格，这算 bug 吗？

最后还是落到了人上面

36

haohong725

2022-05-29 22:08:51 +08:00

不写代码不就没 bug 了嘛

37

caisanli

2022-05-29 22:15:44 +08:00

提前对完接口后面的时间对着测试用例（测试人员提供）改到提测时候应该能减少很多 bug

38

Features

2022-05-30 01:06:10 +08:00

前端是真滴卷啊

39

zyPro

2022-05-30 08:01:58 +08:00

@caisanli 对着测试用例过两遍。基本没什么 bug 了，剩下只是意外情况了

40

7gugu

2022-05-30 09:10:29 +08:00

排期拉长，留多点 buffer ，只要测试时间允许，多让测试测一下，多用 TS 的类型检查，避免小错误，开启 eslint

41

m319

2022-05-30 10:27:14 +08:00

多做多错，少做少错，不做不错