怎么写出没有BUG的代码

怎么写出没有BUG的代码

1947年9月9日，美国海军准将GraceHopper在哈佛学院计算机试验室里运用MarkII和MarkIII计算机进行研究工作。她的团队盯梢到MarkII上的一个过错，操作人员发现是由于一只飞蛾钻到了MarkII的继电器里导致的。团队清除了这只飞蛾，全部康复正常。其时的工作人员记录了这样一句日志：”Firstactualcaseofbugbeingfound.”这次闻名的事情，犹如潘多拉打开了魔盒，从此，程序员的世界里，bug满天飞。
世界上第一个bug
在我所担任过的角色中，有一个岗位叫做DevelopmentManager，通常简称DM.记得在一次根据一款渠道的二次开发项目中，由于bug真实太多，咱们几乎拿出了一整个里程碑的周期来debug，所以我这个DM有了新的解释：DebugMan.
没有人喜爱bug，bug意味着过错、不确定性、加班、交付风险，等等……负面的词语怎么堆砌都不冗余。随便找个有过一、两个项目经历的开发者，问问他debug的回忆，那气氛就跟上坟一样。
关于bug，开发者的神经往往也很灵敏。有个段子很风趣——说的是“应该怎么向程序员反响一个bug”——
你不能直接跟他说：“这儿不对啊，是不是你程序有bug啊？”，要这么说的话，会直接被怼回来：“你丫的自己不会用吧！”。
你能够换个说法：“咦，这儿如同不对，是我操作错了吗？”，这时程序员心里就一咯噔：“Shit..不会是我代码有bug吧？”
从业多年，发现有个现象还蛮风趣的：有时分，当某个bug被发现时，犯下这个过错的始作俑者会开玩笑地为自己解脱：“谁没写过bug啊，Windows还有bug呢。”这句遁词我也用过，感觉挺好用的，就比方：梅西都能罚丢点球，我空门没进，也是能够了解的嘛。

但其实吧……这逻辑经不起琢磨的。
Windows操作体系，一款长达30多年，装机量估量都超过了地球人口数量的巨型工程，复杂度基本只能靠猜。以微软公布的资料来看：
Windows95代码量约1500万行
WindowsXP代码量约4500万行
WindowsVista代码量约5000万行
Windows7代码量5000+万行
以Windows7为例，超5000万的代码量，23个小组，共1000多人的开发团队。如此规模下发作的bug，和一个在办公室里上了1天班，写了200行代码，就闹出一堆bug，搞得项目乱七八糟的，能同日而语吗？终究再轻描淡写地来句“微软也有bug”，不害臊？
所以我后来不用这句了，如此摆脱，水平太low。其替代计划容我稍后再讲。
为了对抗bug，人们发明晰各种各样的东西和手法，上至方法论，下至生产东西。越来越先进的IDE,复杂的代码检查准则，从单元测试到集成联调，再配上beta版，试用，公测，等等。凡此种种，其方针无一不是消除bug。可这些琳琅满目的处理计划的存在，反倒证明晰一个悲惨剧：人类，真实是太简略犯错了。
假如说凡事都有正反两面的含义，那么bug的正能量便是硬生生造就了许多就业机会，从而保护了社会安稳。
那么，为什么咱们总是无法防止bug的发作？咱们能不能根绝bug？
答案当然是不行能了。由于那样一来，程序员的日子岂不是太舒服了？不符合苦逼的定位。并且，咱们所处的这个世界，但凡越是高呼要消除的东西，越是会普遍地存在。就像苍蝇、蚊虫、污染、违法、战役，不一而足。
依照常识，经历越丰富的老手写出来的代码，一次通过的几率更高，比方他们考虑得会更周全，对反常的判断和处理更老练，边界条件把握得更准确，等等。所以咱们可能会幻想：是不是只需咱们足够仔细，并尽力锻炼技艺，通过让一部分码农先老练起来，然后完成一起老练，终究就能够到达全世界开发者联合起来消除bug的大解放了？
很遗憾，这仅仅一个治标不治本的思路，由于bug是有阶级的。老手们的bug相对少，仅仅初级过错少，他们也会遇到bug，而他们的bug，往往都是一眼蒙逼的难度系数N.x的难题，不发作在代码层面，大多在业务层面，乃至需求设计层面，或许直接是一些不行抗拒因素（做过政府项目吗？）。总之，萌新有萌新们的秀逗，大叔有大叔们的短路，老杆也会有自己的滑铁卢。
bug这个概念的起源，就预示着它的不行防止性。世界上第一个bug是一只飞蛾，这剧本，谁能料到？某种含义上说，bug便是不行预见的过错，能被预估并且提前做好准备的，那叫exception，trycatch是他们的朋友。
关于为什么会发作bug的原因，闻名的荷兰计算机科学家EdsgerW.Dijkstra有过一句经典名言：
Ifdebuggingistheprocessofremovingsoftwarebugs,
**thenprogrammingmustbetheprocessofputtingthemin.**
这便是上文说到的那句遁词“Windows也有bug.”的替代计划。:)
想象一下，当你从无到有的写下一句句代码时，中心的任意一个时刻，你的程序都是运转不起来的，至少也是达不到方针作用的。从效用上完全等效于充溢bug的一堆代码。你可能会辩解，程序还没写完呢，仅仅功用还没完成，并没有bug。事实上，换位考虑一下，缺失某个功用和包括一个有毛病的功用，关于用户而言，都是无用的。一个处于开发阶段尚没写完的代码和开发结束但写得有缺陷的代码，是一回事。
由此能够引申出了一个闻名的命题：
That’snotabug,it’safeaturerequest.
有时分，咱们很难分清楚一个问题到底属于bug还是featurerequest.文中作者抛出了一个案例：用VisualStudio构建一个WindowsGUI程序时没有选用体系默认字体。这个算不算一个bug呢？
不好说。毕竟，跟着软件应用越来越普及、越来越寻求所谓人性化的趋势，传统含义上的只需程序能运转就不算bug的观念，也在渐渐发作改动。关于一个逼迫癌用户来说，UI上有缺陷，那基本上整个软件就不能用了。事实上，在当今各类app竞赛白热化、同质化的年代，用户体验上的问题，往往是丧命的。以前咱们没得选，所以没那么挑剔，只需程序能干活就行了。现在的计算机用户现已被宠坏了，在这样的年代下，bug早已悄悄地泛化了。
所以，到底怎么才干写出没有bug的代码呢？
答案:不写代码。
一个悲观又失望却正确的唯一解。
试着在这失望里挖掘一点希望吧。这个答案隐含了一个方法论:尽可能少写代码。由于Dijkstra大师现已说得很清楚了，编程便是制造bug的进程。那么，代码写的越少，犯错的几率就越小，这个道理显而易见。保护一段300行的代码，咱们很简略有决心；接手一段3000行的代码，什么反响就看各人本质了。
现代的开发方式也都包括有这个思路，从IDE的智能提示，代码补全功用，到每门言语都会有的各种“21天从入门到通晓”的开发结构，以及许多实战层面的约定俗成，都是在协助开发者减少不必要的编码。结构化、规范化思维能下降出错的可能性。
事实上，就连编程言语自身的历史发展都是依照这个思路在进行。从底层的汇编言语，到C/C++，再到Java/C#/Python……等各种高档言语，言语演化的目的之一便是为了把程序员从脏活、累活的工作中解放出来。
“不要重复造轮子”的精神，一方面是在辅导咱们提高功率，不要重复劳动成本，另一方面也是减少重复犯错的几率。
当代Web开发中的各种包管理概念正深刻地践行着这条精神，以至于在2016年3月爆发了闻名的NPM&left-pad事情:一段区区11行的字符串填充函数模块，被全世界依靠，结果作者Azer下架模块包的那一天，全球前端大崩溃。受涉及的产品和团队中，乃至包括闻名的React！
这个事情让人们开始反思：咱们是不是忘了该怎么编程了？一个功用简略到人人都会写的函数，却都不谋而合地选择引进，而不是自己完成。终究，过犹不及。
写代码，真的很难。
NOBUG,NOCODE.
可是，假如真的只能不写代码了，那么自身就现已没有女朋友的程序员们，现在连代码也没有了，这还让不让人活了？
不能这样把程序员们给逼死了，要讲人权。
有时分，当答案真实不行接受的时分，咱们就该考虑是不是问题问错了。
所以，换个视点，为什么要寻求无bug呢？或许咱们根本就没必要惧怕bug.
有bug的当地就有费事，有费事就有处理费事的需求，客户便是给那些能处理费事事的人支付报酬的。只处理简略的问题，是没有价值的，商场只认可那些面对困难能提供处理计划的人。简略来讲，想挣钱，就别怕费事。
关于客户来说，不管是bug或是featurerequest，都是一个需求处理的问题。一个优异的PM，能够把客户反响的bug，包装成featurerequest，返回一套处理计划。然后，优异的商务代表出马，签订补充协议。恭喜，你们的项目经费增加了一点点。
英格兰有句谚语：
Wherethere’smuck,there’sbrass.
如此看来，“怎么写出没有BUG的代码？”这问题，恐怕确实问错了。
终究，祝咱们技能在沉积中升华。
“不积跬步，无以至千里”，希望未来的你能：有梦为马到处可栖！加油，少年！
关注大众号:「Java至交」，每天更新Java常识哦，等待你的到来！
发送「Group」，与10万程序员一起进步。
发送「面试」，收取BATJ面试资料、面试视频攻略。
发送「玩转算法」，收取《玩转算法》系列视频教程。
千万不要发送「1024」…