看待这个问题首先得看对方脾气咋样，如果对方脾气不好，或者很难搞，还是想想其他办法。直接跟他讲可能会遭到对方的白眼！
别看我们程序员一个个傻傻呆呆的，其实自尊心特别强！除非你是他的领导，否则即使你发现衡察虚了他代码里的Bug，他也不会服你！虽然还是会改，但内心一定在想：“就你能？自己管好你自己就成，看我代码干啥？”
其实我也是这样的心理，好像程序员除非自己愿意，否则都不怎么喜欢别人去研究自己的代码，好像对方故意找自己茬的意思。
但是不管咋样，不管是有意无意，我们既然发现了同事写的代码有问题，就不能坐视不管！
我最近在调一个小伙伴的接口时，因为涉及到数据回滚，所以就想知道他的代码有没有做回滚 *** 作。如果没有，可能我这边数据已经回滚了，他那边没回滚就会导致数据前后不一致。所以我也不是有意要审查他的代码。
然后我就发现他不光没有做回滚 *** 作，也没有做批处理。几个涉及到修改数据的代码就这样一行一行走下来，看着直让人挠后脑勺。
于是我就把这个事情告诉了他，让他要么做事物（如果 *** 作有问题，可以自动回滚），要么做主动回滚。否则我在调他接口时，如果我这边撤销了数据修改，他那边却提交了修改，就会导致数据丢失或前后不一致。
当我告诉他这个情况和解决方案以后，我能很明显地感受到他有点不愉快。但事实摆在眼咐燃前，也只能修改。可修改归修改，他还是有点脾气的。于是他写了一个事物，将大部分涉及到增删改的语句全部包在了里面，唯一把一个删日志的语句留在了外面。
我看到这个情况，就委婉地跟他说：“”好像这个删日志的语句也要包在事物里面哦！”
但是他却说，这个无关紧要，他特意放在外面的。
我跟他说，既然这里有数据存在，就不是无关紧要的。不管咋样，也不能无缘无故就把数据给删了。但是他很倔强，执意不改，还说如果我觉得这个数据有用，那就让我自己“顺手”把这里的代码改一下。
此时我能明显地感受到他已经有点烦我了！无奈之下，我把这段代码给移动到了事物里面。
而我为什么说我因为发现同事代码有Bug告诉同事而吃过亏呢？
原因在于我之前待过的一家公司，有一个工作了几年的程序员同事，而我当时是个萌新。因为我专门培训过，所以代码能力还行。可这个同事虽然工作了几年，但写出来的程序代码却Bug一堆，常规测试手段还测不出来。
我是在偶然之间发现他写的一个程序是有Bug，但是又不确定，所以就想看看他代码是咋写的。不看不知道，一看吓一跳，他写的好大一部分代码都有问题！
我当时初生牛犊不怕虎，发现一个跟他说一个，结果最后把他给惹毛了，当场就要跟我动手，说我专门针对他。我哪有针对他的心呀！我当时想的是把这些Bug找出来，让他改掉，否则对公司也不好。
但是他想的估计是被我这个萌新发现了一堆Bug很丢人。我总是针对他的代码找Bug，他就是脾气再好也绷不住啊！
后来我们的部门经理为了不让他难堪，也为了给他个台阶下，找了我写的程序里的一个缺点，猛批了下，然后跟大家说：“我刚才看了看，大家写的代码有好多问题。这样，大家都各自检查一下自己的代码，看看有没有问题，有问题尽快改过来，然后我们统一测试！”
直到现在，我也没毕没学会当发现同事代码有Bug以后，在不让同事产生不愉快的心理的情况下，委婉地告诉同事他代码写的有问题的方法。
软件可能在使用过程中没有任何问题，但不符合产品的预期下图源自“How projects really work？”，很形象的突出了客户需要的产品和最终得到的产品不一致。
因为文字具有二义性，每个人对相同文本会不同的理解，客户、项目经理、分析师、程序员对需求理解的不一致，导致了产品上线运行后不符合预期。这算是如李一个最大的Bug，有经验的开发公司会从沟通流程上尽量规避这种可能性，但也没有办法完全避免。
另外在软件开发途中也会出现各种各样的Bug。这种情况有点像装修房子，设计公司根据客户房子的尺寸和结构、朝向、生活习惯等等设计工程图和效果图。客户看到设计工程图和效果图后感觉很满意，马上水电工、木工、瓦工、油漆工等陆续进场按照设计工程图和效果图施工。施工完后看起来所有都很正常，验收的过程中就会暴露很多问题，比如少了一个插座、油漆涂抹不均匀、有的瓷砖没有贴好等。
当客户真正入住的时候，可能还会发现各种当初对设计不满意的地方，一旦真正使用的时候，就会发现当初应该这么设计。客户在使用软件的时候，并不会按照 *** 作流程使用这种情况就好比使渣喊迟用“高压锅”，使用说明上明明指出先得放气，才能掀开锅盖。使用的人非得先掀开锅盖，意外便发生了。软件是按照开发流程一步一步设计的，软件崩溃了，程序员对外行解释软件中出现的Bug是不现实的，只有老老实实地去设置阻断或者更改程序的流程。
另外软件使用过程还会出现一些黑天鹅事件，比如网线断了、服务器故障、机房网络拥堵等等。这种情况除了在软件的架构上做冗余，没有其他更好的办法。用户能正常使用，但在用户看不到的地方有各种异常一个软件有许多的功能模块，并且这些模块并不是同一个人设计的。一个功能模块几乎不可能独立运行，必然牵扯到其他模块。对于一个程序员设计的其中一个模块所依赖的其他模块没有办法保证是100%可用的。
这时虽然有错误，不影响主要的流程，也不影响用户的正常使用，用户也不会察觉到，甚至软件开发人员也没有察觉到。但指不定用户使用软件实现某个功能的时候，软件就会抛出错误或者崩溃。
所以软件想要变得成熟，Bug收集和处理机制是非常有必要的，比如：会影响客户使用的优先级高的Bug要优先修复。Bug是软件的影子，也是程序员的噩梦实际上不能存在没有bug的软件，Bug和软件如影随形。就像我们使用的Windows，穷尽无数优秀的软件工程师来设计给用户优秀的桌面体验，但也有各种层出不穷的bug。
程序员对Bug有多爱就有多恨，Bug无处不在，即使再牛逼的程序员也逃脱不了Bug的魔掌。想要完全避免Bug几乎是不可能的，所以也不在一次性就写好的程序。以上个人浅见，欢迎批评指正。认同我的看法，请点个赞渗虚再走，感谢！喜欢我的，请关注我，再次感谢！
互联网前辈总陆雀是说“bug是改不完的”，新入职的程序员应对bug：
1、在软件行业可能有一些新进的程序员都会面临着替别人改代码的情况。如果让一个人修改另一个人的代码，可能对于每个人来说都会是一种尴尬的情况。因为每个人的代码技术是不同的，而修护另一个人的代码bug，工作效率是相当低的。同时也会搞的那个程序员很没有面子，有时候是越改越糟糕，越改越痛心，不如重新另外写一个新的代码。对bug的时候不要出现消极的情绪。不管这个bug是不是自己所要面临的问题，都不应该觉得不是我的bug。因为这是职裂行业修养的问题。面对bug的正确态度应该是积极的调试集中的检测，确定问题，找到问题的原因，然后集中精力把bug解决掉。
2、测试。可以选择一些代码会出现的结果与预期不符合的先解决这一类问题。因为这每一步的预期结果都是根据跟踪到的实际结果进行判定的。这样子找出来的原因，在开发环境当中是比较容易设置的。当没办法调试的时候，可以查看日志的方式判断是哪一步出现了问题之后再返回来进行调试。这样对修复bug而言是比较快而且比早源早较迅速。
3、重写代码。最后如果是没办法的情况下当然是重写代码，但是这所产生的时间就会比较长。对于一个程序员来说，遇到bug是不用解释的，而且这是一种常见的情况。如果不能够把程序改好或者是实在没有办法改的情况下，也要解释为什么没有办法改，以及以后应该对这种情况如何做处理。因为程序出现错误是很正常的现象，而当机器不出现错误的时候，那是不可能的。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）