程序员第一法则：都是你的错！

测试小姐姐: 这个地方显示有问题，兼容性不好！

程序猿哥哥: 我的浏览器怎么没有？你用Chrome吧!

测试小姐姐: 刚刚这个按钮点击没响应！

程序猿哥哥: 服务端没有请求日志，你再点一下？

测试小姐姐: 这个导出功能无法导出数据，还会超时！

程序猿哥哥: 咦，OOM了，应该导出的数据太多了，你少导点就没问题了！

程序员第一法则：都是你的错！不用怀疑！！！

每个程序员都知道这种感受，因为我们都曾经遇到过这种情况：反复看了无数遍代码，仍然没有找出问题的原因。程序员总会遇到一些BUG或者错误，可能是代码的问题，可能是你写代码的机器的问题，或者运行的操作系统的问题，甚至是正在使用的工具或者类库的问题！

一次又一次对抗有难度的，很隐蔽的BUG是很令人沮丧的，但是不要让绝望让你误入歧途。 作为一个谦虚的，优秀的程序员的一个重要部分就是意识到：只要是你编写的代码就会出问题，而且都是你的错！

在许多项目中，你正在DEBUG的代码可能混合了你写的代码，项目组其他人写的代码，第三方产品（例如数据库，工具类库，通信方式&算法等），平台环境（操作系统，系统库，编译器等）。

这样一来，BUG可能在操作系统中，也可能在编译器中，也可能在第三方产品中，但是这不是你首先需要思考的。你更应该思考的是在开发环境中，应用的BUG是否存在。通常我们更应该假设应用代码以错误的方式调用了第三方库，而不是假设第三方库本身的问题。即使问题真的存在第三方库中，在提交BUG前，我们应该想办法修改自己的代码来规避它。

我们参与过一个项目，一个高级工程师确信在Solaris操作系统上的select系统调用被破坏了，任何劝说都改变不了它的想法（事实上在这个环境上其他应用运行良好）。它花了一周时间写解决方法，但是这些方法似乎并不能修复这个问题。

当最终聚焦在select的文档上时，他发现了问题，并且只花了几分钟就纠正了这个问题。现在当任何人开始把错误的原因归咎在系统上，而不是找自己的问题，我们就会用"select is broken"这个短语作为一个善意的提醒。

代码所有权的另一面是代码责任。无论你的软件出了什么问题可能甚至都不是你的代码你一定要假设问题就出在你的代码中，承担所有出现的问题的责任，即使某些责任你不必承担。这就是你赢得尊重和信任的方式，通过甩锅给其他人，其他公司是肯定无法赢得尊重和信任的。

统计表明，你负责的软件程序中任何BUG或者错误不是你造成的概率是极低的（换句话说，你的程序出错基本上都是你造成的！）。Steve McConnell引用两个研究来证明这一点：

在1973年和1984年两次研究表明，所有的报告的错误中，大概有95%是程序员造成的，2%是系统软件（编译器或者操作系统）引起的，2%是其他软件引起的，只有1%是硬件造成的。

今天使用系统软件和开发工具的人远比70年代和80年代多的多，因此我大胆的猜测，今天的错误，程序员造成的概率比以前（95%）要更高。（操作系统和开发工具用的人越多，发现的问题越多，从而会让它们越来越完善，出错的概率也越来越低）。

所以，你的软件无论出现什么问题，首先检查你的代码，然后慢慢向外排查，直到你能非常明确的证明问题所在。如果问题出现在一些你不能控制的代码中，你不仅学习到了必要的故障排除和诊断技能，而且得到证据支撑你的申明（这个锅确实不是我的锅）。

这个过程肯定是痛苦的，需要你付出巨大的努力，远不是轻易的下个定论说操作系统，工具，或者框架有问题那么轻松。但是它会产生一种信任感和尊重，这些东西是不可能通过妄下定论或者逃避能获得的。

如果你真的渴望成为一个谦虚的，优秀的程序员，你应当毫不犹豫的说：这是我的问题，我会找出原因。

摘录一些有趣的回复：

always your fault

always your fault

always your faultalways your faultalways your fault

翻译来源：https://blog.codinghorror.com/the-first-rule-of-programming-its-always-your-fault/