阅读本文大概需要2min
文/ 强哥；未经授权禁止转载
在我这么多年的工作生涯里，难免遇到那些工作糊弄的开发同事，随意编程的实习生，不够细致的测试，缺乏专业度的产品...
产品的体验，取决于多个环节的把控，但很多情况下，由于bug严重影响体验，或者直接造成产品事故的，那么开发想甩锅都甩不掉！
今天就给大家从几方面讲讲，经验丰富的程序员，是怎么debug的！
1、并不是所有bug都需要修复
修bug有个前提，那就是修复后产品产生的价值大于付出的成本。
很多程序员容易陷入“完美”困境，在提测前看到任何bug，如果不修复，心里老想着，特别难受！很多程序员都有这样的“完美主义”。
比如做个工具产品，可能在一个非常小众的设备上不兼容某个功能或者说体验受损，他就老想着把它修复好，尽管历史数据显示该设备使用这款产品的这部分功能的用户只有十几个，而且很可能没有任何付费行为...
这种的bug，我认为是不值得花很长时间去修复的，因为核心功能点还有很多可以优化的地方，值得你花更多时间去研究技术方案！
不要抬杠，任何产品都不会赢得用户100%的同意，哪怕是微信这种级别的产品，每天也有很多人在教小龙哥怎么优化...
所以，多花时间去听用户对于重要功能的反馈，而不用执着于你的“事事完美主义”。
有时候，需要放下你的偏执。
2、衡量改bug的成本和价值
程序员的工作比较难量化，bug也一样，很难量化其价值。
有些bug虽然找起来和改起来麻烦，但只要改完，带来的业务价值可能是巨大的。
比如我之前做过数据平台需求，涉及到财务对账的，如果有bug影响数据统计的准确性，以及各部门的归属性，那么影响的不仅仅是产品体验这么简单了！
可能关系到部门的业绩核算，同事们的绩效统计等等。
如果这种需求出现大的bug且产品运行了一段时间没有发现，那么一定有人要背大锅！
改bug的成本一般都能判断个大概。而当你无法衡量改bug的价值时，把这个bug影响的具体场景，换算成业务价值、产品价值，就能明确这个bug到底值不值得改，优先级高不高了。
以上2点就是比较有经验的程序员的改bug方式，文章太长，下篇还会接着再分享几点，供大家参考。
后续还会出一些类似系列的文章分享给大家，感兴趣的可以关注公众号，或者加强哥微信～
- END -
今日留言区话题讨论
你是怎么判断一个bug要不要改的？
大家好我是强哥，一线互联网大厂技术leader，团队负责人。欢迎扫码加入读者群，共享技术干货/行业信息/求职内推等，进群方式见下图
