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

[shanejix]

bug 计入绩效，末尾淘汰

一个 bug 搞得人整天都不好了

😭

[zyxyz123]

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

[cmdOptionKana]

交叉检查？

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

[luckyrayyy]

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

[estk]

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

[jiangshanmeta]

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

[bzw875]

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

[magewu1223ll]

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

[FallenMax]

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

[Biwood]

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

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

[wenzichel]

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

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

[morize]

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

[pengtdyd]

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

[wzzzx]

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

[Baymaxbowen]

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

[wd]

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

[Pastsong]

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

[Leviathann]

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

[shanejix]

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

[shanejix]

@estk 测试环境

[shanejix]

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