同事跟我说，在某个类里面，有个 populate 方法可能有 bug。我随机打开那个类文件，查找一个叫 populate 的方法，那个具体步骤是这样（不具体的话看不出来到底会浪费多少时间），IDE 里用 pop 开头来过滤方法列表，但很遗憾，没看到叫 populate 的方法，却有以 populate 为前缀的几个方法。于是向同事确认，他也没看就说，就叫 populate。我还是相信他的，于是猜想可能是代码没更新，接着做更新，还是没有，可能不在 trunk 上而在分支里，几番周转无果，回到最初的类文件，绝望之中，竟然在方法列表里发现了一个叫 pupulate 的方法。
一股冏上心头泪千行的感觉。作为一个相对底层的类，使用率还不低的情况下，居然有个方法名字错了整整一年甚至更长。
同样是错误，那个 github 史上评论最多的一次 commit（原地址已经 404，可以看其它人的文字记录 或者 google “github giant bug”来重温）。那个要命的空格，让我笑到肚子疼。
rm -rf /usr /lib/nvidia-current/xorg/xorg
好歹人家也可怜地表示 sorry 了。
是不是一个错误只要不影响软件的正常使用，就无须为一些错误感到内疚，甚至会继续延续下去？
在日常开发当中，错误被忽略被延续的情况时有发生。程序员的基本技能技能 ctrl+c, ctrl+v ( or ⌘C, ⌘V ) 以及 IDE 的自动补全就是延续错误的帮凶（当然 IDE 是无罪的，如果没有第一次错误，IDE 是不会乱搞恶作剧的）。延续错误似乎是零成本的，但是修正却是有成本的，会带来不稳定的感觉。
只是延续错误是不是真的是零成本，怎么看待就取决于你的想象力有多丰富了，或者说经验有多丰富了。我们知道 墨菲法则 那句著名的，“凡是可能会出错的事必定出错”，而且我们还知道屋漏偏逢连夜雨，那种疼不是蛋都碎了可以形容的。我就不再举个实例证明了，相信那种疼还是很容易理解的。对错误及其影响的低估，会使人产生侥幸的心理。
（苏州国际科技园一期就在雨期来临的时候，天花板缺了那么一大块，天天滴水，一个月过去了，不知道会不会跟臭氧层空洞一样慢慢变大。）
即使延续错误是零成本的，但是每一次错误的延续都会增加问题修复的成本。出来混代码，迟早是要还的。我想的是公平一点的情况，自己还自己的，应该是比较容易理解和接受的。比如项目只有你一个人的情况（虽然也有点特殊）。难以接受的是人家把错误复制 N 遍了，却轮到你了！你或者会想，后面还会有人。嗯，的确，很有可能，而那个人精通问候的技能甚至会点咒语什么的也是很有可能的。能够制止别人作恶的人正是你了。“Save the Cheerleader, Save the World”。
突然又想起 去年 10 月轰动一时的 小悦悦事件。那场悲剧，她的生命，并不仅仅是因为遇上了车祸，碾了两回，还遇上了十八个“冷漠”的“不作为”的路人。不知道是讽刺还是欣慰，这件事情的广泛传播，让人们再次思考生命的意义，社区生活的责任和道德。
估计是不会有人希望生活在没有安全感的社区里的。类似地，是没有人希望在一个糟糕的团队里工作的。正因为错误是必定会出现的，但是它能不能在代码里持久化则完全是人的质量问题了。如果你拿到一份比较严谨的代码（注意这和 bug 少，质量高不是一个概念），除了意味着开发者和你所认为的理所当然是一致的，还意味着开发者会注意约束自己，并为此付出了许多，是专业的，是值得鼓励和赞许的。
最后补充说明一下，通常“错误”是会包含但不限于 bug 的会产生非预期影响效果的情况，这里的错误是特指并不是 bug 的那部分。因为 bug 许多时候有任务指派，是必须消除的，但哪些错误则很少有相应的配套设施。