CoolShell弱爆程序员的特征值CoolShell:弱爆程序员的特征值2011年08月23日首先说明：1、以下特征是真实遇到过的，同事犯过的，乃至我自己也犯过的；2、为了剧情需要，某些例子进行了一些夸张修饰等演绎创作，如无雷同，请勿生气；3、如果你出现过以下症状之一，并不代表你就是弱爆了，但是如果你一直出现，乃至一说到这个大家就能联想到你，那么你就得小心了；4、如果你是集这几个的大成者，恭喜你，你已经找到了离开这个行业的充足理由了。好了，搞定！“那个Bug解决了吗？”“好了，搞定！”“这么快？”正当你非常欣喜的时候，就传来了噩耗：刚才还能编译成功的，就失败了。（好吧，我们的集成编译尚未成功配置上，理论上这种事情应该会被退回。）又或者能编译成功，但是呢，原来明明能起作用的一个下拉框，突然发神经的不起作用了。最隐蔽的莫过于，一切正常，但是当你看到代码的时候，你就晕厥过去了。比如我们曾经发现了一个Bug，简单说就是每次用户点击某个东西，就会执行下面的这段C#代码：这个Bug很明显会导致速度越来越慢，因为同一个更新操作会被更新N次，并且这个N会越来越大。其实这个Bug已经够弱了，但是后来居然被修改为：这段代码能编译，能执行，但是就是弱爆了。因为这不仅仅没有从根本上去掉造成问题的逻辑，还会带来更多的困惑：为什么要先减后加呢？这类特征，请大家看看有趣的《各种流行的编程风格》，我这个例子算是一种撞大运。我觉这吧，这类问题都是因为只想解决一些表面的东西为目的，完全不管底下的其它任何问题而造成的。那估计是他的Bug“这个问题为啥还没解决呢？”“我觉得应该是他那里边的Bug，我调不了。”“哦……”这个“他”可以是某一位同事，或者前同事，或者微软，或者别的什么公司，再或者某个开源代码的作者。这些个我都遇到过，比如说是另一位现在在职的同事吧。当你告诉这位同事这个Bug似乎在他那儿，并且问问什么时候解决，他也许会很愧疚的立刻调试，可最后结果却仍然是开头对话主人翁的所写代码的问题。再比如说是微软吧，那么对话可能就会包括：“啊，SilverLight真是烂，老是内存泄漏、崩溃等……”“是啊是啊！烂死了！早知道用Flash了。”又或者会说：“微软就是烂，Java就是好。”其实，我不想比较什么SilverLight还是Flash，还是Java。因为在讨论这些问题之前，先最好想想，这真的是别人的错么？相信是其他人的错是一件很简单的事情，因为这样推脱之后你就可以啥都不做了，反正不是我的错。如果真的发现了这是别人的Bug并证明了，那倒好说。但这种特征是一种纯粹的怀疑，并没有丝毫的证明。在仔细找了自己所有可能犯的错之后，如果你怀疑是别人的问题，那请求证一下。无图无真相！“楼主，无图无真相啊！”“楼主，无代码无真相啊！”“楼主，给翻译一下啊！”据说Linus在别人询问Linux内存管理的一个什么问题时，回答道“Readthefxxxingsourcecode”，很多时候我也有类似的冲动。我发现在信息发达的时代，不少人的阅读能力、动手能力都严重退化了。这些人最好就是你亲自来帮他把问题解决了，他才不想了解里面到底发生了什么。这种问题体现在博客里面，就是寄希望于你写得图文并茂，图嘛最好花里胡哨同时言简而意概，文字嘛最好大段大段的代码。其实图不是重要的，只是为了好看，重点是代码，这样他一Copy就可以直接解决他们的问题了。比方说，Silverlight里面没有各种图像格式的编码器，于是当你希望保存Jpg的时候怎么办呢？Google一下，发现原来有人写过一个Flu习近平eg的编码器。下载下来一跑，唉还真能用哎。之后就直接签入，也不捎带看一下有没有什么问题，或者设计不合理的地方。（其实真的有，会很慢，因为有大量毫无必要的数组拷贝。）又或者说，遇到了某个Bug，搜索一下发现，哎，还真有人遇到过，而且还有代码哎！把代码扒下来一跑，发现好像解决了，至于为什么就不管了。甚至还遇到过根本就不管解决不解决问题，反正代码扒下来了就签入了的。再比如，写一篇博客讲解如何缩减编译出来的文体大小，其中提到许多概念需要先阅读微软官方的一个文档。结果，还是会有人回复说，你那个文章里面提到那么多的Blob，也不说...