首先说明：

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是什么？”

“是一个变量”

“啊？”

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

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

（全文完）

首先，我们有一个表达式如下所示：

s = 7;

很明显，这个表达式的变量名太没意义了，很不利于程序的可读性，所以，我们需要取一个有意义的变量名：

slots = 7;

很好，不过，那个常量7是hard-code或是一个Magic number，而且，这常量没有名字也不利于代码的可读性啊。再改：

SEVEN = 7;
...
slots = SEVEN;

靠！上面，是这是哪门子的改法？（不过，我保证这是真实发生的），常量名也要有意义一点嘛，再改：

SLOTS_PER_WIDGET = 7;
...
slots = SLOTS_PER_WIDGET;

这还差不多，不过，名字可能会重名啊，最好放到一个类中：

import widgetConstants;
...
slots = widgetConstants.SLOTS_PER_WIDGET;

现在看起来好很多了，不过，即然面向对象了，我们当然要学会使用Design Pattern，比如Factory啊，或是Singleton啊什么的：

widgetModelFactory = WidgetModelFactory.getInstance();
widgetModel = widgetModelFactory.getWidgetModel() ;
slots = widgetModel.getSlotsPerWidget();

当然，要是考虑到整体的类结构，上面的那些还不够，下面是我们最终的重构代码：（欢迎来到真实的Java世界）

context = Context.getCurrentContext();
serviceDirectoryFactory = ServiceDirectoryFactory.getServiceDirectory(context);
serviceDirectory = serviceDirectoryFactory.getServiceDirectory(context);
serviceDescriptor = ServiceDescriptorFactory.getDescriptor("widgetModelFactory");
widgetModelFactoryServiceLocator = serviceDirectory.getServiceLocator(serviceDescriptor,context);
widgetModelFactory = (WidgetModelFactory)widgetModelFactoryServiceLocator.findService(context);
widgetModel = widgetModelFactory.getWidgetModel(context);

slots = widgetModel.getSlotsPerWidget();

这就是我们的面像对象的编程模式，记得N年前在面试那家著名的以鼓吹敏捷方法论的公司时，在用程序实现一个程序题的时候，他们对我的程序很不屑一顾，原因有两个，其一、我没有使用TDD写UT Case，其二、我的程序里没有设计模式。（我才知道，编程原来是为了测试和设计模式，而不是为了原来的需求），今天，仅以此文献给钟爱于那些流行编码风格的程序员们。

其实，这段代码也是如下而已罢了。

slots = thisWidget.getSlotCount();

(全文完)

散弹枪编程

这种编程风格是一种开发者使用非常随意的方式对待代码。“嗯，这个方法调用出错了……那么我会试着把传出的参数从 false 变成 true!”，当然依然出错，于是我们的程序员会这样：“好吧，那我就注释掉整个方法吧”，或是其它更为随意的处理方式，直到最后让这个调用成功。或是被旁边的某个程序员指出一个正确的方法。

如果我们把一个正规的程序员和一个撞大运的程序员放在一起做结地，那么，那个正规的程序可以马上变得发疯起来，并且，可以把正规的程序员的智商降到最低。两个撞大运的程序员不应该在一起做结对编程，这是因为他们破坏性的才能会造成的伤害会比只有一个还差。

撞大运编程

这是一种比散弹枪编程要温和一些的编程方式，我相信这种方式可能会是大多数程序员都会使用的方式。这种编程方式经常出现于程序员并不确切知道他们在干什么，也不知道所写的程序的本质和实际，但是可以让程序工作起来。他们以一种撞大运的方式在写程序，某些时候，他们根本就不知道某个错误的原因，就开始稀里糊涂地修改代码。一旦出现问题，他们会用两条路：1）停下来，理解一下程序，找到出错的原因。2）使用散弹枪编程方式开始解决问题。

测试驱动开发（Test Driven Development）是一种可以用来拯救上百万的撞大运编程的程序员。于是，他们有了一个更为NB的借口：只要我的程序通过测试了，你还有什么话好说？别骂我，测试驱动开发是一个不错的事物，其主要是用来控制撞大运开发所带来的问题。

Cargo-Cult 编程

关于Cargo Cults 这个词儿来自二战期间的某些太平洋上小岛里的土著人。在战争期间，美国利用这些小岛作为太平洋战场上的补给站。他们在这些小岛上修建自己的飞机跑道以用来运输战争物资。而那些小岛上的土著人从来没有见过飞机，当他们看到飞机的时候，觉得相当的牛，可以为那些白人带来各种各样的物品和食物。当二战结束后，那些土著人仿照着修建了飞机跑道，并用竹子修建了塔台。然后就在那期望着有飞机为他们送来物品和食物。

Cargo Cult 编程是一种非常流行的编程方法，使用这种方法的程序员会学习其它编程高手的编程方法，虽然他们并不知道为什么高手们要那样做，但是他们觉得那样做可以让程序工作起来。举个例子，当时有大量的程序员在J2EE出现的第一年中过度地使用了EJBs和Entity Beans。

刻舟求剑编程

刻舟求剑是一个很流行的寓言了。这种风格的编程在程序员的圈子里是非常常见的。比如，有一天，你发现了一个空指会的异常，于是你到了产生空指针异常的地方，简单地放上一个判断： if (p != NULL)。

是的，这样的fix可以让你的程序工作起来，但你并没有真正地解决问题。你只不过是在你的船边记下了剑掉下去的位置，这样做只不过把问题隐藏起来，最终只会让你的程序的行为变得神出鬼没。你应该找到为什么指针会为空的原因，然后再解决这个问题。

设计模式驱动型编程

正如这种编程的名字所说的，这种编程风格使用大量的设计模式，在你的程序中，四处都是设计模式，你的代码到处都是Facade，Observer ，Strategy，Adapter，等等等等。于是，你的程序要处理的业务逻辑被这些设计模式打乱得无法阅读，最后，也不知道是业务需求重来，还是设计模式重要，总之，实际业务需求的程序逻辑被各种设计模式混乱得不堪入目。

侦探型编程

在解决一个Bug的时候，侦探型程序员会调查这个Bug的原因。然后，则调查引发这个BUG的原因的原因。再然后，其会分析修正代码后是否会导致其它代码失败的因果关系。再然后然后，他会使用文本搜索查找所有使用这个改动的代码，并继续查找更上一级的调用代码。最后，这个程序员会写下30个不同的情形的测试案例，就算这些测试案例和那个Bug没有什么关系，最最后，这个程序员有了足够多的信心，并且精确地修正了一个拼写错误。

与此同时，其它一个正常的程序修正了其它5个Bug。

屠宰式编程

使用这种风格的程序员，对重构代码有着一种难以控制的极端冲动。他们几乎会重构所有经手的代码。就算是在产品在Release的前夜，当他在修正几个拼写错误的bug同时，其会修改10个类，以及重构与这10个类有联系的另20个类，并且修改了代码的build脚本，以及5个部署描述符。

文章：来源
（全文完）