最近几天，微博上有一个戏谑的帖子，把程序员按照等第分为了几档，从“死掉的程序员”开始，有“成功程序员”，“著名程序员”，“普通程序员”，“无名程序员”，“烂程序员”，等等几个档次。按照描述，我对号入座，觉得自己现在算得上是“无名程序员”这个级别，在中国，处于我这个级别的程序员有千千万万，也就是人们常说的“码农”。《代码大全》这书，依我看，其面向读者群，就是“码农”。

   我推己及人一下，我觉得每个下决心买这本书的人，都是有一定的原因的，反正我不会因为看到封面四个字“代码大全”而去买这个砖头书，这四个字，看起来要么像是以前初学编程时候，那种“js特效一千例”，找到你要用的例子，拷贝，粘贴，就能极大程度提高你的生产力的那种“食粮”；要么就像“成语大全”，“歇后语大全”一样的字典一类的东西。如果你联想到了上面两种东西，那要产生花几乎100块钱而去买这么一本书动力，就很困难了。我回忆了一下，我自己买这书的原因，大体是因为“著名程序员”和“成功程序员”的推荐，我是码农，整天扑在代码生产的一线，日子重复，枯燥，最最让人感到不能忍受的是迷茫，不知道自己将去向何方，应该去向何方。所以这个时候，一般都是看看“著名程序员”，“成功程序员”的道路，以期望照亮自己的道路。于是，就有了买这本书的理由。

   我看了下扉页的签名，购买于10年6月17日，迄今超过2年了，仍旧没有看完。如果正态分布是真理的话，那我猜测，购买了此书的，极少人完整阅读过此书，也极少人一页都没看。你们会在书的前言部分，看到各种“成功程序员”，“著名程序员”，“普通程序员”的推荐辞，但是你们大约没法看到像我这样的一个“码农”，聊聊这本书。这是我第一次聊这本书，以后应该还会聊一次，我想是在我看完了之后。

   前面说了我被什么蛊惑而买了这本书，被什么蛊惑下决心去看。接下来说说为什么这本书这么“难看”。

   “难看”点一，始于枯燥。McConnell，作者被称为是软件工程的专家，当然，我不熟悉他，就像不熟悉每个老外一样。这本书，把软件工程的一般管理过程放到全书的第一个部分，虽然，流程之类的东西很重要，但是如果丢给一个“码农”一大摞文档，只为了说明某流程多么重要，可以想见这个东西有多不受欢迎。这本书，就这么开始了。花了几乎30页讲两个问题，一个是“为什么码农写代码(软件构建)很重要”，另一个是“用什么样的比喻(隐喻)描述码农写代码(软件构建)这件事情比较合适”。如果我猜测没错，大部分中国读者都会觉得，这两个问题，真的很那什么。30页，足够消磨一个程序员阅读的兴趣了。如果拿做爱来比喻，前戏大概有125页，这还是中译本，考虑到汉语比英语精炼，原著的前戏大概要有200页了。对比下，《Learning Ruby》影印版一共才200多页。

   “难看”点二，太合乎常识。程序＝算法＋数据结构；程序包含顺序、分支和循环；编写代码最重要的是管理复杂性；类应该有良好的抽象、封装和接口……这些东西，都是每个一线码农或多或少知道的东西，内心有认识的东西，未必能说出来，或者这么有条理的写出来，但是多少都知道一点。于是乎，你看这书，就好像，不断的意料之中嘛。

   这本书到底该不该看呢？问出这个问题后，我很纠结要怎么回答。我觉得这本书里说到的很多东西，都是很基础的实践要求，也是有远见的做法，但是就像我上面说的，很多都没有超出常识太多。但是从我实际从工作中看到的各种人的代码来看，很多人都没有坚持用比较好的方案去做事情，但是你要问及他们，他们总是有各种选用比较差的方法的理由。对于这种人，最应该看这书，但是他们看完了还是依然故我，那不是浪费时间么？对于另一部分人，他们有类似这样的常识，也确实会应用到实践中去，这样的人，看书，估计就是有共鸣，不断有共鸣，但是我已经是这样做的了。看完又觉得收获不大。仿佛也没有什么看的必要。

   如果说，我自己要看的理由，第一个就是我花了快100块，不应该浪费(追加沉没成本投资，不理智)；第二是，以后你吹嘘这书有多牛逼，或者批判这书有多傻逼，你最最起码，应该通读过一遍吧(码农的可悲自尊)；第三，这书其实还是有一点营养的，至少把敲代码这件事情，讲得这么系统，还是绝无仅有的一本书。但是，如果要我像“李维”，“潘爱民”之流，写出那么肉麻而虚伪地推荐辞，我是万万办不到的。这本书，应该就是那种你通读一遍之后，觉得“我知道了”的书，或许会想起来再翻下，但是你绝不会想翻纸质版，你更愿意google，很难成为“书架上占据重要地位，不曾移开”的书，《鹿鼎记》还更有可能一点。“在众多编程书籍中，如果只能挑一本”，我也绝不会挑这本书，又厚，又重的，说不定挑《设计模式》还更好一点。