程序员如何减少代码的BUG量

01.BUG的起源

BUG常常困扰着程序员，Bug一词来源于英语，原意为“臭虫”或“虫子”。我们将发现Bug并加以纠正的过程叫做“Debug”，意为“捉虫子”或“杀虫子”。在中文里面，我们常常将BUG称为程序缺陷。从电脑诞生之日起，就有了电脑BUG，根据维基百科描述，BUG一词源于1947年，当时身为美国海军上尉的格蕾丝·穆雷·霍波退役后，加入了哈佛大学的计算机实验室，继续研究马克II型和马克III型计算机的工作。操作员在追踪马克II型的错误时发现是因为一只飞蛾在继电器的触电上导致的，遂有bug术语。这个飞蛾被仔细移除，并被贴在日志本上。这个日志本现存于史密森尼国立美国历史博物馆，飞蛾还完整贴在上面。

02.作为程序员为什么要减少BUG量

BUG会给我们的产品带来危害

BUG如果在开发和测试阶段没有被发现，将会随着产品发布，在生产环节被触发，其后果将视情况而定，在这里举一个比较极端的例子。1980年，北美防空联合司令部曾报告称美国遭受导弹袭击。后来证实，这是反馈系统的电路故障问题，但反馈系统软件没有考虑故障问题引发的误报。无独有偶，1983年，苏联卫星报告有美国导弹入侵，但主管官员的直觉告诉他这是误报。后来事实证明的确是误报。如果，这两次的误报被当时的掌权部门信以为真，一场全球性的世界大战不可避免。

能提高程序员的开发效率

有些程序员认为，测试BUG是测试人员做的事情，程序员只要负责写代码就可以了。其实，这种想法是经不起推敲的。程序员不仅有编写完成需求的代码的义务，也要对自己的代码质量负责。在常见的开发流程中 

程序员开发 ->提交代码 ->测试人员测试（如果存在BUG） ->反馈BUG给程序员 ->程序员修复BUG ->测试人员测试 （未发现BUG）->提交测试结果，等待版本发布

如果BUG量较大，将直接导致上述的这个过程时间延长，如果在修复的过程中产生其他BUG，将让这个过程重复，直到测试人员没有测试出来BUG为止。所以，减少开发的BUG量，将显著的减少整个发布的时间。

修复BUG的过程中是何种感受

一般作为程序员在开发中难免会出现BUG，在工作过程中就难免有修复BUG这个环节，可能是修复你自己编写的BUG，也可能是修复同事的BUG，下面用两张图来形象的描述这两种状况。

1）程序员在修复自己编写的代码BUG时

2）程序员在修复别人编写的代码BUG时

成为高级程序员的必经之路

很多公司将BUG量作为评估一个程序员晋升的重要参考指标，因为，BUG量的多少能直接反映你开发的代码的质量，也直接影响版本发布的时间周期。所以，编写高质量的代码对程序员在职业道路上的晋升起到不可忽视的作用。反观身边的同行会发现这样一个结论，越是程序大牛，其开发的代码的BUG量越少。

03.怎么做才能减少开发过程中的BUG量

清晰理解需求的真实目的

经验尚浅的程序员经常在拿到需求的时候，较少去思考，直接按照需求上描述的样子去开发。而相对有经验的程序员在拿到需求的时候会尝试理解用户的真正需要，在有必要的情况下还会去找设计人员沟通，最终在开发、设计、用户三者之间达成一致的理解。

理清需求的各个细节

有经验的程序员在拿到需求后，不会马上就动手去做，他会先如第一点所说，搞清楚用户的真实目的是什么。第二步要做的就是梳理实现这个目的的需求中的各个细节是否合理，对于描述模糊或存在歧义的地方会和设计人员（或者客户）进行沟通，在开发之前将这些细节明确下来。

开发之前的构思和规划很重要

有经验的程序员在动手开发之前，会构思和规划整体的实现方式和步骤，头脑中有了清晰的架构后再逐步实现它。这样能在开发前做到心中有数，在开发过程中做到有条不紊。

开发过程中做到专注

在这个信息爆炸的时代，我们时刻都会被各种信息打扰：QQ、微信、短信、电话、同事的聊天等等等等，假如我们不断地被各种事情打断，等我们再回到原来的事情时，发现很多地方还要重新思考，这样就浪费了大量的重复思考时间。特别是在开发较为复杂的需求时，我们如果能做到专注，我们的思路和工作就能很连贯的进行下去，自然我们就能在较短的时间里面完成。

开发完成后不要忘记复查你的代码不要忘记复查你的代码

代码复查是为了在提交之前能发现存在的BUG，代码复查一般从代码风格、重大缺陷、设计逻辑和设计思路几个方面展开。复查的方式有自查（自己检查自己的写的代码），互查（同事、经验较丰富的程序员或Team Leader检查你写的代码）