亲亲宝宝

普遍来说，一旦开发出现了问题，开发人员都会编造借口，特别是初学者或者是开发的程序总是不断有问题的开发人员。只要这些理由是真的，这并不是什么问题。但是，一旦这真的只是个借口，这就会成为整个团队的的问题所在。我不喜欢找借口的人，让每个人都知道只有在整体环境中正常运行才是可以交付的程序，在改正问题的同时并思考着如果在未来避免同样的问题。下文列举了一些常见。

0. 在我机器上是可以运行的

拜托，这可是开发人员最常用的借口，《程序员给测试人员的20条高频回复》中的第一条就是它了。我们总是觉得测试或者用户有着某种神奇的电脑，能在我们的代码里填充着原本不存在的程序错误。这，完全不是真的。

唯一可以避免这种借口的方法是意识到开发，测试和产品运行环境。想要做到这点，第一你需要问的就是，这是什么样的产品运行环境，得到更详细的问题咨询，并进一步查看这是不是一个合理的问题。另一种方法是，建立一个持续集成的环境，同样的代码，在同一个环境内的某些机器上开发，另一些机器上测试。

1.你用最新的版本了嘛？

这是另一个借口。没有使用最新的版本，或者测试了错误的版本是一个颇为常用的借口。这也并不是不可以避免的事情。

去避免这个借口的唯一方法，就是建立一个过程，验证测试使用的是最新的版本。在一个持续集成的环境里，代码自动归档，生成新的版本并在同时部署在测试的机器上。另一个方法去验证正在测试的版本和开发的版本相同。

2.一定是配置问题

如果你告诉我这个，我一定会说，“对啊，可能是个配置问题。所以，你能告诉我是哪里的配置出了问题了嘛？”如果你遇到相似的情况，你也很有可能问类似的问题。正如你所预料到的，人家在这个问题是寻找一个确切的答案，而不是泛泛之词。

避免这个借口的最佳方法，是把所有配置相关的参数都定义在分开的配置文档里，并把动态值写进日志中，所以一旦出现混淆，总是可以参考配置文档里的说明，来避免分歧。在运行的过程中使用文档规定的格式，可以使错误率降到最小。到时候，即使问题真的是由配置产生的，我们也可以轻松发现并找到解决方案。

3.请建立一个错误报告，我等下去查这个错误

从我的角度看，在确定是否是错误前就直接建立错误报告，是个蛮大的问题。这个问题，既可能是在过程中被追踪着，也可能在测试人员和开发人员中间的协调问题。一般来说，测试人员和开发人员可以联合作业，以防测试并不能真的追查到是否是开发错误。

避免这个问题的方法是，建立良好的测试人员和开发人员之间的关系。这样子，开发和测试之间会沟通，讨论并积极的寻找解决方案。

4. 试试重启机器

杀手级的借口。我也做过同样的事情。确实，这真的能解决不少微软相关的技术产品上（比如说，.NET），而且在某些特殊的情况下，重启还是很起作用的。科学有效解决了相当多的微软相关的开发软件的某些错误。当然，更多的情况下，这样子是没啥结果了。

避免这个借口的方法和上面列举过的某个方法很类似： 我们需要注意开发环境、功能性、架构和代码设计。通过这些，我们可以确定这是否是一个真的软件开发错误。

5. 我不确定这是否能运行，让我看看

我个人非常讨厌这个借口。作为开发人员，如果你不确定某个特定功能是否能运行，这表示，要么你根本没有准确的明白这个开发的功能，要么你没有明白这个程序的设计。

解决方案：建立模块在心中的映射，一旦被告知问题，开发人员能立刻去分析问题，并找到问题的根源。如果不能确定问题根源，要么是没有设计好的代码，要么就是对功能或模块没有完全理解。

6. 五分钟前它还能正常运行

多可爱的回复。我猜你刚刚放下了一个定时炸弹在那里，确保了这软件5分钟以后一定不能正常运行。

解决方案： 意识到时间并不能改变程序，除非这是段专门处理时间的程序。因此任何其他的功能都不能应该受到时间的影响。

7. 我觉得我的程序没有任何问题

我一般不会给出这个答案。我相信在一个团队中，没有一个东西可以被称为是我的东西。我宁愿说哪个模块也许错了。这个借口是在尝试着去找个人背黑锅，绝对不利于团队的最大士气。

解决方案： 建立团队文化，让每个团队成员都对整个项目有了解认识，能够从全局把握项目，以项目经理的角度来看待发生的每个问题，一个开发人员尽心尽责的只负责某一个特定的模块。