提前预判问题解决 bug,还是等 bug 暴露出来再解决

bug 不暴露出来那就不算 bug

看你的离职时间

提前预判，到线上才发现 Bug ，大一点的那就是事故了

通常都是每个人负责一些模块，如果你负责的模块总出线上 Bug ，那么__

这个职业规划问题两千多年前就被回答过。
魏文王问扁鹊：“子昆弟三人其孰最善为医？”扁鹊曰：“长兄最善，中兄次之，扁鹊最为下。”魏文王曰：“可得闻邪？”扁鹊曰: “长兄于病视神，未有形而除之，故名不出于家。中兄治病，其在毫毛，故名不出于闾。若扁鹊者，（ chán ）血脉，投毒药，副肌肤，闲而名出闻于诸侯。”

那不叫预判，应该是兜底

防御性编程

看你们 KPI 怎么算

这问题的答案，不取决于技术或任何客观性的东西，完全取决于你的领导和公司的风格。要是“零 BUG”风格，你不管选哪个最后都要背锅。

正常情况下，都是问题越早发现越好的。CMMI 、ISO 体系（不是国内那种拿到资质就不再遵守的假体系），以及各大开源框架体系，选择的是前者，去看看开源框架的 Issue 库和版本发布文档就能看出来。

"等 bug 暴露出来再解决"

这操作明显是把 BUG 留给领导看的。

自己的项目有潜在 BUG ，肯定越早解决越好，根据二八原则，有 20%的时间写代码，80%的时间调试 BUG 。

先敲着，再没暴露出来的时候离职

等线上事故再解决？能预判肯定预判啊

是你个人的 bug 吗，严重到算绩效吗。

知道 bug 不改是什么操作…

突然想到之前的一张图，里面的内容大体是：

"魏文侯问扁鹊：“你兄弟三人，哪个软件开发水平最高？”
扁鹊说:“大哥最好，二哥其次，我最差。”
文侯甚为不解。
扁鹊解释道:“我大哥不等 Bug 出现就提前预防了，所以名声传不出开发组。二哥在 Bug 出现时就顺手解决了，所以名声传不出技术部。我呢，每天像打地鼠一般到处救火，所以在公司没人不知道我。"

能预判到的 bug 还是 bug 吗！

能预判到的都提前解决

不讨论绩效或甩锅情况，写代码还是要有边际。首先看是否能解决当前业务问题，之后考虑预判问题在所有情况不变情况下是否能正常运行。可以就可以不解决。就如写一个复杂 sql ，你知道短期内数据不会爆发增长执行速度可接受那就不用管。如果查询表一天是 100w 这种数据增加那就要解决一下逻辑了。

我的原则是看影响。你要提前预判到你的 bug 会产生什么影响
有的两小时就修了，那我就不管，到时候修还能给自己找 kpi
有的可能要涉及到运营、运维、测试等多人，折腾好几天或者通宵搞。这种就提前修，不然到时候苦的还是自己。当然你愿意这样做当我没说

你说的暴露，是指第二个开发知道，还是用户上报？

这边看到题目想到一句话, 善战者无赫赫之功

不好说，看公司风格

看是大 bug 还是小 bug ，大的 bug 要尽早解决，小 bug 等别人发现再处理

谋事在人，成事在天。
即用能想到的各种方法尽可能提前预知未来可能发生的 bug ，将其消灭在萌芽之中。
同时，还要对超出认知和能力范围的 bug 则保持一种乐观之心，不要祈求其不要发生，而是发生了及时地应对。

能预判出来的 bug 一般都不会成为 bug 。

除非你等着离职。