你们会修复潜在的 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

  不改