弱爆程序员的特征值

【感谢网友sumtec投递此文，很欢乐也有意思，与大家共勉】

首先说明：

1、以下特征是真实遇到过的，同事犯过的，乃至我自己也犯过的；
2、为了剧情需要，某些例子进行了一些夸张修饰等演绎创作，如无雷同，请勿生气；
3、如果你出现过以下症状之一，并不代表你就是弱爆了，但是如果你一直出现，乃至一说到这个大家就能联想到你，那么你就得小心了；
4、如果你是集这几个的大乘者，恭喜你，你已经找到了离开这个行业的充足理由了。

好了，搞定！

“那个Bug解决了吗？”

“好了，搞定！”

“这么快？”

正当你非常欣喜的时候，就传来了噩耗：刚才还能编译成功的，就失败了。（好吧，我们的集成编译尚未成功配置上，理论上这种事情应该会被退回。）又或者能编译成功，但是呢，原来明明能起作用的一个下拉框，突然发神经的不起作用了。最隐蔽的莫过于，一切正常，但是当你看到代码的时候，你就晕厥过去了。比如我们曾经发现了一个Bug，简单说就是每次用户点击某个东西，就会执行下面的这段C#代码：

controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;

这个Bug很明显会导致速度越来越慢，因为同一个更新操作会被更新N次，并且这个N会越来越大。其实这个Bug已经够弱了，但是后来居然被修改为：

controlPropertyPanel.PropertyChanged -= this.UpdatePropertyOnChanged;
controlPropertyPanel.PropertyChanged += this.UpdatePropertyOnChanged;

这段代码能编译，能执行，但是就是弱爆了。因为这不仅仅没有从根本上去掉造成问题的逻辑，还会带来更多的困惑：为什么要先减后加呢？

这类特征，请大家看看有趣的《各种流行的编程风格》，我这个例子算是一种撞大运。我觉这吧，这类问题都是因为只想解决一些表面的东西为目的，完全不管底下的其它任何问题而造成的。

那估计是他的Bug

“这个问题为啥还没解决呢？”

“我觉得应该是他那里边的Bug，我调不了。”

“哦……”

这个“他”可以是某一位同事，或者前同事，或者微软，或者别的什么公司，再或者某个开源代码的作者。这些个我都遇到过，比如说是另一位现在在职的同事吧。当你告诉这位同事这个Bug似乎在他那儿，并且问问什么时候解决，他也许会很愧疚的立刻调试，可最后结果却仍然是开头对话主人翁的所写代码的问题。

再比如说是微软吧，那么对话可能就会包括：“啊，SilverLight真是烂，老是内存泄漏、崩溃等……”“是啊是啊！烂死了！早知道用Flash了。”又或者会说：“微软就是烂，Java就是好。”其实，我不想比较什么SilverLight还是Flash，.NET还是Java。因为在讨论这些问题之前，先最好想想，这真的是别人的错么？相信是其他人的错是一件很简单的事情，因为这样推脱之后你就可以啥都不做了，反正不是我的错。

如果真的发现了这是别人的Bug并证明了，那倒好说。但这种特征是一种纯粹的怀疑，并没有丝毫的证明。在仔细找了自己所有可能犯的错之后，如果你怀疑是别人的问题，那请求证一下。

无图无真相！

“楼主，无图无真相啊！”

“楼主，无代码无真相啊！”

“楼主，给翻译一下啊！”

据说Linus在别人询问Linux内存管理的一个什么问题时，回答道“Read the fxxxing source code”，很多时候我也有类似的冲动。我发现在信息发达的时代，不少人的阅读能力、动手能力都严重退化了。这些人最好就是你亲自来帮他把问题解决了，他才不想了解里面到底 发生了什么。这种问题体现在博客里面，就是寄希望于你写得图文并茂，图嘛最好花里胡哨同时言简而意概，文字嘛最好大段大段的代码。其实图不是重要的，只是为了好看，重点是代码，这样他一Copy就可以直接解决他们的问题了。

比方说，Silverlight里面没有各种图像格式的编码器，于是当你希望保存Jpg的时候怎么办呢？Google一下，发现原来有人写过一个FluxJpeg的编码器。下载下来一跑，唉还真能用哎。之后就直接签入，也不捎带看一下有没有什么问题，或者设计不合理的地方。（其实真的有，会很慢，因为有大量毫无必要的数组拷贝。）

又或者说，遇到了某个Bug，搜索一下发现，哎，还真有人遇到过，而且还有代码哎！把代码扒下来一跑，发现好像解决了，至于为什么就不管了。甚至还遇到过根本就不管解决不解决问题，反正代码扒下来了就签入了的。

再比如，写一篇博客讲解如何缩减.NET编译出来的文体大小，其中提到许多概念需要先阅读微软官方的一个文档。结果，还是会有人回复说，你那个文章里面提到那么多的Blob，也不说说Blob里面都有什么，大概是很不满意吧。可是这个文档里面都有啊，难道就不能自己阅读一下？其实即便我连这个文档都没有给出，自己也应该有这个能力去进行思考，去动手寻找。

千万不要退化成一个啥都要别人给你嚼烂了才能够吞下去，吞下去也不会消化吸收的人。这样的人大概别人给的是大便，只要有代码无真相，也会照样吃下去的。若真如此，那你打算如何提高呢？

那是个对象！

“这个ExpressionVisitor，它是用来干什么的？”

“……”

“好吧，或者这么说，他是一个什么东西？”

“他是一个对象！”

“啊？”

“哦，是一个对象的实例。”

大概这样的回答，和那个微软工程师说“你在直升飞机上”差不多——反正你也不能说是错的，但是就是没什么意义。其实不知道没啥问题，人又不是神，怎么可能都知道呢？不去仔细了解和学习问题也不严重，因为你可以改。但是当你习惯性的随便找一个绝对没错但又不说明任何问题的答案，甚至似是而非的东西来对付的时候，你就离弱爆的边缘很近了。

当然，上面的对话也许是比较极端的。一个稍弱一点的对话版本是：

“这个内存泄漏是怎么造成的呢？”

“嗯，会不会是图片放的位置不对呢？”

哈，还是很夸张对吧？没办法，写博客有时候需要夸张的文字，否则你无法理解我的意思是：有时候，大家会倾向于从自己的记忆中寻找一些相似的物品，然后选择相似度自认为比较高的东西出来当作答案，而全然不管两者之间的逻辑是否有哪怕那么一丝的关联。也许很多时候，我们确实需要从相似的东西开始，但请别把他当作终点。程序是需要严谨的逻辑的，所以你也必须非常严谨的去推演。

关于这类的问题真的太多太多了，比如我指着下面这段代码当中的红字：

var dictionary = new Dictionary<string, string>();
dictionary["someKey"] = “someValue”;

“这句话说明了什么？”

“说明dictionary是一个数组。”

集大成者

最后我举一个集大成者的例子，说，有个任务是要在SilverLight应用上面添加一个“收藏本站点”。好，怎么解决呢？网上一搜，发现有很多这样的代码：

function AddBookmark(Url, LabeName) {
  if (document.all)
  {
    window.external.addFavorite(Url, LabeName);
  }
  else if (window.sidebar)
  {
    window.sidebar.addPanel(LabeName, Url, '');
  }
}

然后直接扒下来就放上去了，通过某种方式在SilverLight中调用这段JavaScript，签入，搞定了！结果到了测试那边发现完全不能用，无论在IE6/7/8/9/10，还是在FireFox/Safari/Chrome上面，都不能使用。我问：

“这是什么原因呢？”

“不知道，反正浏览器报告没有权限，可能是浏览器的安全设置原因吧，或者操作系统的Bug，也可能是浏览器的某种Bug？”

“不可能啊？这些代码存在很多年了，要有问题早就能在网上搜索到了。”

“那也许是SilverLight调用的时候有什么安全问题。哎！SilverLight好烦啊！”

“那怎么还没有解决呢？”

“好，我马上解决它！”

很快，那段Javascript就变成了：

function AddBookmark(Url, LabeName) {
  try
  {
    if (document.all)
    {
      window.external.addFavorite(Url, LabeName);
    }
    else if (window.sidebar)
    {
      window.sidebar.addPanel(LabeName, Url, '');
    }
  }
  catch
  {
    alert("您的浏览器因为安全设置的问题无法收藏，请手动添加收藏！");
  }
}

看到这样的代码，我彻底震惊了。亲自调试了一下，发现确实报告了一个“没有权限”的异常。但是，我还发现，那个Url参数的值是“www.adomainname.com\test\page.html”。那这不废话么！浏览器认为你要收藏的是一个本地硬盘上的路径，怎么可能在一个Internet Zone上允许收藏这种路径呢？我于是指着代码问：

“这个Url是什么？”

“是一个变量”

“啊？”

“哦，不对，是一个参数。”

你是否也有类似的经历呢？

（全文完）

相关文章

• 2010年09月25日 -- 代码重构的一个示例
• 2010年01月22日 -- 各种流行的编程风格
• 2011年08月16日 -- 重构代码的7个阶段
• 2011年08月01日 -- 你确信你了解时间吗？
• 2011年07月18日 -- 程序员技术练级攻略
• 2011年07月12日 -- 给程序员新手的一些建议
• 2011年07月06日 -- 软件公司的两种管理方式