程序员在Bug面前的反应

开发应用程序过程中一定会遇到bug，这是很正常的事。程序员会有各种反应：生气，沮丧，郁闷甚至泄气，也有一些程序员会比较淡定。怎么修复bug，解决问题，也是一项技能。下面北大青鸟来分享程序员在bug面前反应情况。

当氛围变得紧张的时候，这些话就会显得轻松幽默。最终，bug也会修复成功，你将会继续下一个任务。我相信许多web开发人员和程序员在编程中都会遇到困难，而事后回想起来，会觉得很好笑。

程序员在bug面前反应情况

1、我不知道该删掉还是重写

看这些曾经的代码也别想重写，逻辑性差，冗余代码多，让人难以理解。B不过，如果功能没出现问题，千万别去修改。

2、一开始架构时就该查Github

Github上面每天都会发布的一些神奇的开源项目。所有语言的程序员都会利用网络，为已存在的项目创建分支，添加项目wiki描述，或者创建自己的代码库，这些都为各种各样的项目的插件和模板提供了丰富的资源。

3、为什么这个脚本要依赖这么多库

说到一些越来越被广泛使用的计算机语言，像Java和Objective-C，库文件的数量也不断增加。明显能看出，构建一个框架需要许多基础库，一些JavaScript插件也要大量的附加文件。

4、网上一定有解决办法

遇到困难时，第一反应是上网查资料，很多程序员会在论坛上发布他们的问题，最终这些问题都会被解决并存档。Google会很神奇地选择一些跟你的问题相关的关键字，就能够轻松得到一些有帮助的信息。不过，有时一些特定的问题，相关的信息并不多。

5、有这个功能的插件吗

何必多此一举，插件是扩展任何程序或者网站用户接口的很好的资源。另外它们还为开发者提供了一些定制及独特的选项。

6、对于网站项目，好担心InternetExplorer

使用IE渲染网页遇到的各种困难，我就不提了，从5。5版本到IE9-IE10，对于浏览器的支持问题的争议就一直不断。Web开发员很害怕网页调试，使用IE6进行渲染更是噩梦，幸好那已成为历史。

事情的起因是微服务A通过feign调用微服务B的某个接口，报了形如下的异常

负责微服务A的工程师小张就找到负责提供该接口的工程师小李，问小李是不是改动了接口，小李一脸无辜说他最近没对这个接口做任何改动，不过小李还是说道他排查一下。

小李排查的过程如下，他先通过swagger查看他提供给A服务接口是否存在，他一查发现他在swagger上看不到他提供给A服务的接口。于是他怀疑是不是有人动了他的代码，他就去查找最近的git提交记录，发现没人动他的代码，因为项目还没发布，都在测试阶段，他就根据项目集成的git-commit-id-maven-plugin插件定位到测试目前发布具体是哪个版本。（ps：对

git-commit-id-maven-plugin感兴趣的朋友，可以查看之前的文章聊聊如何验证线上的版本是符合预期的版本）。然后他将该版本的代码下到本地进行调试，他发现代码中提供给A的接口还在，target下的class也有提供给A的接口class，但诡异的是swagger就是没显示他提供出去的接口，他一度以为是swagger出了问题，于是他用postman直接请求他提供A的接口，发现报了404。然后他就叫负责同个微服务B的同事小王，也帮忙试一下，发现结果就是404。后面没招，小李就去求助他们项目资深同事小林。

小林的排查思路如下，他先走查一下小李的接口代码，发现他提供的接口实现层的方法上加了一个@Async，示例形如下

小林凭多年的经验直觉告诉小李说，应该是@Async引起。小李很斩钉截铁的说不可能啊，他@Async很早就加了，之前接口都可以访问的，小林一看小李说得那么肯定，他也不好打击小李。于是他接下来做了如下 *** 作，先在项目中yml配置如下参数，开启springweb日志

然后在项目中加了形如下代码，来跟踪接口bean的类型

启动控制台，看日志形如下

发现确实没打印出相关requestMapping映射信息，这可以说明一点就是小李那个接口没有绑定到springmvc映射，也就是出现404的原因。接着观察控制台打印的bean，内容形如下

这很明显这个接口bean已经被jdk动态代理给替换。小李看到控制台打印的信息，若有所思，然后说，我把@Async去掉试下。小李把@Async去掉后，再观察下控制台

通过控制台可以发现，此时接口已经绑定到springmvc映射，而且打印出bean类型是真实对象bean。小李看到这个现象，也百思不得其解，他说道他之前确实是加了@Async，接口也能正常访问。于是小林就问一句，你确定你加了@Async，异步生效了吗，小李说开启spring异步，不都是加@Async吗。小林又问了一句，你在项目中开启异步，除了加@Async，还有做什么处理吗，小李说没了，他之前在项目使用异步就都是加了@Async，也能用了好好的，小林一听，基本上知道为什么小李之前@Async，接口还能正常访问了，小林为了验证想法，就问同负责该项目的小王，说你最近有加什么异步 *** 作吗，小王说有，小林进一步问，你是怎么做的，小王说，他先加@EnabledAsyn，开启异步，然后在业务逻辑层上的方法上加@Async注解。小李一听，说原来使用@Async还要配合@EnabledAsyn啊，他之前都不知道

接着小李说 那在controller是不是就不能使用@Async注解了？ ，小林说最好是把加@Async的逻辑挪到service层去处理，不过也不是controller就不能使用@Async注解了，接着小林为了验证这个想法，他把原来实现的接口类去掉，形如下

启动后，查看控制台

此时bean的类型如下

访问接口，打印内容如下

从控制台可以发现，都是>

深有体会，肺腑之言：

晚上10点之后千万不要写代码，每次我这个时候写代码总会左眼睁着右眼闭上，右眼睁着左眼闭上，我表示10点之后写代码那是开玩笑。虽然有时后不是很困，然后自我感觉很良好，但是，但是，第二天自测，或者QA测试的时候那就呵呵。。。写代码5分钟，查bug俩小时。

写代码前可以自言自语，或者写在纸上。把要做的东西说一遍，理清楚了再写。

写代码千万不能着急。领导催，pm催，那也是急不来的。必须按照平时的速度，一步一步的来，心浮气躁，心神不宁的状态不能写代码。

写注释，写注释，写注释。重要的事情说三遍。代码就像天书（这点相信看过别人代码的人深有体会），而自己的代码呢，当时觉得清新易懂，过个两三天就不那么回事了。写上注释有利于后续开发的时候容易减少bug和定位bug

bug有很多种，语法上的，逻辑上的等等。对于语法错误，很好解决。使用集成的开发环境，一般都会有语法检查，高亮提示等功能避免产生。然后

软件可能在使用过程中没有任何问题，但不符合产品的预期下图源自“How projects really work？”，很形象的突出了客户需要的产品和最终得到的产品不一致。

因为文字具有二义性，每个人对相同文本会不同的理解，客户、项目经理、分析师、程序员对需求理解的不一致，导致了产品上线运行后不符合预期。这算是一个最大的Bug，有经验的开发公司会从沟通流程上尽量规避这种可能性，但也没有办法完全避免。

另外在软件开发途中也会出现各种各样的Bug。这种情况有点像装修房子，设计公司根据客户房子的尺寸和结构、朝向、生活习惯等等设计工程图和效果图。客户看到设计工程图和效果图后感觉很满意，马上水电工、木工、瓦工、油漆工等陆续进场按照设计工程图和效果图施工。施工完后看起来所有都很正常，验收的过程中就会暴露很多问题，比如少了一个插座、油漆涂抹不均匀、有的瓷砖没有贴好等。

当客户真正入住的时候，可能还会发现各种当初对设计不满意的地方，一旦真正使用的时候，就会发现当初应该这么设计。客户在使用软件的时候，并不会按照 *** 作流程使用这种情况就好比使用“高压锅”，使用说明上明明指出先得放气，才能掀开锅盖。使用的人非得先掀开锅盖，意外便发生了。软件是按照开发流程一步一步设计的，软件崩溃了，程序员对外行解释软件中出现的Bug是不现实的，只有老老实实地去设置阻断或者更改程序的流程。

另外软件使用过程还会出现一些黑天鹅事件，比如网线断了、服务器故障、机房网络拥堵等等。这种情况除了在软件的架构上做冗余，没有其他更好的办法。用户能正常使用，但在用户看不到的地方有各种异常一个软件有许多的功能模块，并且这些模块并不是同一个人设计的。一个功能模块几乎不可能独立运行，必然牵扯到其他模块。对于一个程序员设计的其中一个模块所依赖的其他模块没有办法保证是100%可用的。

这时虽然有错误，不影响主要的流程，也不影响用户的正常使用，用户也不会察觉到，甚至软件开发人员也没有察觉到。但指不定用户使用软件实现某个功能的时候，软件就会抛出错误或者崩溃。

所以软件想要变得成熟，Bug收集和处理机制是非常有必要的，比如：会影响客户使用的优先级高的Bug要优先修复。Bug是软件的影子，也是程序员的噩梦实际上不能存在没有bug的软件，Bug和软件如影随形。就像我们使用的Windows，穷尽无数优秀的软件工程师来设计给用户优秀的桌面体验，但也有各种层出不穷的bug。

程序员对Bug有多爱就有多恨，Bug无处不在，即使再牛逼的程序员也逃脱不了Bug的魔掌。想要完全避免Bug几乎是不可能的，所以也不在一次性就写好的程序。以上个人浅见，欢迎批评指正。认同我的看法，请点个赞再走，感谢！喜欢我的，请关注我，再次感谢！

以上就是关于程序员在Bug面前的反应全部的内容，包括:程序员在Bug面前的反应、记一次因@Async引发的程序bug、程序员写程序时，有哪些减少bug的好方法等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！