作为一个程序员，我发现同事写的代码有Bug，怎么办？

作为一个程序员，你发现同事写的代码有Bug，你会告诉他吗？讲真的，这个事情对我来讲，很难，因为我在这个事情上吃过苦头！
看待这个问题首先得看对方脾气咋样，如果对方脾气不好，或者很难搞，还是想想其他办法。直接跟他讲可能会遭到对方的白眼！
别看我们程序员一个个傻傻呆呆的，其实自尊心特别强！除非你是他的领导，否则即使你发现了他代码里的Bug，他也不会服你！虽然还是会改，但内心一定在想：“就你能？自己管好你自己就成，看我代码干啥？”
其实我也是这样的心理，好像程序员除非自己愿意，否则都不怎么喜欢别人去研究自己的代码，好像对方故意找自己茬的意思。
但是不管咋样，不管是有意无意，我们既然发现了同事写的代码有问题，就不能坐视不管！
我最近在调一个小伙伴的接口时，因为涉及到数据回滚，所以就想知道他的代码有没有做回滚 *** 作。如果没有，可能我这边数据已经回滚了，他那边没回滚就会导致数据前后不一致。所以我也不是有意要审查他的代码。
然后我就发现他不光没有做回滚 *** 作，也没有做批处理。几个涉及到修改数据的代码就这样一行一行走下来，看着直让人挠后脑勺。
于是我就把这个事情告诉了他，让他要么做事物（如果 *** 作有问题，可以自动回滚），要么做主动回滚。否则我在调他接口时，如果我这边撤销了数据修改，他那边却提交了修改，就会导致数据丢失或前后不一致。
当我告诉他这个情况和解决方案以后，我能很明显地感受到他有点不愉快。但事实摆在眼前，也只能修改。可修改归修改，他还是有点脾气的。于是他写了一个事物，将大部分涉及到增删改的语句全部包在了里面，唯一把一个删日志的语句留在了外面。
我看到这个情况，就委婉地跟他说：“”好像这个删日志的语句也要包在事物里面哦！”
但是他却说，这个无关紧要，他特意放在外面的。
我跟他说，既然这里有数据存在，就不是无关紧要的。不管咋样，也不能无缘无故就把数据给删了。但是他很倔强，执意不改，还说如果我觉得这个数据有用，那就让我自己“顺手”把这里的代码改一下。
此时我能明显地感受到他已经有点烦我了！无奈之下，我把这段代码给移动到了事物里面。
而我为什么说我因为发现同事代码有Bug告诉同事而吃过亏呢？
原因在于我之前待过的一家公司，有一个工作了几年的程序员同事，而我当时是个萌新。因为我专门培训过，所以代码能力还行。可这个同事虽然工作了几年，但写出来的程序代码却Bug一堆，常规测试手段还测不出来。
我是在偶然之间发现他写的一个程序是有Bug，但是又不确定，所以就想看看他代码是咋写的。不看不知道，一看吓一跳，他写的好大一部分代码都有问题！
我当时初生牛犊不怕虎，发现一个跟他说一个，结果最后把他给惹毛了，当场就要跟我动手，说我专门针对他。我哪有针对他的心呀！我当时想的是把这些Bug找出来，让他改掉，否则对公司也不好。
但是他想的估计是被我这个萌新发现了一堆Bug很丢人。我总是针对他的代码找Bug，他就是脾气再好也绷不住啊！
后来我们的部门经理为了不让他难堪，也为了给他个台阶下，找了我写的程序里的一个缺点，猛批了下，然后跟大家说：“我刚才看了看，大家写的代码有好多问题。这样，大家都各自检查一下自己的代码，看看有没有问题，有问题尽快改过来，然后我们统一测试！”
直到现在，我也没学会当发现同事代码有Bug以后，在不让同事产生不愉快的心理的情况下，委婉地告诉同事他代码写的有问题的方法。

你不描述一下问题，也没有说明故障现象，谁知道怎么帮你呀。
都没看懂你的问题到底是啥意思，你把问题再详细追问一下，我看看能不能帮你。
百度提问页面的顶端可以看到“我要提问”，要描述清楚您的问题，为了更好地得到答案，可通过文字、截图，对问题进行更详细的描述并悬赏！

作为一名码农、程序员，加班算是家常便饭了。周一至周五晚上加、周末加、办公室加、回家加、有偿加、无偿加……确实让人看见就怕。
但是你加班的原因是什么呢？让我们一起来看看下面两个例子。
01 程序员踩点下班，领导：不想干的请办理离职，我这里不养闲人与废物
在职场上加班不是目的，加班是为了完成工作，当员工能在正常上班时间内完成工作，无需加班，这时候作为领导也就没有必要让其留下来加班。
然而也有一些公司领导不看产出只看员工加不加班，就有一领导经过几天的观察，发现新来的几名程序员每天晚上不到八点就早早的下班走了。
对此这名领导很生气，想管管这群新来的程序员，于是在群里通知称：
都是干嘛使的？八点不到都 TM 走了！不干的直接说，现在就表态度，我这里从来不养闲人，也不养废物！不干的不想干的都去人事那里办理离职。
其实员工有这种心态实在人之常情。但退一步想，为何老板却能做到 5+2、白+黑呢？难道老板们都是铁打的？都是超人？非也，只因他们是经营者，他们为企业负责，为自己负责。
员工往往拿的是固定工资，所以这就导致了老板与员工焦点矛盾的局面：老板只关心利润，员工只关心工资。

正常。
bug的修复时间取决于它的复杂程度，如果是一个特别复杂的bug，可能需要很长的时间来解决，所以改一个月属于正常情况。
改bug是一个复杂且需要细心的过程，所以为了避免改错或者出现更多的bug，可以适当放慢步伐慢慢修改。

程序员小树：这个bug我不改了

测试小花&小草：为什么啊

程序员小树：就不想改了，咋地

测试小花：凭什么不改，你说不改就不改啊，xxxxx，两个人怼起来了

测试小草：不改就不改吧，那我关了啊

显然，上面小树、小花、小草的做法都是不对的，那么怎么样才算是比较合理的解决办法呢

首先，搞清楚bug不改的原因：

1、开发本地无法复现，觉得bug没有了

解决办法：帮助开发复现bug，如果开发本地没有问题，但是测试的环境有问题，拉着开发过来看，并且对比有哪里不一样，让开发尽量的复现解决。同时这个时候反思自己的bug提交的是否正确，步骤是否明了，如果有误，及时修改bug内容

2、bug需要执行多步 *** 作，比较复杂，开发觉得没有必要修改

解决办法：

a、个人魅力（不要小看这点，和开发搞好关系还是很重要的）

b、站在用户的角度去分析，如果上线后用户遇到了这个问题，会发生什么样的后果，尝试说服开发

c、找产品确认，说明问题的详情，可能出现的后果，由产品来做最终决定权或者和产品一起说服开发

3、临近上线了，bug发现的太晚了，来不及修复了

解决办法：首先要看这个bug的优先级，如果真的属于影响用户的使用和体验的，一定要在上线之前解决，一是延迟上线时间，二是加班解决bug。如果不是，那最终的决定权还是要交给产品，由产品来判断

4、涉及到框架的修改，修改成本太高了，这个版本先不改了

解决办法：寻找公司内部其他技术大牛，看是否真的没有其他可替代的解决办法，同时把可能出现的风险列给产品，由产品决定

5、第三方插件的问题，我解决不了

解决办法：找相应的同事，联系第三方插件的工作人员，推动第三方尽量修复这个问题

总之根据不同的情况，进行不同的处理，不能仅凭借开发的一句话，测试就稀里糊涂的将bug关闭，也不能因为一个无关痛痒的问题，揪着开发不放，影响整个项目的测试进度

另外两篇拙见：

《遇到产品不改的Bug怎么办》

《遇到不能复现的Bug怎么办》

---