你们会修复潜在的 bug 吗

[jugelizi]

接手别人的项目 有些隐藏的 bug
测试发现不了 你们会主动花时间修复吗

[DHclly]

简单的会~

[daishankeke]

风险很高的话会优先修复
低风险的可能等手上没事了再修复吧

如果风险高又很复杂需要跟领导沟通下修复

[reus]

什么鬼逻辑？没来的同学请举手？

[tabris17]

众所周知，去做不计入 KPI 的工作都是在浪费生命

[DoUSeeMe]

那肯定的，潜在的 bug 都写了 TODO，等回头有空了来处理

[johnchshen]

这玩意叫技术债务，能还必然要还。
另外接手的工作要小心，有些时候看似 bug，实则需求。修复反而出错。
所以我个人比较反感在代码上玩奇技淫巧的，尤其不写单元测试和文档那种。

[onfuns]

小问题可以改改，牵涉广的最好别改，当然了，最后发现了还是你改，但至少可以辩称甩一下锅~

[cco]

不改。改好了没人知道，改坏了这就是你的锅。但是多少心里有个谱，等救火的时候就可以表现一波了。当然这是对待 996 的公司。如果公司氛围比较好，那还是有点责任心。

[cccssss]

问自己领导 X
问网友 √

[qiayue]

不要偷偷的修，还是要交流，不然改完你发现，原来之前是故意这样设计的

[libook]

建议先深入了解技术实现、业务细节、代码变更历史及原因，刚接手的代码可能自己觉得有问题，但有可能是历史原因导致必然写成这样的。

除非是与业务、算法完全无关的问题，但是编程语言的一个指令往往在不同情况下可以表达出多种特性，所以难说改完后一定不会对程序的执行预期产生影响。

如果真的全面且细致地了解过了，最终确认确实是缺陷，则建议按照其风险和修复成本以及未来的变更计划来规划修复计划，毕竟有可能一个整体大重构就使得很多小问题不用解决了。

[sm0king]

之前会。
现在不会。

[sean10]

有单测可以改，没单测只能找懂这部分代码的领导确认

[raaaaaar]

测试发现不了？逻辑错误吗。。

[daozhihun]

非常简单并且确认没啥问题的会（比如按钮文字不对等）。
其他的要和产品（或者 leader ）商量，不建议默默地改掉

[iMiata]

既然是 bug，肯定是可以测试出来的，没测试出来估计可能是测试没有想到这种操作逻辑？
既然项目到你手上了，bug 肯定要修的，现在不修难道等到生产环境发现了以后熬夜加班修么

[wangritian]

汇报一下比较好，注明运行环境、参数和结果，让主管定夺
如果 bug 是在职人员负责开发的，私下跟他讲

[no1xsyzy]

有单测？先写单测让它 fail，指不定你想象中会 fail 的情况结果单测写出来不 fail 那不是很尴尬？看自己几个月前写的代码，感觉有 bug，先 REPL 里试下…… 咦没毛病，咋回事啊？哦原来我早已考虑到了。我可真牛逼（
没单测？那先写出这个项目的第一个单测吧……

[DJQTDJ]

领导知道还好，领导不知道，行嘞，你就改呗。
改好了没你啥事。改坏了一查历史，你就吃鳖了

[yousabuk]

不会，你修了是别人写的好，会算到你头上？
干嘛修呢

[limuyan44]

bug 可以修，但是不要偷偷修，那就是在坑人了。

[luoleng]

顺手就修，不顺的话以后有时间再修，没时间的话就不修。。。

[OHyn]

改完要充分测试。。这种边缘情况有时候会改坏掉。。。

[wctml]

我的责任心不允许我放过任何 bug

[maichael]

先要确定是 bug 还是 feature

[hantsy]

一直在写 Bug

[SmiteChow]

那叫待优化重构点,未影响用户使用的不叫 bug

[FlexGap]

不改