看待这个问题首先得看对方脾气咋样，如果对方脾气不好，或者很难搞，还是想想其他办法。直接跟他讲可能会遭到对方的白眼！
别看我们程序员一个个傻傻呆呆的，其实自尊心特别强！除非你是他的领导，否则即使你发现了他代码里的Bug，他也不会服你！虽然还是会改，但内心一定在想：“就你能？自己管好你自己就成，看我代码干啥？”
其实我也是这样的心理，好像程序员除非自己愿意，否则都不怎么喜欢别人去研究自己的代码，好像对方故意找自己茬的意思。
但是不管咋样，不管是有意无意，我们既然发现了同事写的代码有问题，就不能坐视不管！
我最近在调一个小伙伴的接口时，因为涉及到数据回滚，所以就想知道他的代码有没有做回滚 *** 作。如果没有，可能我这边数据已经回滚了，他那边没回滚就会导致数据前后不一致。所以我也不是有意要审查他的代码。
然后我就发现他不光没有做回滚 *** 作，也没有做批处理。几个涉及到修改数据的代码就这样一行一行走下来，看着直让人挠后脑勺。
于是我就把这个事情告诉了他，让他要么做事物（如果 *** 作有问题，可以自动回滚），要么做主动回滚。否则我在调他接口时，如果我这边撤销了数据修改，他那边却提交了修改，就会导致数据丢失或前后不一致。
当我告诉他这个情况和解决方案以后，我能很明显地感受到他有点不愉快。但事实摆在眼前，也只能修改。可修改归修改，他还是有点脾气的。于是他写了一个事物，将大部分涉及到增删改的语句全部包在了里面，唯一把一个删日志的语句留在了外面。
我看到这个情况，就委婉地跟他说：“”好像这个删日志的语句也要包在事物里面哦！”
但是他却说，这个无关紧要，他特意放在外面的。
我跟他说，既然这里有数据存在，就不是无关紧要的。不管咋样，也不能无缘无故就把数据给删了。但是他很倔强，执意不改，还说如果我觉得这个数据有用，那就让我自己“顺手”把这里的代码改一下。
此时我能明显地感受到他已经有点烦我了！无奈之下，我把这段代码给移动到了事物里面。
而我为什么说我因为发现同事代码有Bug告诉同事而吃过亏呢？
原因在于我之前待过的一家公司，有一个工作了几年的程序员同事，而我当时是个萌新。因为我专门培训过，所以代码能力还行。可这个同事虽然工作了几年，但写出来的程序代码却Bug一堆，常规测试手段还测不出来。
我是在偶然之间发现他写的一个程序是有Bug，但是又不确定，所以就想看看他代码是咋写的。不看不知道，一看吓一跳，他写的好大一部分代码都有问题！
我当时初生牛犊不怕虎，发现一个跟他说一个，结果最后把他给惹毛了，当场就要跟我动手，说我专门针对他。我哪有针对他的心呀！我当时想的是把这些Bug找出来，让他改掉，否则对公司也不好。
但是他想的估计是被我这个萌新发现了一堆Bug很丢人。我总是针对他的代码找Bug，他就是脾气再好也绷不住啊！
后来我们的部门经理为了不让他难堪，也为了给他个台阶下，找了我写的程序里的一个缺点，猛批了下，然后跟大家说：“我刚才看了看，大家写的代码有好多问题。这样，大家都各自检查一下自己的代码，看看有没有问题，有问题尽快改过来，然后我们统一测试！”
直到现在，我也没学会当发现同事代码有Bug以后，在不让同事产生不愉快的心理的情况下，委婉地告诉同事他代码写的有问题的方法。
程序写代码就像造一座大楼，如果即便经过严格的设计论证，装配高质量的部件，最后还有系统性地验收，让你去造这么一座大楼，你能保证不管是窗户安没安好，还是地基挖浅了挖深了，还是墙皮脱落，都一个问题没有？回想早年的小程序，执行某一个具体的任务，明确的输入输出，一般是不会有bug的。
但现在的软件开发，早就已经不是一个人在战斗了，大部分的工程，开发规模5人左右居多，另外稍大的软件工程动辄几十人，更有甚者几百人的团队规模并行作业。你试想一下，要保证这么多人的产出都符合设计要求，势必需要合适的开发流程，需要更多的项目管理的技巧和方法。这就对个人以及团队的提出了非常高的要求了。
软件工程的方法论中，要求软件开发者尽可能多地在软件测试阶段发现bug，而不是交付之后。
但是楼主说的能不能让软件开发出来没有bug，我觉得把下面这几个事情做好，还是有可能的。
1、花尽可能多的时间，和客户沟通软件需求，了解每一项需求的用意。
2、确保软件需求不能随意变动，因为很多情况下一个需求的变化，程序会带来很多问题，有可能连底层结构都需要跟着一起变动。频繁的需求变动，加上开发周期和成本的约束，带来的结果就是软件质量的不可控。
3、确保软件测试质量，完成全覆盖测试，设计系统需要的全部用例并保证全部通过。
总结下，软件项目在实际开发过程中风险点还是很多的，通过合理的控制，可以降低和减少bug。但是软件本身是为人的需求而生，只要需求在变化，软件是永远都需要跟着去维护和更新的，所以只要有不可控的因素（需求分析，系统设计，系统详细设计，编码，单元测试，集成测试，系统测试，验收等）任何一个环节任何一个人产生问题，反映到最后的软件产品上就是一个bug。
另外Bug分很多类，一类是对用户来说不能正常使用，能被用户感知到的错误。一类是用户能正常使用，但是有各种异常的错误。一类是使用没有任何问题，但是不符合产品预期的问题。其他应该还有很多，这里我们一一讨论。
对用户来说不能正常使用，能被用户感知到的错误。
其中一种情况是程序员和测试人员的问题，所有功能在上线前，工程师和QA人员应该测试，回归完功能。能被用户感知到使用流程有问题的话，一定是相关人员能力或者线上意识某一方面欠缺，也是最不能容忍的。
另外一种情况是黑天鹅事件，什么网线被挖断，机房被炸，服务器爆炸什么的。。。。。。 ，这个说实话，出了在软件架构上做冗余，目前没有什么特别好的办法。
2. 用户能正常使用，但是在用户看不到的地方有各种异常的。
一个功能模块几乎不可能是独立的，它必然牵扯到其他模块。对于你所依赖的模块，你没办法保证这些模块是100%可用的。这个时候可能虽然有错误，但是只要不影响主要流程，我们依然可以正常使用。但这个时候对于外部依赖的异常处理，很考验工程师的能力。
举个例子，有可能你看到的点赞数比你实际收到的点赞数少。这个是由于点赞统计在什么时候失败了一次，某些用户可能认为这个是bug，但是其他可能不会在意（当你有10001赞的时候，你在意少了1个么？）
3. 使用没有任何问题，但是不符合产品预期
这个更多的是研发和产品经理对于需求理解的不一致。因为文字是有二义性的，况且人和人对相同文本的理解本来就可能出现偏差，这就导致了需求理解的不一致，最终导致了线上产品不符合预期。对于内部人员来说，这个也算BUG。
说了那么多，最主要的核心在于实现功能的是人。人不像机器，不可能不犯错；同样的，不可能存在没有bug的程序，像大家使用的windows，穷尽无数优秀的工程师，给予用户优秀的桌面体验的同时，也有你可能完全看不到的数千个bug。想要完全避免几乎是不可能的。所有也不存在一次性就写好的情况，鬼知道产品经理什么时候改需求呢~
1. 火箭爆炸，原因：类型强转（64b浮点->16b整数）导致异常2. 火箭爆炸，原因：Fortran代码笔误（少一个减号）
3. 火星车故障，原因：vxWorks优先级逆转 -
4. 火星探测器坠毁，原因：用错计量单位（磅与牛）
程序员导致的事故挺多，这些是严重点的。还有游戏更新把用户电脑上文件删光的...
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）