摘要：话说人人都是创造者，程序员除了会编写程序外，在听到自己的程序不工作时，还会制造一些滑稽搞笑的理由或挡箭牌。本文作者就总结了他在生活中经常听到的8句话，大家不妨一起来看下。

都说态度决定一切，良好的态度也可以成就一名优秀开发者。

但在现实生活中，尤其是遇到问题、功能实现失败或不能正常运行时，大家就会开始抱怨或者寻找一些借口，这些借口完全是没用的或者是阻碍你前进的拦路虎。而真正专业的态度应该着眼于项目和团队的积极结果，关注个人和团队的成长，并且围绕当前的工作积极展开各项任务。

本文作者Rajaraman Raghuraman是一名拥有8年开发经验的软件开发人员，他总结了程序员遇到问题时经常找的借口或理由，大家不妨看下，不知各位中枪了没，如果没有，大家不妨在移步看看“ 程序员遇到Bug后的30种常见反应”。 

1. 在我机器上还运行好好的

开发人员常会遇到这样的问题，他们感觉测试人员或者客户的电脑有一种神奇的魔力，可以给程序注入bug。因为程序在他本人电脑上可以很好的运行，为什么到他们那就会出现问题。

想要避免这样的借口发生，开发人员需要弄清楚开发、测试、客户的运行环境。bug是在何种配置/环境下出现，当你弄清楚这些，相信你就不会再发出这样的抱怨了。另外一种避免方式是拥有持续集成环境，检查每一段代码，并且把代码编译和部署到一些测试机器上。

2. 你这是最新的build吗？

当测试人员告知开发者有bug或者提交bug时，程序员常会问，你测试的应用程序是最新的构建状态吗？其实，这种情况一般很少发生，一般提交的bug都是在最新的build里发现的。

想要避免这种情况发生最好有一个进程，可以验证测试人员使用的代码是最新最有效的。另一个方法是有一个持续集成环境，代码可以自动build和部署到测试服务器上。

3. 肯定是配置问题

如果有开发人员这样对你说，你可以回答：“或许有可能，你能告诉我是哪个文件的配置出现问题了吗？我需要让它运行起来。”正如上面的对话，用户需要一个确切的回答，而非通用、模棱两可的答案。

最佳的做法是把所有配置文件里的相关参数定义在一个单独的配置文件里，把所有的动态值写在某个日志文件里，以防在引用时发生混乱。

4. 先提出一个缺陷，然后我再确认它

个人角度来看，一个未得到确认的缺陷是很令人烦恼的。开发人员要么在开发过程中对缺陷进行跟踪，要么就是程序员和测试人员之间协调，通常情况下，开发人员和测试人员应该携手来进行缺陷的确认，以防弄出一些模棱两可的缺陷出来。

要想避免这样的情况发生，最好的方法就是测试人员和开发人员之间有良好的团队士气和协作。这样，他们就会很容易进沟通讨论，并且对缺陷进行确认和跟踪。

5. 重启一下机器看看

这可以说是程序员杀手级的挡箭牌了，偶尔这个会奏效，但通常都是假的。

想要避免这种情况发生就要弄清楚架构、代码以及相应的开发环境。

6. 我不确定它为什么不工作，让我检查一下

相信用户最讨厌开发者说出这样的借口，作为一名开发者，你竟然都不确定某个特定的模块/功能为什么不工作，那么你是否正确地理解了该功能和代码设计呢？

想要避免这种情况发生，开发人员应该对各个模块有个清晰的思维导图，一旦问题发生，应该立即进行分析并且找出可能导致问题发生的原因。如果对问题出现的情况不知所措或者根本不知道原因所在，这很可能是因为代码设计不良或者缺乏对相应功能模块的理解。

7. 5分钟以后再试试

好吧，难道你对程序设置了计时炸弹，好让它5分钟以后再工作。

这个借口真的是很可笑，开发者应该意识到代码不会随着的时间的改变而改变，除非你设置了某些特定的定时代码功能。

8. 我不认为我的代码有错

有些程序员在面对缺陷时，通常都会说：“我的代码没错啊。”作为开发团队里的一员，应该没有“我的代码一说”，还不如换种说法更好，比如可能是某个模块出现了点问题，我去检查一下看看，最后再找到相应的开发人员，这样更加有利于振奋团队士气。

想要避免这种情况发生，最好的方法就是拥抱团队文化，每个开发者都要清楚各个模块的作用和功能，并给予相应的权限。

除了以上八句话，开发人员在听到自己的程序有缺陷或者功能失败时还会冒出哪些借口或者挡箭牌呢？

大家不妨分享下吧。

来自： Java Code Geeks