分类目录归档:杂

小bug,大智慧【轉】

摘自:

http://codebay.cn/post/1345.html?1487994910683

 

程序员和BUG之间的关系很奇妙, 相互都不喜欢对方, 又离不开对方, 是一对相爱相杀相互纠缠永远无法摆脱对方的对手。

每一个BUG都是程序员无意创造出来的,程序员对于BUG的态度完全是恨的咬牙切齿。 很多场景下,当有人反应程序员写的程序有BUG的时候, 程序员的第一反应是这个BUG肯定不是自己的代码有问题产生的, 而是由外部因素起的。比如说某张网页显示效果出错, 前端程序员第一反应肯定是用户的浏览器有缓存或者使用了什么老掉牙的浏览器在浏览他做的网页; 再比如说某个程序访问数据库出错, 后端程序员第一反应也肯定不是自己写的SQL或代码有问题, 而是怀疑是不是数据库或服务器出了故障。

多人开发的项目中, 在BUG的生产者难以界定的情况下尤其如此,当出现BUG时, 程序员一般的应对方法是:“你去找某某某, 这显然是他的问题。”,然而,结果往往是啪啪啪的打自己脸。

小bug,大智慧0

这也难怪, 自己一行行写的代码, 调试,运行,上线,像自己儿子一样养大的, 但是在毫无征兆的情况下儿子突然去干坏事了,这种意外的情形下很难不认为儿子是被坏人给带坏的。 然而, 世事无绝对, 意外意外那自是意料之外的事情,永远不会和自己的逻辑在同一个方向上,有的事情就是借你一百个脑袋也想不到居然会是这种结果,程序的BUG也是如此。

小bug,大智慧1

前段时间我们部门开发一个Java程序,有新的同事要参与进来,开发环境和运行环境都装好了, 但是跑程序的时候速度奇慢, 别人的电脑上5秒钟运行的程序在这里需要跑1分钟左右才能出结果, 显然这是难以接受的。 从代码、数据库到开发环境、Java编译器、Java虚拟机都仔细检查了一遍也没有找到原因, 软件从64位换到32位,服务器从六点几版本换到九点几版本, 但是该慢还是慢,问题照旧。正在快要绝望的时刻,我无意间发现程序的代码居然不是放在本地的, 而是在映射到本地的网络磁盘上。 如果是这样, 不慢就见鬼。运行程序需要先把代码下载到本机, 再编译运行, 所有花掉的时间居然都在网络传输的开销上面。 这就是完全出人意料的情形了, 因为在思维先入为主的情况下, 谁能想的到源代码不在本地机器上而在网络上, 假如没有线索, 能想的到那脑洞该有多大。小bug,大智慧2

这个例子是网友分享的,我当时看到就笑喷了。 一前端哥们,开发基于微信的应用, 调用微信接口来获取用户的信息,因为有Android和iOS双平台, 所以这哥们向同事借了个手机调试Android平台的版本。 在调试的过程中Android上的应用怎么也获取不到用户的昵称, 调用接口返回的结果总是null, 而在iOS平台上一切正常。 这位仁兄心急火燎的, 想尽办法也束手无策, 微信文档看的都快背熟也找不到获取不到昵称的原因。 后来,借给他手机的那位同事告诉他, 他微信用户的昵称就叫做null小bug,大智慧3

可以设身处地的想想那位仁兄的心情, 杀人的心都有了吧。这样的BUG,就算是专业的编剧也没有这份想像力想的到,更何况是注重逻辑的程序员了。

所以, 程序员千万不要对自己的代码太有信心, BUG永远出在你意想不到的某个角落。 碰到BUG的时候,首先找找自己的原因,在拿到充足的证剧的情况下,再可以去怀疑别人, 这样即节省了时间提升解决BUG的效率,也免得到时候发现其实的是自己的原因时而打自己的脸,啪啪啪啪啪…真的很痛!

小bug,大智慧4

 

编程的智慧【轉】

摘自:http://www.yinwang.org/blog-cn/2015/11/21/programming-philosophy/

编程是一种创造性的工作,是一门艺术。精通任何一门艺术,都需要很多的练习和领悟,所以这里提出的“智慧”,并不是号称一天瘦十斤的减肥药,它并不能代替你自己的勤奋。然而由于软件行业喜欢标新立异,喜欢把简单的事情搞复杂,我希望这些文字能给迷惑中的人们指出一些正确的方向,让他们少走一些弯路,基本做到一分耕耘一分收获。

反复推敲代码

既然“天才是百分之一的灵感,百分之九十九的汗水”,那我先来谈谈这汗水的部分吧。有人问我,提高编程水平最有效的办法是什么?我想了很久,终于发现最有效的办法,其实是反反复复地修改和推敲代码。

在IU的时候,由于Dan Friedman的严格教导,我们以写出冗长复杂的代码为耻。如果你代码多写了几行,这老顽童就会大笑,说:“当年我解决这个问题,只写了5行代码,你回去再想想吧……” 当然,有时候他只是夸张一下,故意刺激你的,其实没有人能只用5行代码完成。然而这种提炼代码,减少冗余的习惯,却由此深入了我的骨髓。

有些人喜欢炫耀自己写了多少多少万行的代码,仿佛代码的数量是衡量编程水平的标准。然而,如果你总是匆匆写出代码,却从来不回头去推敲,修改和提炼,其实是不可能提高编程水平的。你会制造出越来越多平庸甚至糟糕的代码。在这种意义上,很多人所谓的“工作经验”,跟他代码的质量,其实不一定成正比。如果有几十年的工作经验,却从来不回头去提炼和反思自己的代码,那么他也许还不如一个只有一两年经验,却喜欢反复推敲,仔细领悟的人。

有位文豪说得好:“看一个作家的水平,不是看他发表了多少文字,而要看他的废纸篓里扔掉了多少。” 我觉得同样的理论适用于编程。好的程序员,他们删掉的代码,比留下来的还要多很多。如果你看见一个人写了很多代码,却没有删掉多少,那他的代码一定有很多垃圾。

就像文学作品一样,代码是不可能一蹴而就的。灵感似乎总是零零星星,陆陆续续到来的。任何人都不可能一笔呵成,就算再厉害的程序员,也需要经过一段时间,才能发现最简单优雅的写法。有时候你反复提炼一段代码,觉得到了顶峰,没法再改进了,可是过了几个月再回头来看,又发现好多可以改进和简化的地方。这跟写文章一模一样,回头看几个月或者几年前写的东西,你总能发现一些改进。

所以如果反复提炼代码已经不再有进展,那么你可以暂时把它放下。过几个星期或者几个月再回头来看,也许就有焕然一新的灵感。这样反反复复很多次之后,你就积累起了灵感和智慧,从而能够在遇到新问题的时候直接朝正确,或者接近正确的方向前进。

写优雅的代码

人们都讨厌“面条代码”(spaghetti code),因为它就像面条一样绕来绕去,没法理清头绪。那么优雅的代码一般是什么形状的呢?经过多年的观察,我发现优雅的代码,在形状上有一些明显的特征。

如果我们忽略具体的内容,从大体结构上来看,优雅的代码看起来就像是一些整整齐齐,套在一起的盒子。如果跟整理房间做一个类比,就很容易理解。如果你把所有物品都丢在一个很大的抽屉里,那么它们就会全都混在一起。你就很难整理,很难迅速的找到需要的东西。但是如果你在抽屉里再放几个小盒子,把物品分门别类放进去,那么它们就不会到处乱跑,你就可以比较容易的找到和管理它们。

优雅的代码的另一个特征是,它的逻辑大体上看起来,是枝丫分明的树状结构(tree)。这是因为程序所做的几乎一切事情,都是信息的传递和分支。你可以把代码看成是一个电路,电流经过导线,分流或者汇合。如果你是这样思考的,你的代码里就会比较少出现只有一个分支的if语句,它看起来就会像这个样子:

if (...) {
  if (...) {
    ...
  } else {
    ...
  }
} else if (...) {
  ...
} else {
  ...
}

注意到了吗?在我的代码里面,if语句几乎总是有两个分支。它们有可能嵌套,有多层的缩进,而且else分支里面有可能出现少量重复的代码。然而这样的结构,逻辑却非常严密和清晰。在后面我会告诉你为什么if语句最好有两个分支。

写模块化的代码

有些人吵着闹着要让程序“模块化”,结果他们的做法是把代码分部到多个文件和目录里面,然后把这些目录或者文件叫做“module”。他们甚至把这些目录分放在不同的VCS repo里面。结果这样的作法并没有带来合作的流畅,而是带来了许多的麻烦。这是因为他们其实并不理解什么叫做“模块”,肤浅的把代码切割开来,分放在不同的位置,其实非但不能达到模块化的目的,而且制造了不必要的麻烦。

真正的模块化,并不是文本意义上的,而是逻辑意义上的。一个模块应该像一个电路芯片,它有定义良好的输入和输出。实际上一种很好的模块化方法早已经存在,它的名字叫做“函数”。每一个函数都有明确的输入(参数)和输出(返回值),同一个文件里可以包含多个函数,所以你其实根本不需要把代码分开在多个文件或者目录里面,同样可以完成代码的模块化。我可以把代码全都写在同一个文件里,却仍然是非常模块化的代码。

想要达到很好的模块化,你需要做到以下几点:

  • 避免写太长的函数。如果发现函数太大了,就应该把它拆分成几个更小的。通常我写的函数长度都不超过40行。对比一下,一般笔记本电脑屏幕所能容纳的代码行数是50行。我可以一目了然的看见一个40行的函数,而不需要滚屏。只有40行而不是50行的原因是,我的眼球不转的话,最大的视角只看得到40行代码。如果我看代码不转眼球的话,我就能把整片代码完整的映射到我的视觉神经里,这样就算忽然闭上眼睛,我也能看得见这段代码。我发现闭上眼睛的时候,大脑能够更加有效地处理代码,你能想象这段代码可以变成什么其它的形状。40行并不是一个很大的限制,因为函数里面比较复杂的部分,往往早就被我提取出去,做成了更小的函数,然后从原来的函数里面调用。
  • 制造小的工具函数。如果你仔细观察代码,就会发现其实里面有很多的重复。这些常用的代码,不管它有多短,提取出去做成函数,都可能是会有好处的。有些帮助函数也许就只有两行,然而它们却能大大简化主要函数里面的逻辑。有些人不喜欢使用小的函数,因为他们想避免函数调用的开销,结果他们写出几百行之大的函数。这是一种过时的观念。现代的编译器都能自动的把小的函数内联(inline)到调用它的地方,所以根本不产生函数调用,也就不会产生任何多余的开销。同样的一些人,也爱使用宏(macro)来代替小函数,这也是一种过时的观念。在早期的C语言编译器里,只有宏是静态“内联”的,所以他们使用宏,其实是为了达到内联的目的。然而能否内联,其实并不是宏与函数的根本区别。宏与函数有着巨大的区别(这个我以后再讲),应该尽量避免使用宏。为了内联而使用宏,其实是滥用了宏,这会引起各种各样的麻烦,比如使程序难以理解,难以调试,容易出错等等。
  • 每个函数只做一件简单的事情。有些人喜欢制造一些“通用”的函数,既可以做这个又可以做那个,它的内部依据某些变量和条件,来“选择”这个函数所要做的事情。比如,你也许写出这样的函数:
    void foo() {
      if (getOS().equals("MacOS")) {
        a();
      } else {
        b();
      }
      c();
      if (getOS().equals("MacOS")) {
        d();
      } else {
        e();
      }
    }
    

    写这个函数的人,根据系统是否为“MacOS”来做不同的事情。你可以看出这个函数里,其实只有c()是两种系统共有的,而其它的a(), b(), d(), e()都属于不同的分支。

    这种“复用”其实是有害的。如果一个函数可能做两种事情,它们之间共同点少于它们的不同点,那你最好就写两个不同的函数,否则这个函数的逻辑就不会很清晰,容易出现错误。其实,上面这个函数可以改写成两个函数:

    void fooMacOS() {
      a();
      c();
      d();
    }
    

    void fooOther() {
      b();
      c();
      e();
    }
    

    如果你发现两件事情大部分内容相同,只有少数不同,多半时候你可以把相同的部分提取出去,做成一个辅助函数。比如,如果你有个函数是这样:

    void foo() {
      a();
      b()
      c();
      if (getOS().equals("MacOS")) {
        d();
      } else {
        e();
      }
    }
    

    其中a()b()c()都是一样的,只有d()e()根据系统有所不同。那么你可以把a()b()c()提取出去:

    void preFoo() {
      a();
      b()
      c();
    

    然后制造两个函数:

    void fooMacOS() {
      preFoo();
      d();
    }
    

    void fooOther() {
      preFoo();
      e();
    }
    

    这样一来,我们既共享了代码,又做到了每个函数只做一件简单的事情。这样的代码,逻辑就更加清晰。

写可读的代码

有些人以为写很多注释就可以让代码更加可读,然而却发现事与愿违。注释不但没能让代码变得可读,反而由于大量的注释充斥在代码中间,让程序变得障眼难读。而且代码的逻辑一旦修改,就会有很多的注释变得过时,需要更新。修改注释是相当大的负担,所以大量的注释,反而成为了妨碍改进代码的绊脚石。

实际上,真正优雅可读的代码,是几乎不需要注释的。如果你发现需要写很多注释,那么你的代码肯定是含混晦涩,逻辑不清晰的。其实,程序语言相比自然语言,是更加强大而严谨的,它其实具有自然语言最主要的元素:主语,谓语,宾语,名词,动词,如果,那么,否则,是,不是,…… 所以如果你充分利用了程序语言的表达能力,你完全可以用程序本身来表达它到底在干什么,而不需要自然语言的辅助。

有少数的时候,你也许会为了绕过其他一些代码的设计问题,采用一些违反直觉的作法。这时候你可以使用很短注释,说明为什么要写成那奇怪的样子。这样的情况应该少出现,否则这意味着整个代码的设计都有问题。

如果没能合理利用程序语言提供的优势,你会发现程序还是很难懂,以至于需要写注释。所以我现在告诉你一些要点,也许可以帮助你大大减少写注释的必要:

  1. 使用有意义的函数和变量名字。如果你的函数和变量的名字,能够切实的描述它们的逻辑,那么你就不需要写注释来解释它在干什么。比如:
    // put elephant1 into fridge2
    put(elephant1, fridge2);
    

    由于我的函数名put,加上两个有意义的变量名elephant1fridge2,已经说明了这是在干什么(把大象放进冰箱),所以上面那句注释完全没有必要。

  2. 局部变量应该尽量接近使用它的地方。有些人喜欢在函数最开头定义很多局部变量,然后在下面很远的地方使用它,就像这个样子:
    void foo() {
      int index = ...;
      ...
      ...
      bar(index);
      ...
    }
    

    由于这中间都没有使用过index,也没有改变过它所依赖的数据,所以这个变量定义,其实可以挪到接近使用它的地方:

    void foo() {
      ...
      ...
      int index = ...;
      bar(index);
      ...
    }
    

    这样读者看到bar(index),不需要向上看很远就能发现index是如何算出来的。而且这种短距离,可以加强读者对于这里的“计算顺序”的理解。否则如果index在顶上,读者可能会怀疑,它其实保存了某种会变化的数据,或者它后来又被修改过。如果index放在下面,读者就清楚的知道,index并不是保存了什么可变的值,而且它算出来之后就没变过。

    如果你看透了局部变量的本质——它们就是电路里的导线,那你就能更好的理解近距离的好处。变量定义离用的地方越近,导线的长度就越短。你不需要摸着一根导线,绕来绕去找很远,就能发现接收它的端口,这样的电路就更容易理解。

  3. 局部变量名字应该简短。这貌似跟第一点相冲突,简短的变量名怎么可能有意义呢?注意我这里说的是局部变量,因为它们处于局部,再加上第2点已经把它放到离使用位置尽量近的地方,所以根据上下文你就会容易知道它的意思:比如,你有一个局部变量,表示一个操作是否成功:
    boolean successInDeleteFile = deleteFile("foo.txt");
    if (successInDeleteFile) {
      ...
    } else {
      ...
    }
    

    这个局部变量successInDeleteFile大可不必这么啰嗦。因为它只用过一次,而且用它的地方就在下面一行,所以读者可以轻松发现它是deleteFile返回的结果。如果你把它改名为success,其实读者根据一点上下文,也知道它表示”success in deleteFile”。所以你可以把它改成这样:

    boolean success = deleteFile("foo.txt");
    if (success) {
      ...
    } else {
      ...
    }
    

    这样的写法不但没漏掉任何有用的语义信息,而且更加易读。successInDeleteFile这种”camelCase“,如果超过了三个单词连在一起,其实是很碍眼的东西,所以如果你能用一个单词表示同样的意义,那当然更好。

  4. 把复杂的逻辑提取出去,做成“帮助函数”。有些人写的函数很长,以至于看不清楚里面的语句在干什么,所以他们误以为需要写注释。如果你仔细观察这些代码,就会发现不清晰的那片代码,往往可以被提取出去,做成一个函数,然后在原来的地方调用。由于函数有一个名字,这样你就可以使用有意义的函数名来代替注释。举一个例子:
    ...
    // put elephant1 into fridge2
    openDoor(fridge2);
    if (elephant1.alive()) {
      ...
    } else {
       ...
    }
    closeDoor(fridge2);
    ...
    

    如果你把这片代码提出去定义成一个函数:

    void put(Elephant elephant, Fridge fridge) {
      openDoor(fridge);
      if (elephant.alive()) {
        ...
      } else {
         ...
      }
      closeDoor(fridge);
    }
    

    这样原来的代码就可以改成:

    ...
    put(elephant1, fridge2);
    ...
    

    更加清晰,而且注释也没必要了。

  5. 把复杂的表达式提取出去,做成中间变量。有些人听说“函数式编程”是个好东西,也不理解它的真正含义,就在代码里使用大量嵌套的函数。像这样:
    Pizza pizza = makePizza(crust(salt(), butter()),
       topping(onion(), tomato(), sausage()));
    

    这样的代码一行太长,而且嵌套太多,不容易看清楚。其实训练有素的函数式程序员,都知道中间变量的好处,不会盲目的使用嵌套的函数。他们会把这代码变成这样:

    Crust crust = crust(salt(), butter());
    Topping topping = topping(onion(), tomato(), sausage());
    Pizza pizza = makePizza(crust, topping);
    

    这样写,不但有效地控制了单行代码的长度,而且由于引入的中间变量具有“意义”,步骤清晰,变得很容易理解。

说到这里,我必须警告你,这里所说的“不需注释,让代码自己解释自己”,并不是说要让代码看起来像某种自然语言。有个叫Chai的JavaScript测试工具,可以让你这样写代码:

expect(foo).to.be.a('string');
expect(foo).to.equal('bar');
expect(foo).to.have.length(3);
expect(tea).to.have.property('flavors').with.length(3);

这种做法是极其错误的。程序语言本来就比自然语言简单清晰,这种写法让它看起来像自然语言的样子,反而变得复杂难懂了。

写简单的代码

程序语言都喜欢标新立异,提供这样那样的“特性”,然而有些特性其实并不是什么好东西。很多特性都经不起时间的考验,最后带来的麻烦,比解决的问题还多。很多人盲目的追求“短小”和“精悍”,或者为了显示自己头脑聪明,学得快,所以喜欢利用语言里的一些特殊构造,写出过于“聪明”,难以理解的代码。

并不是语言提供什么,你就一定要把它用上的。实际上你只需要其中很小的一部分功能,就能写出优秀的代码。我一向反对“充分利用”程序语言里的所有特性。实际上,我心目中有一套最好的构造。不管语言提供了多么“神奇”的,“新”的特性,我基本都只用经过千锤百炼,我觉得值得信奈的那一套。

现在针对一些有问题的语言特性,我介绍一些我自己使用的代码规范,并且讲解一下为什么它们能让代码更简单。

  • 避免使用自增减表达式(i++,++i,i–,–i)。这种自增减操作表达式其实是历史遗留的设计失误。它们含义蹊跷,非常容易弄错。它们把读和写这两种完全不同的操作,混淆缠绕在一起,把语义搞得乌七八糟。含有它们的表达式,结果可能取决于求值顺序,所以它可能在某种编译器下能正确运行,换一个编译器就出现离奇的错误。其实这两个表达式完全可以分解成两步,把读和写分开:一步更新i的值,另外一步使用i的值。比如,如果你想写foo(i++),你完全可以把它拆成int t = i; i += 1; foo(t);。如果你想写foo(++i),可以拆成i += 1; foo(i); 拆开之后的代码,含义完全一致,却清晰很多。到底更新是在取值之前还是之后,一目了然。有人也许以为i++或者++i的效率比拆开之后要高,这只是一种错觉。这些代码经过基本的编译器优化之后,生成的机器代码是完全没有区别的。自增减表达式只有在两种情况下才可以安全的使用。一种是在for循环的update部分,比如for(int i = 0; i < 5; i++)。另一种情况是写成单独的一行,比如i++;。这两种情况是完全没有歧义的。你需要避免其它的情况,比如用在复杂的表达式里面,比如foo(i++)foo(++i) + foo(i),…… 没有人应该知道,或者去追究这些是什么意思。
  • 永远不要省略花括号。很多语言允许你在某种情况下省略掉花括号,比如C,Java都允许你在if语句里面只有一句话的时候省略掉花括号:
    if (...) 
      action1();
    

    咋一看少打了两个字,多好。可是这其实经常引起奇怪的问题。比如,你后来想要加一句话action2()到这个if里面,于是你就把代码改成:

    if (...) 
      action1();
      action2();
    

    为了美观,你很小心的使用了action1()的缩进。咋一看它们是在一起的,所以你下意识里以为它们只会在if的条件为真的时候执行,然而action2()却其实在if外面,它会被无条件的执行。我把这种现象叫做“光学幻觉”(optical illusion),理论上每个程序员都应该发现这个错误,然而实际上却容易被忽视。

    那么你问,谁会这么傻,我在加入action2()的时候加上花括号不就行了?可是从设计的角度来看,这样其实并不是合理的作法。首先,也许你以后又想把action2()去掉,这样你为了样式一致,又得把花括号拿掉,烦不烦啊?其次,这使得代码样式不一致,有的if有花括号,有的又没有。况且,你为什么需要记住这个规则?如果你不问三七二十一,只要是if-else语句,把花括号全都打上,就可以想都不用想了,就当C和Java没提供给你这个特殊写法。这样就可以保持完全的一致性,减少不必要的思考。

    有人可能会说,全都打上花括号,只有一句话也打上,多碍眼啊?然而经过实行这种编码规范几年之后,我并没有发现这种写法更加碍眼,反而由于花括号的存在,使得代码界限明确,让我的眼睛负担更小了。

  • 合理使用括号,不要盲目依赖操作符优先级。利用操作符的优先级来减少括号,对于1 + 2 * 3这样常见的算数表达式,是没问题的。然而有些人如此的仇恨括号,以至于他们会写出2 << 7 - 2 * 3这样的表达式,而完全不用括号。这里的问题,在于移位操作<<的优先级,是很多人不熟悉,而且是违反常理的。由于x << 1相当于把x乘以2,很多人误以为这个表达式相当于(2 << 7) - (2 * 3),所以等于250。然而实际上<<的优先级比加法+还要低,所以这表达式其实相当于2 << (7 - 2 * 3),所以等于4!解决这个问题的办法,不是要每个人去把操作符优先级表给硬背下来,而是合理的加入括号。比如上面的例子,最好直接加上括号写成2 << (7 - 2 * 3)。虽然没有括号也表示同样的意思,但是加上括号就更加清晰,读者不再需要死记<<的优先级就能理解代码。
  • 避免使用continue和break。循环语句(for,while)里面出现return是没问题的,然而如果你使用了continue或者break,就会让循环的逻辑和终止条件变得复杂,难以确保正确。出现continue或者break的原因,往往是对循环的逻辑没有想清楚。如果你考虑周全了,应该是几乎不需要continue或者break的。如果你的循环里出现了continue或者break,你就应该考虑改写这个循环。改写循环的办法有多种:
    1. 如果出现了continue,你往往只需要把continue的条件反向,就可以消除continue。
    2. 如果出现了break,你往往可以把break的条件,合并到循环头部的终止条件里,从而去掉break。
    3. 有时候你可以把break替换成return,从而去掉break。
    4. 如果以上都失败了,你也许可以把循环里面复杂的部分提取出来,做成函数调用,之后continue或者break就可以去掉了。

    下面我对这些情况举一些例子。

    情况1:下面这段代码里面有一个continue:

    List<String> goodNames = new ArrayList<>();
    for (String name: names) {
      if (name.contains("bad")) {
        continue;
      }
      goodNames.add(name);
      ...
    }  
    

    它说:“如果name含有’bad’这个词,跳过后面的循环代码……” 注意,这是一种“负面”的描述,它不是在告诉你什么时候“做”一件事,而是在告诉你什么时候“不做”一件事。为了知道它到底在干什么,你必须搞清楚continue会导致哪些语句被跳过了,然后脑子里把逻辑反个向,你才能知道它到底想做什么。这就是为什么含有continue和break的循环不容易理解,它们依靠“控制流”来描述“不做什么”,“跳过什么”,结果到最后你也没搞清楚它到底“要做什么”。

    其实,我们只需要把continue的条件反向,这段代码就可以很容易的被转换成等价的,不含continue的代码:

    List<String> goodNames = new ArrayList<>();
    for (String name: names) {
      if (!name.contains("bad")) {
        goodNames.add(name);
        ...
      }
    }  
    

    goodNames.add(name);和它之后的代码全部被放到了if里面,多了一层缩进,然而continue却没有了。你再读这段代码,就会发现更加清晰。因为它是一种更加“正面”地描述。它说:“在name不含有’bad’这个词的时候,把它加到goodNames的链表里面……”

    情况2:for和while头部都有一个循环的“终止条件”,那本来应该是这个循环唯一的退出条件。如果你在循环中间有break,它其实给这个循环增加了一个退出条件。你往往只需要把这个条件合并到循环头部,就可以去掉break。

    比如下面这段代码:

    while (condition1) {
      ...
      if (condition2) {
        break;
      }
    }
    

    当condition成立的时候,break会退出循环。其实你只需要把condition2反转之后,放到while头部的终止条件,就可以去掉这种break语句。改写后的代码如下:

    while (condition1 && !condition2) {
      ...
    }
    

    这种情况表面上貌似只适用于break出现在循环开头或者末尾的时候,然而其实大部分时候,break都可以通过某种方式,移动到循环的开头或者末尾。具体的例子我暂时没有,等出现的时候再加进来。

    情况3:很多break退出循环之后,其实接下来就是一个return。这种break往往可以直接换成return。比如下面这个例子:

    public boolean hasBadName(List<String> names) {
        boolean result = false;
    
        for (String name: names) {
            if (name.contains("bad")) {
                result = true;
                break;
            }
        }
        return result;
    }
    

    这个函数检查names链表里是否存在一个名字,包含“bad”这个词。它的循环里包含一个break语句。这个函数可以被改写成:

    public boolean hasBadName(List<String> names) {
        for (String name: names) {
            if (name.contains("bad")) {
                return true;
            }
        }
        return false;
    }
    

    改进后的代码,在name里面含有“bad”的时候,直接用return true返回,而不是对result变量赋值,break出去,最后才返回。如果循环结束了还没有return,那就返回false,表示没有找到这样的名字。使用return来代替break,这样break语句和result这个变量,都一并被消除掉了。

    我曾经见过很多其他使用continue和break的例子,几乎无一例外的可以被消除掉,变换后的代码变得清晰很多。我的经验是,99%的break和continue,都可以通过替换成return语句,或者翻转if条件的方式来消除掉。剩下的1%含有复杂的逻辑,但也可以通过提取一个帮助函数来消除掉。修改之后的代码变得容易理解,容易确保正确。

写直观的代码

我写代码有一条重要的原则:如果有更加直接,更加清晰的写法,就选择它,即使它看起来更长,更笨,也一样选择它。比如,Unix命令行有一种“巧妙”的写法是这样:

command1 && command2 && command3

由于Shell语言的逻辑操作a && b具有“短路”的特性,如果a等于false,那么b就没必要执行了。这就是为什么当command1成功,才会执行command2,当command2成功,才会执行command3。同样,

command1 || command2 || command3

操作符||也有类似的特性。上面这个命令行,如果command1成功,那么command2和command3都不会被执行。如果command1失败,command2成功,那么command3就不会被执行。

这比起用if语句来判断失败,似乎更加巧妙和简洁,所以有人就借鉴了这种方式,在程序的代码里也使用这种方式。比如他们可能会写这样的代码:

if (action1() || action2() && action3()) {
  ...
}

你看得出来这代码是想干什么吗?action2和action3什么条件下执行,什么条件下不执行?也许稍微想一下,你知道它在干什么:“如果action1失败了,执行action2,如果action2成功了,执行action3”。然而那种语义,并不是直接的“映射”在这代码上面的。比如“失败”这个词,对应了代码里的哪一个字呢?你找不出来,因为它包含在了||的语义里面,你需要知道||的短路特性,以及逻辑或的语义才能知道这里面在说“如果action1失败……”。每一次看到这行代码,你都需要思考一下,这样积累起来的负荷,就会让人很累。

其实,这种写法是滥用了逻辑操作&&||的短路特性。这两个操作符可能不执行右边的表达式,原因是为了机器的执行效率,而不是为了给人提供这种“巧妙”的用法。这两个操作符的本意,只是作为逻辑操作,它们并不是拿来给你代替if语句的。也就是说,它们只是碰巧可以达到某些if语句的效果,但你不应该因此就用它来代替if语句。如果你这样做了,就会让代码晦涩难懂。

上面的代码写成笨一点的办法,就会清晰很多:

if (!action1()) {
  if (action2()) {
    action3();
  }
}

这里我很明显的看出这代码在说什么,想都不用想:如果action1()失败了,那么执行action2(),如果action2()成功了,执行action3()。你发现这里面的一一对应关系吗?if=如果,!=失败,…… 你不需要利用逻辑学知识,就知道它在说什么。

写无懈可击的代码

在之前一节里,我提到了自己写的代码里面很少出现只有一个分支的if语句。我写出的if语句,大部分都有两个分支,所以我的代码很多看起来是这个样子:

if (...) {
  if (...) {
    ...
    return false;
  } else {
    return true;
  }
} else if (...) {
  ...
  return false;
} else {
  return true;
}

使用这种方式,其实是为了无懈可击的处理所有可能出现的情况,避免漏掉corner case。每个if语句都有两个分支的理由是:如果if的条件成立,你做某件事情;但是如果if的条件不成立,你应该知道要做什么另外的事情。不管你的if有没有else,你终究是逃不掉,必须得思考这个问题的。

很多人写if语句喜欢省略else的分支,因为他们觉得有些else分支的代码重复了。比如我的代码里,两个else分支都是return true。为了避免重复,他们省略掉那两个else分支,只在最后使用一个return true。这样,缺了else分支的if语句,控制流自动“掉下去”,到达最后的return true。他们的代码看起来像这个样子:

if (...) {
  if (...) {
    ...
    return false;
  } 
} else if (...) {
  ...
  return false;
} 
return true;

这种写法看似更加简洁,避免了重复,然而却很容易出现疏忽和漏洞。嵌套的if语句省略了一些else,依靠语句的“控制流”来处理else的情况,是很难正确的分析和推理的。如果你的if条件里使用了&&||之类的逻辑运算,就更难看出是否涵盖了所有的情况。

由于疏忽而漏掉的分支,全都会自动“掉下去”,最后返回意想不到的结果。即使你看一遍之后确信是正确的,每次读这段代码,你都不能确信它照顾了所有的情况,又得重新推理一遍。这简洁的写法,带来的是反复的,沉重的头脑开销。这就是所谓“面条代码”,因为程序的逻辑分支,不是像一棵枝叶分明的树,而是像面条一样绕来绕去。

另外一种省略else分支的情况是这样:

String s = "";
if (x < 5) {
  s = "ok";
}

写这段代码的人,脑子里喜欢使用一种“缺省值”的做法。s缺省为null,如果x<5,那么把它改变(mutate)成“ok”。这种写法的缺点是,当x<5不成立的时候,你需要往上面看,才能知道s的值是什么。这还是你运气好的时候,因为s就在上面不远。很多人写这种代码的时候,s的初始值离判断语句有一定的距离,中间还有可能插入一些其它的逻辑和赋值操作。这样的代码,把变量改来改去的,看得人眼花,就容易出错。

现在比较一下我的写法:

String s;
if (x < 5) {
  s = "ok";
} else {
  s = "";
}

这种写法貌似多打了一两个字,然而它却更加清晰。这是因为我们明确的指出了x<5不成立的时候,s的值是什么。它就摆在那里,它是""(空字符串)。注意,虽然我也使用了赋值操作,然而我并没有“改变”s的值。s一开始的时候没有值,被赋值之后就再也没有变过。我的这种写法,通常被叫做更加“函数式”,因为我只赋值一次。

如果我漏写了else分支,Java编译器是不会放过我的。它会抱怨:“在某个分支,s没有被初始化。”这就强迫我清清楚楚的设定各种条件下s的值,不漏掉任何一种情况。

当然,由于这个情况比较简单,你还可以把它写成这样:

String s = x < 5 ? "ok" : "";

对于更加复杂的情况,我建议还是写成if语句为好。

正确处理错误

使用有两个分支的if语句,只是我的代码可以达到无懈可击的其中一个原因。这样写if语句的思路,其实包含了使代码可靠的一种通用思想:穷举所有的情况,不漏掉任何一个。

程序的绝大部分功能,是进行信息处理。从一堆纷繁复杂,模棱两可的信息中,排除掉绝大部分“干扰信息”,找到自己需要的那一个。正确地对所有的“可能性”进行推理,就是写出无懈可击代码的核心思想。这一节我来讲一讲,如何把这种思想用在错误处理上。

错误处理是一个古老的问题,可是经过了几十年,还是很多人没搞明白。Unix的系统API手册,一般都会告诉你可能出现的返回值和错误信息。比如,Linux的read系统调用手册里面有如下内容:

RETURN VALUE 
On success, the number of bytes read is returned... 

On error, -1 is returned, and errno is set appropriately.

ERRORS EAGAIN, EBADF, EFAULT, EINTR, EINVAL, …

很多初学者,都会忘记检查read的返回值是否为-1,觉得每次调用read都得检查返回值真繁琐,不检查貌似也相安无事。这种想法其实是很危险的。如果函数的返回值告诉你,要么返回一个正数,表示读到的数据长度,要么返回-1,那么你就必须要对这个-1作出相应的,有意义的处理。千万不要以为你可以忽视这个特殊的返回值,因为它是一种“可能性”。代码漏掉任何一种可能出现的情况,都可能产生意想不到的灾难性结果。

对于Java来说,这相对方便一些。Java的函数如果出现问题,一般通过异常(exception)来表示。你可以把异常加上函数本来的返回值,看成是一个“union类型”。比如:

String foo() throws MyException {
  ...
}

这里MyException是一个错误返回。你可以认为这个函数返回一个union类型:{String, MyException}。任何调用foo的代码,必须对MyException作出合理的处理,才有可能确保程序的正确运行。Union类型是一种相当先进的类型,目前只有极少数语言(比如Typed Racket)具有这种类型,我在这里提到它,只是为了方便解释概念。掌握了概念之后,你其实可以在头脑里实现一个union类型系统,这样使用普通的语言也能写出可靠的代码。

由于Java的类型系统强制要求函数在类型里面声明可能出现的异常,而且强制调用者处理可能出现的异常,所以基本上不可能出现由于疏忽而漏掉的情况。但有些Java程序员有一种恶习,使得这种安全机制几乎完全失效。每当编译器报错,说“你没有catch这个foo函数可能出现的异常”时,有些人想都不想,直接把代码改成这样:

try {
  foo();
} catch (Exception e) {}

或者最多在里面放个log,或者干脆把自己的函数类型上加上throws Exception,这样编译器就不再抱怨。这些做法貌似很省事,然而都是错误的,你终究会为此付出代价。

如果你把异常catch了,忽略掉,那么你就不知道foo其实失败了。这就像开车时看到路口写着“前方施工,道路关闭”,还继续往前开。这当然迟早会出问题,因为你根本不知道自己在干什么。

catch异常的时候,你不应该使用Exception这么宽泛的类型。你应该正好catch可能发生的那种异常A。使用宽泛的异常类型有很大的问题,因为它会不经意的catch住另外的异常(比如B)。你的代码逻辑是基于判断A是否出现,可你却catch所有的异常(Exception类),所以当其它的异常B出现的时候,你的代码就会出现莫名其妙的问题,因为你以为A出现了,而其实它没有。这种bug,有时候甚至使用debugger都难以发现。

如果你在自己函数的类型加上throws Exception,那么你就不可避免的需要在调用它的地方处理这个异常,如果调用它的函数也写着throws Exception,这毛病就传得更远。我的经验是,尽量在异常出现的当时就作出处理。否则如果你把它返回给你的调用者,它也许根本不知道该怎么办了。

另外,try { … } catch里面,应该包含尽量少的代码。比如,如果foobar都可能产生异常A,你的代码应该尽可能写成:

try {
  foo();
} catch (A e) {...}

try {
  bar();
} catch (A e) {...}

而不是

try {
  foo();
  bar();
} catch (A e) {...}

第一种写法能明确的分辨是哪一个函数出了问题,而第二种写法全都混在一起。明确的分辨是哪一个函数出了问题,有很多的好处。比如,如果你的catch代码里面包含log,它可以提供给你更加精确的错误信息,这样会大大地加速你的调试过程。

正确处理null指针

穷举的思想是如此的有用,依据这个原理,我们可以推出一些基本原则,它们可以让你无懈可击的处理null指针。

首先你应该知道,许多语言(C,C++,Java,C#,……)的类型系统对于null的处理,其实是完全错误的。这个错误源自于Tony Hoare最早的设计,Hoare把这个错误称为自己的“billion dollar mistake”,因为由于它所产生的财产和人力损失,远远超过十亿美元。

这些语言的类型系统允许null出现在任何对象(指针)类型可以出现的地方,然而null其实根本不是一个合法的对象。它不是一个String,不是一个Integer,也不是一个自定义的类。null的类型本来应该是NULL,也就是null自己。根据这个基本观点,我们推导出以下原则:

  • 尽量不要产生null指针。尽量不要用null来初始化变量,函数尽量不要返回null。如果你的函数要返回“没有”,“出错了”之类的结果,尽量使用Java的异常机制。虽然写法上有点别扭,然而Java的异常,和函数的返回值合并在一起,基本上可以当成union类型来用。比如,如果你有一个函数find,可以帮你找到一个String,也有可能什么也找不到,你可以这样写:
    public String find() throws NotFoundException {
      if (...) {
        return ...;
      } else {
        throw new NotFoundException();
      }
    }
    

    Java的类型系统会强制你catch这个NotFoundException,所以你不可能像漏掉检查null一样,漏掉这种情况。Java的异常也是一个比较容易滥用的东西,不过我已经在上一节告诉你如何正确的使用异常。

    Java的try…catch语法相当的繁琐和蹩脚,所以如果你足够小心的话,像find这类函数,也可以返回null来表示“没找到”。这样稍微好看一些,因为你调用的时候不必用try…catch。很多人写的函数,返回null来表示“出错了”,这其实是对null的误用。“出错了”和“没有”,其实完全是两码事。“没有”是一种很常见,正常的情况,比如查哈希表没找到,很正常。“出错了”则表示罕见的情况,本来正常情况下都应该存在有意义的值,偶然出了问题。如果你的函数要表示“出错了”,应该使用异常,而不是null。

  • 不要把null放进“容器数据结构”里面。所谓容器(collection),是指一些对象以某种方式集合在一起,所以null不应该被放进Array,List,Set等结构,不应该出现在Map的key或者value里面。把null放进容器里面,是一些莫名其妙错误的来源。因为对象在容器里的位置一般是动态决定的,所以一旦null从某个入口跑进去了,你就很难再搞明白它去了哪里,你就得被迫在所有从这个容器里取值的位置检查null。你也很难知道到底是谁把它放进去的,代码多了就导致调试极其困难。解决方案是:如果你真要表示“没有”,那你就干脆不要把它放进去(Array,List,Set没有元素,Map根本没那个entry),或者你可以指定一个特殊的,真正合法的对象,用来表示“没有”。需要指出的是,类对象并不属于容器。所以null在必要的时候,可以作为对象成员的值,表示它不存在。比如:
    class A {
      String name = null;
      ...
    }
    

    之所以可以这样,是因为null只可能在A对象的name成员里出现,你不用怀疑其它的成员因此成为null。所以你每次访问name成员时,检查它是否是null就可以了,不需要对其他成员也做同样的检查。

  • 函数调用者:明确理解null所表示的意义,尽早检查和处理null返回值,减少它的传播。null很讨厌的一个地方,在于它在不同的地方可能表示不同的意义。有时候它表示“没有”,“没找到”。有时候它表示“出错了”,“失败了”。有时候它甚至可以表示“成功了”,…… 这其中有很多误用之处,不过无论如何,你必须理解每一个null的意义,不能给混淆起来。如果你调用的函数有可能返回null,那么你应该在第一时间对null做出“有意义”的处理。比如,上述的函数find,返回null表示“没找到”,那么调用find的代码就应该在它返回的第一时间,检查返回值是否是null,并且对“没找到”这种情况,作出有意义的处理。“有意义”是什么意思呢?我的意思是,使用这函数的人,应该明确的知道在拿到null的情况下该怎么做,承担起责任来。他不应该只是“向上级汇报”,把责任踢给自己的调用者。如果你违反了这一点,就有可能采用一种不负责任,危险的写法:
    public String foo() {
      String found = find();
      if (found == null) {
        return null;
      }
    }
    

    当看到find()返回了null,foo自己也返回null。这样null就从一个地方,游走到了另一个地方,而且它表示另外一个意思。如果你不假思索就写出这样的代码,最后的结果就是代码里面随时随地都可能出现null。到后来为了保护自己,你的每个函数都会写成这样:

    public void foo(A a, B b, C c) {
      if (a == null) { ... }
      if (b == null) { ... }
      if (c == null) { ... }
      ...
    }
    
  • 函数作者:明确声明不接受null参数,当参数是null时立即崩溃。不要试图对null进行“容错”,不要让程序继续往下执行。如果调用者使用了null作为参数,那么调用者(而不是函数作者)应该对程序的崩溃负全责。上面的例子之所以成为问题,就在于人们对于null的“容忍态度”。上面这种“保护式”的写法,试图“容错”,试图“优雅的处理null”,其结果是让调用者更加肆无忌惮的传递null给你的函数。到后来,你的代码里出现一堆堆nonsense的情况,null可以在任何地方出现,都不知道到底是哪里产生出来的。谁也不知道出现了null是什么意思,该做什么,所有人都把null踢给其他人。最后这null像瘟疫一样蔓延开来,到处都是,成为一场噩梦。正确的做法,其实是强硬的态度。你要告诉函数的使用者,我的参数全都不能是null,如果你给我null,程序崩溃了该你自己负责。至于调用者代码里有null怎么办,他自己该知道怎么处理(参考以上几条),不应该由函数作者来操心。
  • 使用@NotNull和@Nullable标记。IntelliJ提供了@NotNull和@Nullable两种标记,加在类型前面,这样可以比较可靠地防止null指针的出现。IntelliJ本身会对含有这种标记的代码进行静态分析,指出运行时可能出现NullPointerException的地方。在运行时,会在null指针不该出现的地方产生IllegalArgumentException,即使那个null指针你从来没有deference。这样你可以在尽量早期发现并且防止null指针的出现。
  • 使用Optional类型。Java 8和Swift之类的语言,提供了一种叫Optional的类型。正确的使用这种类型,可以在很大程度上避免null的问题。null指针的问题之所以存在,是因为你可以在没有“检查”null的情况下,“访问”对象的成员。Optional类型的设计原理,就是把“检查”和“访问”这两个操作合二为一,成为一个“原子操作”。这样你没法只访问,而不进行检查。这种做法其实是ML,Haskell等语言里的模式匹配(pattern matching)的一个特例。模式匹配使得类型判断和访问成员这两种操作合二为一,所以你没法犯错。比如,在Swift里面,你可以这样写:
    let found = find()
    if let content = found {
      print("found: " + content)
    }
    

    你从find()函数得到一个Optional类型的值found。假设它的类型是String?,那个问号表示它可能包含一个String,也可能是nil。然后你就可以用一种特殊的if语句,同时进行null检查和访问其中的内容。这个if语句跟普通的if语句不一样,它的条件不是一个Bool,而是一个变量绑定let content = found

    我不是很喜欢这语法,不过这整个语句的含义是:如果found是nil,那么整个if语句被略过。如果它不是nil,那么变量content被绑定到found里面的值(unwrap操作),然后执行print("found: " + content)。由于这种写法把检查和访问合并在了一起,你没法只进行访问而不检查。

    Java 8的做法比较蹩脚一些。如果你得到一个Optional类型的值found,你必须使用“函数式编程”的方式,来写这之后的代码:

    Optional<String> found = find();
    found.ifPresent(content -> System.out.println("found: " + content));
    

    这段Java代码跟上面的Swift代码等价,它包含一个“判断”和一个“取值”操作。ifPresent先判断found是否有值(相当于判断是不是null)。如果有,那么将其内容“绑定”到lambda表达式的content参数(unwrap操作),然后执行lambda里面的内容,否则如果found没有内容,那么ifPresent里面的lambda不执行。

    Java的这种设计有个问题。判断null之后分支里的内容,全都得写在lambda里面。在函数式编程里,这个lambda叫做continuation,它表示“如果found不是null,拿到它的值,然后应该做什么”。由于lambda是个函数,你不能在里面写return语句返回出外层的函数。比如,如果你要改写下面这个函数(含有null):

    public static String foo() {
      String found = find();
      if (found != null) {
        return found;
      } else {
        return "";
      }
    }
    

    就会比较麻烦。因为如果你写成这样:

    public static String foo() {
      Optional<String> found = find();
      found.ifPresent(content -> {
        return content;    // can't return from foo here
      });
      return "";
    }
    

    里面的return a,并不能从函数foo返回出去。它只会从lambda返回,而且由于那个lambda的返回类型必须是void,编译器会报错,说你返回了String。由于Java里closure的自由变量是只读的,你没法对lambda外面的变量进行赋值,所以你不能采用这种写法:

    public static String foo() {
      Optional<String> found = find();
      String result = "";
      found.ifPresent(content -> {
        result = content;    // can't assign to result
      });
      return result;
    }
    

    所以,虽然你在lambda里面得到了found的内容,然而如何使用这个值,却让人摸不着头脑。实际上,判断null之后,你必须使用Java 8提供的一系列古怪的操作map, flatMap, orElse之类,想法把它们组合起来,才能表达出原来代码的意思。比如之前的代码,只能改写成这样:

    public static String foo() {
      Optional<String> found = find();
      return found.orElse("");
    }
    

    这简单的情况还好。复杂一点的代码,我还真不知道怎么表达。这些东西的工作原理,可以扯到functor,continuation,甚至monad…… 仿佛用了Optional之后,这语言就不再是Java了一样。所以Java虽然提供了Optional,但我觉得可用性其实比较低,难以被人接受。相比之下,Swift的设计更加简单直观,接近普通的过程式编程。你只需要记住一个特殊的语法if let content = found {...},里面的代码写法,跟普通的过程式语言没有任何差别。

    总之你只要记住,使用Optional类型,要点在于“原子操作”,使得null检查与取值合二为一。这要求你必须使用我刚才介绍的特殊写法。如果你违反了这一原则,把检查和取值分成两步做,还是有可能犯错误。比如在Java 8里面,你可以使用found.get()这样的方式直接访问found里面的内容。在Swift里你也可以使用found!来直接访问而不进行检查。

    你可以写这样的Java代码来使用Optional类型:

    Option<String> found = find();
    if (found.isPresent()) {
      System.out.println("found: " + found.get());
    }
    

    如果你使用这种方式,把检查和取值分成两步做,就可能会出现运行时错误。if (found.isPresent())本质上跟普通的null检查,其实没什么两样。如果你忘记判断found.isPresent(),直接进行found.get(),就会出现NoSuchElementException。这跟NullPointerException本质上是一回事。所以这种写法,比起普通的null的用法,其实换汤不换药。如果你要用Optional类型而得到它的益处,请务必遵循我之前介绍的“原子操作”写法。

防止过度工程

人的脑子真是奇妙的东西。虽然大家都知道过度工程(over-engineering)不好,在实际的工程中却经常不由自主的出现过度工程。我自己也犯过好多次这种错误,所以觉得有必要分析一下,过度工程出现的信号和兆头,这样可以在初期的时候就及时发现并且避免。

过度工程即将出现的一个重要信号,就是当你过度的思考“将来”,考虑一些还没有发生的事情,还没有出现的需求。比如,“如果我们将来有了上百万行代码,有了几千号人,这样的工具就支持不了了”,“将来我可能需要这个功能,所以我现在就把代码写来放在那里”,“将来很多人要扩充这片代码,所以现在我们就让它变得可重用”……

这就是为什么很多软件项目如此复杂。实际上没做多少事情,却为了所谓的“将来”,加入了很多不必要的复杂性。眼前的问题还没解决呢,就被“将来”给拖垮了。人们都不喜欢目光短浅的人,然而在现实的工程中,有时候你就是得看近一点,把手头的问题先搞定了,再谈以后扩展的问题。

另外一种过度工程的来源,是过度的关心“代码重用”。很多人“可用”的代码还没写出来呢,就在关心“重用”。为了让代码可以重用,最后被自己搞出来的各种框架捆住手脚,最后连可用的代码就没写好。如果可用的代码都写不好,又何谈重用呢?很多一开头就考虑太多重用的工程,到后来被人完全抛弃,没人用了,因为别人发现这些代码太难懂了,自己从头开始写一个,反而省好多事。

过度地关心“测试”,也会引起过度工程。有些人为了测试,把本来很简单的代码改成“方便测试”的形式,结果引入很多复杂性,以至于本来一下就能写对的代码,最后复杂不堪,出现很多bug。

世界上有两种“没有bug”的代码。一种是“没有明显的bug的代码”,另一种是“明显没有bug的代码”。第一种情况,由于代码复杂不堪,加上很多测试,各种coverage,貌似测试都通过了,所以就认为代码是正确的。第二种情况,由于代码简单直接,就算没写很多测试,你一眼看去就知道它不可能有bug。你喜欢哪一种“没有bug”的代码呢?

根据这些,我总结出来的防止过度工程的原则如下:

  1. 先把眼前的问题解决掉,解决好,再考虑将来的扩展问题。
  2. 先写出可用的代码,反复推敲,再考虑是否需要重用的问题。
  3. 先写出可用,简单,明显没有bug的代码,再考虑测试的问题。

非编程天才参与开源项目的14种方式「轉」

如果你想参与到开源项目中去,却又不知道从何入手,这里提供一些参考方法或许能给你提供一些帮助,哪怕你对你目前的技术还缺乏自信都不要紧。

开源软件已经改变了IT,甚至整个世界,正是因为有了你们,乐于奉献在开源事业中。不幸的是,很多人把参与到开源项目中想象成一个难以跨越的障碍一样,因此而退缩。我通常听到人们说他们很想参与到开源项目中来,但是因为以下的3个原因而打消了念头。

1. 我还不足够优秀

2. 我没有足够的是时间

3. 我不知道什么样的项目适合我

 

寻求机会参与到开源项目中去,你应该知道的三个基本原则:

1. 项目需要各种能力层次的专业人才。

2. 哪怕是微不足道的贡献也比没有好。

3. 从你正在使用的项目作为参与到开源的第一步

 

我从开源项目中所观察到最要命的想法是那些新人总认为要成为某种类型的天才程序员才能参与到开源中去,其实根本就不是这回事。当然,某些项目中的成 员看起来就像摇滚明星,没错,他们确确实实是一个极具天赋的程序员,然而,我们中的绝大部分不是的。我们仅仅是那些只要把任务完成的人。有时我们做的付出 的不需太多,有时我们需要花大把的时间,有时它就是编程,而有时它不是。

0. 加入邮件列表:对于大多数项目,邮件列表仍然是项目开发沟通主要的渠道。在一个规模比较大的项目中通常有很多邮件列表可以选择,例如:PostgreSQL项目就有不少于12个面向用户的邮件列表和6个面向开发者的。我建议你关注最主要的几个面向用户邮件列表以及核心的开发者列表。

1. 关注博客:博客一般由核心开发者维护,通常博客中包含项在未来版本的一些信息。如何获取这些信息呢?通常一个星级站点有包括来自很多相关项目的新闻或者博客词条,如果有一个星级站点,如:http://planet.gnome.org 或者 http://planet.mysql.com ,那么你要做的仅仅是用Google搜索”planet <项目名>”。

2. 加入到IRC频道:许多开源项目都有专门的互联网中继聊天(IRC)频道,用来为开发者和用户讨论开发问题。仔细查找项目站点中IRC频道叫什么。

3. 代码诊断:Bug通常很难报告出来,诊断快速处置bug有助于节省开发人员的时间。如果用户提出报告:“当我操作XX功能时,系统无法工作”,你得花些时间解决这些问题。还是不是会重复出现?例如该类问题是否只是发生在某种浏览器不兼容?只在发行版有这样的问题还是其它的原因。

4. 关闭已修复的bug:  通常bug在代码库中修复了,但是在问题追踪系统中还没更新。清理掉这些杂乱的东西虽然耗时,但是对整个项目来说是值得的。

5. 测试beta版或者候选版本:任何项目设计用于运行在多个平台时就有可能存在各种兼容性问题。当一个beta版或者候选版发布时,项目带头人希望能在不同的人和不同的平台上得到测试反馈结果,你就可以是其中之一。

6. 修复bug:修复bug通常是贡献者开始接触代码的地方,非常简单,在问题追踪系统中找到感兴趣的bug,把bug修复,如果合适的话为代码的修复撰写文档。

7. 写测试:绝大多数项目都有测试套件用来测试代码,很难想象测试套件中不能附加更多的测试在其上。使用测试覆盖工具诸如基于c的gcov、基于Perl的Devel::Cover,用来标识源代码没法通过测试套件测试到的范围,然后添加一个套件覆盖它。

8. 理性对待编译警告:许多基于C项目的构建过程中经常会出现很多古怪的编译警告,这些警告通常不是错误,但是看起来像,太多的警告让编译器听起来就像在发假警报,仔细检查代码是否的确隐藏有bug。

9. 附上注释:当你在深入研究代码时,你可能发现有疑惑的地方,如果感到疑惑,这对你来是一个机会,比别人也可能碰到同样的问题,给他们贴上注释提交补丁。

10. 创建例子:一般项目都没有太多入门的例子,不管是web API、普通程序库、或者是GUI应用如Gimp、还是命令行工具,比起长篇的文档,一个恰当的例子能够更清晰更快速解释软件的使用方式。

11. 问题回答参与到社区最好的方式是帮助别人。回答问题,尤其是那些初次涉及的,这对于一个项目的成长很关键,即使你回答只是简单地”RTFM”(read the fxxk manual),每个人都要行动起来,项目如果要变得强大起来的话每个人需要动员起来。

12. 写博客:如果你有博客,写下你使用项目的一些经验,记录你碰到的问题及解决的方法。你可以通过两种方式来提供帮助,一个是记住你身边帮助过你的人,另一个是记录下你将来可能会碰到的问题。

13. 改进网站:很多程序员在图形设计方面显得非常糟糕,尤其是那些不能从设计部门得到帮助的项目网站。如果 你有网页设计方面的技能,不妨改进下网站,网站作为项目的招牌,是值得花时间的。或许项目界面需要彻底改造,抑或仅仅是一个logo,这些是社区缺乏的技 能,如果我能提供一些图形设计上的帮助,我会非常喜欢的。

有太多的方式参与到开源项目中,哪怕是我们写一个新产品的特性的历史回顾。每个使用开源项目的人都可以把技术带到社区和帮助开源成为IT产业中重要的一部分。

 

本文由 伯乐在线刘志军 翻译。未经许可,禁止转载!
英文出处:Andy Lester。欢迎加入翻译组

程序员在周末学习的8个实用技术「轉」

 

无论你是刚开始接触软件项目开发的新手程序员,还是一个正在寻找拓展技能的经验级软件工程师,都有许多学不完的新技术等待着你去拓展。当然如果你可以在周末学习下面这些实用技术,那就更棒了。学会一下8个技术或许会让你以后有更多的周末休息时间。

熟练掌握版本控制

如果你从来没有使用版本控制的经历,那么也许你现在会处于一种很艰难的境地:无法将代码恢复到上一个版本,或许你只能将你的代码以文件命名的方式进行备份,比如index_17.html,这是多么痛苦的一件事情。

版本控制意味着你可以将你的代码恢复到任意的版本——甚至精确到小时或者分钟。如果你使用过Google Drive,也许会对恢复到上一个版本的功能比较熟悉,对,这就是简单的版本控制原理。

灵活运用文本编辑器

程序员每天都会将大量的时间花在各种文本编辑器上面,你应该根据自身习惯和开发环境的需要,选择一款可以提高工作效率的文本编辑器,并且不断地深入学习它的使用方法。

如果你更喜欢在终端上工作,那么这里推荐使用VIM和Emacs;如果你喜欢使用本地文本编辑器,那么可以尝试一下Sublime Text;如果你喜欢在Mac环境中工作,也可以试试TextMate。

仅仅在文本编辑器上工作是不够的——你应该尝试安装一些插件和扩展,让自己的工作可以更加舒心。

强大的SQL

一个应用软件必须使用文件或者数据库来存储用户的数据,正因为数据库查询快速,并且提供更优的查询结果,我们的应用便更亲睐于数据库。

SQL是一种数据库查询语言,但是仅仅是学习基础的SQL对我们构建大型复杂的应用系统是远远不够的,很多时候我们需要进行多表,甚至是多库的联合查询。

所以,我建议程序员在周末的时候可以加强SQL方面的练习。

神秘的NoSQL

NoSQL或者也叫Not Only SQL,它有着和传统的关系数据库不同的数据存储格式,NoSQL数据库更加关注数据库的可用性和水平扩展能力,它也有类似SQL的数据库查询语言。

NoSQL根据不同的数据组织结构有几种不同的类型,尽管像Quora这样的大公司并不使用NoSQL,但是如果你有非常庞大的数据需要处理,那么NoSQL是一种非常棒的选择。

爱上终端

对于一些特定的工作任务来说,使用终端会比使用可视化界面来的方便。举个例子,你需要从成千上万个字符串中查找并替换相应的字符串——想象一下这需要在几秒内完成。

如果你在远程服务器上工作,那么你更加需要擅长使用终端。尽管你可以在远程服务器上使用可视化界面来进行操作,但是使用终端会更快一些。还有更重要的一点原因是——使用终端将更加节省带宽,因为这样仅仅需要传输一些文本信息而已。

对于终端初学者来说,周末有空了可以从简单的文本拷贝开始学习,过一段时间,你会发现自己会爱上终端了。

控制远程服务器

作为一名程序员,你肯定不会将代码局限在本地的,如果开发了一款应用,你肯定会将它展示给全世界的人看。这样你就需要登录远程服务器,并且设置相关信息,以便自己的应用可以在服务器上正确运行。

学会单元测试

另外一个重要的技能就是单元测试,当你在开发一个庞大的项目时,是不可能写完所有的代码后才去测试应用的正确性的。我们最好将代码分割成几个部分,然后对每一个部分进行单元测试。

具体的单元测试方法根据不同编程语言有所区别,但是核心理念是一致的——写一部分代码,测试一部分代码。

学会使用Markdown

我将Markdown放到最后是因为它对你写代码并没有多大关系,但是这对那些习惯在网络上发布信息的同学来说就非常重要。比如说编写README文件,并将其添加到Github项目中。

Markdown是一个将文本转换成HTML的工具,它有自己的语法和标签,这些语法标签经过转换后成为标准的HTML结构,这对有些Web开发者来说有一定的实用价值。

各位程序员,这个周末你准备好了吗?

 

译文链接:http://www.codeceo.com/article/8-tech-programmer-learn-weekend.html
英文原文:8 Essential Skills Developers Can Learn in a Weekend
翻译作者:码农网 – 小峰

怎样花两年时间去面试一个人「轉」

原文鏈接:http://mindhacks.cn/2011/11/04/how-to-interview-a-person-for-two-years/

Joel Spolsky曾经感叹:招聘难,难于上青天(此处笔者稍加演绎:))。他有两个辛辣但不乏洞察力的断言:真正的牛人也许一辈子就投大概4次简历,这些家伙一毕业就被好公司抢走了,并且他们的雇主会给他们不赖的待遇,所以他们也不想挪窝。(刚刚去世的Dennis Ritchie就是这样一个人)而“人才”市场上能找到的大多都不是什么人才。招到这帮人轻则费钱重则把你公司搞挂。

(当我把这篇文章给邹欣老师review的时候,他说了另外两 点:1. 最好的人也许不投简历,就决定去哪里了。所以要在他们做决定前找到他们。2. 比较差的会投很多次简历,找不到工作的时间越多,投的简历越多,给整个pool 带来很多噪音,top10%的简历也许根本不算全部人的top10%。)

诚然,也许没有哪个行业像IT行业这样,无形资产占据公司的绝大多数资产。拒坊间传言比尔·盖茨就曾经说过类似这样的话:只要允许我带走100个人我可以再造一个微软。这话没搜到原版出处,但是从一个侧面反映了IT公司当中智力资产所占的比例之重。

所以一个自然的推论就是,招聘也许是一个公司决策当中最最重要的一个环节。Joel Spolsky把他在这方面的观察,体会和洞见集结成了一本小册子《Smart and Gets Things Done》,开篇就挑战“产品是公司成败的关键”这个传统观念,他认为创造最适合工程师生活的环境,留下最优秀的人才才是最先最重要的一步,接下来好的产品是水到渠成的事情。国内iapp4me.com创始人郝培强正是这个理念,所以他在微博上说

我们是小公司,工资开的不高,也不招太多的人,但是电脑都是iMac27,iMac21,Macbook pro15,基本上比很多大公司都好多了。软件没盗版,刚才photoshop的正版我也收了。中午管饭,公司备伞。哈哈。节日假正常放,从不加班,早晨 11点上班,下午6点下班。我是有资格说某些大公司的员工苦逼的。

事实上,米国找个人尚且难成这样,搞得Joel还费心费力写本书语重心长地劝企业们要善待好工程师,国内找个人更是难上加难,国内高质量问答社区知乎创始人周源就曾经在知乎上分享他呕心沥血的招人历程,看完真是让人慨叹这年头找个靠谱的人多不容易(这条知乎问答还有很多精彩的跟帖):

其实从 08 年到现在,我一直想这事能不能有点窍门,或者是实用的方法,结论是几乎没有。我用过的大家都用的方法:

  • 在水木上发贴子(有点效果)
  • 在蓝色理想上发贴子(无效)
  • 在技术邮件组里发贴子(无效)
  • 买 51job/智联 最便宜的服务(有点效果)
  • 给所有可以想到的人打电话,请他们推荐(无效)
  • 给所有和你讨论过创业,喝过点小酒的人打电话(无效)
  • 约前同事私下谈(有效)

我用过的大家可能没有用的方法:

  • 上 twitter,看 XXX 的 follower,一个一个看,看他们的 twitter,博客,Google Reader 分享,想办法搞到邮件,联系,半夜电话骚扰。
  • 上豆瓣,前端后端挑几本重量级的书,去找想看,看过,正在看这本书的人,一个一个看,看他们的活动,博客,Google Reader 分享,想办法搞到邮件,联系,半夜电话骚扰。
  • 找同事,问他们都看什么技术博客,想办法搞到邮件,联系,半夜电话骚扰。

正是这样的不容易,才有不少公司走内部培养的办法,这里的逻辑是:一上来就招到靠谱的人太难了,但找一块靠谱的璞玉然后雕琢雕琢相对就简单很多。这倒是个办法,但这样做的人难免就陷入了纠结:培养好了,人跑了怎么办。这也不能怪招聘的公司,的确是人之常情。其实解决的办法也很简单,培养的时候进行适当引导,让员工发挥自己的主动学习能力,这样不但人得到更多成长,公司也不会觉得投入太多患得患失。所谓师傅领进门修行在个人。

但是,这仍然还是没有解决根本的问题,就是招聘真的很困难。应聘者固然觉得自己是在“海投”,大海捞针一般。而招聘者何尝不也是这种大海捞针的感觉。这就好比两个人谈恋爱,都想和对方好上,但是偏偏就聊不到一块去。

招聘真的很困难。以至于招聘者每年需要绞尽脑汁出新笔试题,以免往年的笔试题早就被人背熟了。出题很费脑子,要出的不太简单也不太难,能够滤掉绝大 多数滥竽充数的但又要保证不因题目不公平而滤掉真正有能力的,要考虑审题人的时间成本就只能大多数用选择题,而选择题又是可以猜答案的(极少有人会在选了 答案之后还敢在空白的地方写为什么选某答案的原因的)。更悲催的是,有些题目出的连公司的员工们自己都会做错(真的是员工们做错了吗?还是题目本身就出错 了?)

笔试完了之后如果还没有被鄙视就要进入面试环节,姑且不说笔试题的种种弊端,就说面试环节,短短几个小时的面试(大多数公司也许连几个小时的面试时间都没有),既需要全面考察基本知识,又要考察编程素养,还要考察(也许最重要的)性格心态。再然后还有一项根本没法考察但却占据程序员相当一部分工作时间的:debug能力。面试官不但得找准问题,不因对方一题答对而妄下结论,也不因一题打错而就扼杀机会,还要以管窥豹,从一朵花看到整个世界,从面试人的举止言谈,分析问题的方式,甚至写程序的笔迹来观察这个人的性格,做事的方式和心态,简直是要面试官具备心理分析师的水准才行。

这厢要招人的雇主苦不堪言,那边找工作的人也是一团乱麻。绝大多数应届生直到毕业也不清楚他们想要去的公司到底需要什么样的能力,或者说,他们到底 需要具备什么样的能力才能在应聘季节拥有自己的选择权。中国虽然本科教育环境差,但是同样有很多的人在本科希望整点东西出来,他们有一腔的激情和抱负,有 强大的动力,但就是不知道自己需要掌握哪些技能才能满足雇主的要求,求告无门,整年整年苦闷的像没头苍蝇一样乱撞(我就收到过很多次这样的来信,他们往往 很想学点东西,但又不知道哪些重要哪些不重要,到底该学到什么程度,不知道导致不确定,不确定导致决策瘫痪,干脆嘛也不动,荒废时间)。

什么叫熟练?什么又叫精通?那么扎实呢?两年的YY经验又意味着什么?能这么简单的量化吗?同样是两年的“实践”有的人能真的学到点东西,有的人也 许近似一无所得。那么实习呢?很多人都一定要在简历上弄个实习经验,这个又能说明多少问题呢?大作业呢?得奖呢?有一次我面试一位同学,据简历说编译原理课的大作业得了一等奖,可我一问什么是递归下降,就傻眼了。

这个现实的结果就是,现在绝大多数应届简历而言,也许最具信息量的部分不是“精通XXX,熟悉YYY,掌握ZZZ”,不是“在UUU实习过”,也不是这个项目那个作业,反倒是越来越被认为不重要的一项:毕业学校毕业学校本不应该是最具信息量的,它之所以最具信息量只是源于一个悲剧的事实:简历上其他条目实在信息量太少了。 所以靠谱的面试者往往学会了无视简历上华而不实的内容,只相信面试的时候亲眼所见,扫两眼简历也就罢了,最后还得自己捋起袖子慢慢面。而应聘者也许也知道 招聘的也不会细细纠简历上的条目,所以什么词也都敢往上捅,反正先过了HR筛简历这关再说。从经济学角度来讲,应聘者的这种策略是正确的,没有代价(因为 目前似乎没有公司会去给已经申请过的人做一个诚信数据库),但至少有可能会带来巨大的收益。应聘成了博彩。而博彩式的应聘给招聘公司带来了巨大的筛选压 力。简历成了摆设。

那么招聘这个关系里面的第三者——学校——所处的位置呢?学校更关心的是毕业率和就业率,这似乎是件好事,有这个为目标,那么老师们似乎应该努力让 自己的学生多学点东西。可惜就业的质量似乎不是最重要的指标,此其一。其二老师本身大多数没有丰富的业界经验,根本不知道企业整整需要的人才是什么样的, 可能花了精力,但却培养不出雇主真正需要的人。另一方面,老师所起的作用很多时候甚至是一个负面的作用,例如布置大作业表面上看上去是培养学生的能力,我 们姑且不说抄袭,假设每个人都做了,那么大作业本身能够衡量多少东西呢?能否衡量代码质量,能否衡量团队协作能力?能否衡量交流能力?考虑到大作业用到的 东西往往都是书里面现成的,大作业甚至不能衡量学习能力。而学习能力简直算是这个行业最重要的能力没有之一了

所以,简而言之,如果把人才培养/招聘这件事情本身类比做一个项目,那么这整个项目迄今为止就是一个巨大的失败。为什么这么说呢:

  • 和需求严重脱节:作为人才需求方的雇主的需求到底是什么?绝大多数应聘者都没搞清。更严重的是,这却一点都不是应聘者的错。因为雇主是stakeholder,是雇主自己的责任得去说清楚需求是什么。结果应聘者实现的不是雇主想要的,雇主想要的应聘者没有实现。
  • 应聘者雇来培训自己的人根本不管事:学生交了学费,就相当于雇老师来培训自己,可培训者根本也不了解(或不关心)他的客户们的需求。这里,学生是需求方,老师则是实现方。弄清需求的职责在后者,可后者也弄不清。
  • 学生自己也弄不清:学生自己既是需求方(需要特定技能),也是实现方。可他们自己也弄不清需求到底是什么。

以上三点还不是最严重的,最严重的在下面:

  • 明白需求是什么的也不知道怎么实现:怎么去培养现代IT企业真正需要的人才?特别地,实战能力怎么培养?代码素养怎么培养?协作沟通能力怎么培 养?学习能力怎么培养?就算这些都知道怎么培养,又怎么给在象牙塔里头,离催命之日还遥遥无期的学生提供足够的动力呢?而学生自己就算知道该学哪些技能, 又怎么知道具体怎么着手?什么是最有效率的学习方法?又如何让自己保持学习的热情?

以上这些问题,就是当下人才培养/招聘的惨淡现状。简而言之,在雇主和学生之间,横梗着一条巨大的鸿沟,两头都很着急,两头都有动力,但就是没有方 法,君住长江头妾住长江尾。像微软谷歌这样的,干脆和高校合作,直接插手本科或硕士的教育,从而保证到时有足够强的候选,某种程度上,这的确是根本解决之 道,可一来这代价太大了,非一般企业承受得起,二来这影响面也太小了。

这一切,也许将在未来的5年发生根本的变化。

《Switch: How to Change Things When Change Is Hard》(中译《瞬变》)里面指出,表面上看来非常困难的改变,也许是因为根本就没有抓住要害。在书中作者通过大量案例分析和心理学研究,雄辩地指出以下几点促成改变的关键之处:

  • 触动内心的大象:要改变的人必须要有情感层面的动力。有一些特定的方法能够比另一些方法更能对人的情感产生触动。
  • 给出清晰、明确的目标:目标一定不能含糊,模棱两口的目标让人无所适从,导致决策瘫痪。 例如最近我们组在招实习生,我在微博上发了一条招聘信息,其中提到“扎实”的系统底层知识,有同学就写信来问,怎么叫“扎实”。我傻眼了。比尔·盖茨就以 目标清晰明确著称,不仅在战略制定上,“每个人桌面上都有一台PC”,而且居然还体现在招聘上——“如果你读完了TAOCP,那么就给我投简历吧”。多么 清晰,明确的目标啊——虽然高了点,也许这就是比尔·盖茨至今还没被应聘邮件淹没的原因:)
  • 给前进的道路扫清障碍:人是懒惰的,只要有借口就会不想往前。如果既有明确的目标,同时道路又直直指向目标,一览无余,只等你开始往前走,那么便没有借口,一往无前。

那么让我们对照上面看看,可以做什么?

首先,内心的大象不需要触动,中国有足够多的人足够早就开始焦虑就业的事情,只是不知道往哪使劲,这部分人如果把劲头用到正确的事情上面也许足以满足现在的IT企业人才饥渴了。至于其他人,好吧,也许身边的人开始动起来他们也会被触动。

然后是清晰、明确的目标。这一点上目前雇主们的做法可谓好坏参半,好的一点是大家都强调要有实践经验,要有团队协作精神,坏的一点就在基础知识和技 能的要求方面,可谓再含糊不过了:“精通XX语言”,“扎实的XX功底”,“熟悉XX技术”,甚至看上去最具量化感的描述“X年YY经验”其实都根本说明 不了多少东西,在信息量方面还不如我家门口菜市场上一家卖酥油饼的店门口挂的横幅——“三天不硬、至少六层!”。

很多朋友也许注意到一个现象,现在企业对招聘者简历的要求也在变得越来越灵活变通,例如ThoughtWorks在招聘的时候就希望招聘者能给出自己的博客地址,博客对IT行业的意义也许胜过其他所有行业,一个积累多年的技术博客比任何简历都更能说明问题。台湾的郭安定也说“为什么写技术博客对新人如此重要”。可惜这个做法也有一个弊端:并不是所有技术牛人都写博客,有人就是只干不说型的,而就算写博客,乃至动手写过一阵子的,写一个常年的博客,也远比你想象的更为困难,因为很多时候,写(说)得靠谱比做得靠谱更难。所以这个过滤器很多时候用不上。

但是这的确表明了一个思考的方向,就是寻找更具鉴别力的过滤器,Stackoverflow Careers 2.0之所以强大,是因为Joel Spolsky和Jeff Atwood这两位常年混社区的资深博主创造性地将一个人在社区的活动历史浓缩成为一系列的量化数值,由于这个历史很长期,所以鉴别力非常高。但它同样也有问题,就是对于应聘者来讲相当花费时间,而且并不是花时间(在Stackoverflow上回答问题)就一定能花到点子上。

到底什么特征才是既通用,又能够有效地鉴别高低应聘者的特征呢?这个特征必须不像博客那样难以实现,同时又必须有足够的区分度

有的地方在要求填写简历的时候必须填上平时都访问哪些技术网站。恩,很不错的尝试,可区分度仍然还是不够,因为上网站上查东西毕竟只占现阶段大多数应届生的少数信息来源,特别是当我们看重得更多的是应届应聘者的系统性的知识基础的时候,网上的东西虽然丰富,但属于提高班,也更为琐碎,什么是更系统的知识来源呢?答案其实大家都知道——

书。

我一向认为,很多时候,是否好好看完一本好书,对一个人的提升往往能达到质的区别。就算不好好看完一本好书,马马虎虎看完,只要书是真的好书,也肯定会有很大的提高。我在面试的时候就经常询问对方看过哪些技术书籍,经常上哪些网站,订哪些博客。这里头尤其数书籍这一项的区分度最高。此外,好书和坏书的差别,从本质上,就是学习效率和大方向的差别。一本烂书可以浪费你半年的时间,但一本好书却可以为你带来真正扎实的基础和开阔的视野。人们常常用“内功”来形容扎实的基础,认为学好了内功以后学什么都快,其实一点没错,好的“内功”书不仅讲清楚深刻的原理,而且指明技术的本质,刻画领域的地图。好的书抓住不变量,让人能够触类旁通。好的书不仅介绍知识,而且阐释原则,介绍那些万变不离其宗的东西。读烂书浪费时间,但读好书却节省时间

象牙塔内的学生受到视野的限制,往往择书不慎,事倍功半,烂书不仅浪费时间,还会打击人的积极性,让人对知识心生恐惧,认为很难掌握,殊不知只是作者没有讲好(或者没有翻译好)。因此,为招聘头疼的公司完全可以给出“应聘俺们公司前必读的十本书”,也不一定要每个公司都不一样,在某个技术子领域有影响力的人,或者创始人们,可以来定义具有代表性的书单。

我们姑且把这个计划叫做“书单计划”,容易看到“书单计划”具备以下几个卓越的优点:

  1. 清晰、明确。完全可度量。
  2. 防伪:读没读过,随便一问便知。而正因为应聘者也知道这事不像实习经验可以忽悠,所以也不敢乱往简历上捅词。
  3. 不在乎是否“泄题”:书单完全公开的,无所谓,本来就是要你去读的。想背题?背书吧。真能背下来说明认真看了。
  4. 管你用心不用心读,只要读了,读完了,就有区别。真正的好书,你想不被吸引都难。据我观察很多人就是不知道该去读什么书。
  5. 不存在“怎么做”的障碍:所有人都知道怎么读书——一页一页读。
  6. 不需要招聘者投入精力:书单在此,就这么简单,您看着办。
  7. 评估的负担很大程度转移到了应聘者的身上:是不是认真看完了,有没有心得体会,您自己掂量。没看完别来找我们。

“书单计划”能很大程度上起到强鉴别器的作用,看了就是看了,必然能学到东西,没看就是没看。知道和不知道,区别是本质的其实很多企业内部培训,根本上其实还不就是叫员工去看之前没看过的书或者资料嘛。最后,除了鉴别作用之外,它还是一个清晰促进的目标,是完全不花精力的培养

当然,“书单计划”的背后是另一个悲剧的现实,如果不是因为这个现实,这个计划也完全没有必要,那就是,中国IT大学教育当中要求要学的书,和企业真正需要你去读的书相比,不是完全不够用,就是写的不够好,或者更悲剧的就是根本用不上,所以在这个大背景下出来的牛人都是自己淘书自己学的。微软高级开发测试工程师,《Windows用户态程序高效排错》作者熊力就在微博上说过:“我当年毕业的时候总结了一个公式:第一份工作的月薪=大学四年买过的技术书籍价格的总和。”

但是光有“书单计划”还不够,因为书籍只能管基础知识这一块,一些更难以量化衡量的实战“能力”又怎么办呢?至 少目前为止,除了“练”之外好像还没有特别好的办法。可是在象牙塔里面做的项目,或大作业,真的能起到练的作用吗?前面说了,学生会知道自己最终要交差的 不是雇主,而是老师,于是就以老师能够评判的标准来默认要求自己了,老师能够评判编码素养?代码风格?文档?设计?协作?甚至连著名的Joel 12条的第一条“是否用源代码管理系统”都没法通过。所以大多数时候,大作业能起到的作用近乎0。

但是如果这一切是由雇主来评判的,这个“作业”是由雇主来给出的,就完全不一样了。一想到作业是要作为简历的一部分的,能不紧张嘛。能不好好做嘛。能不学到点东西嘛?

可是这事儿能实现吗?雇主能给学生出大作业吗?也许一两个关系好的高校可以,可是中国那么多学生呢?

为什么不能呢?如果像书单那样,列出各个技术领域“推荐在学校期间尝试的项目”,至于动不动手做,那是学生自己的问题。做的,自然能够得到锻炼,面试的时候自然能得到更大的优势。

可问题是,面试的人又怎么来评估呢?这不又回到了没法有效评估的怪圈了吗?答案很简单,但这个答案,直到最近几年,才真正成为现实——

GitHub

GitHub诞生于08年春天,第一年便产生了4万6千个公共项目,大约一年半之后用户就已经达到10万用户之巨。而到今年九月份,GitHub已经迎来了百万级用户。Host超过两百万个项目。

增长的太快了!就像Twitter一样。这样疯了一般的增长只能说明一个事实——人们等待这个产品太久了

Social Coding

真实的项目,真实的流程,真实的人名,一切代码review, check-in, test, build, document, 甚至讨论,计划,brianstorming,流程,一切的一切,都是项目历史的一部分,都可以像棋局那样复盘。有经验的面试者只要稍稍扫两眼一个人的 GitHub历史,挑出几个check-in历史看一看,便完全能够迅速判断这个人是否满足他的要求。不再需要费劲心机地去想题目,去观察,去揣测,去花 费大量的时间的同时还只能采样到几个极为有限的点。

不像象牙塔里面大作业,这里有源代码管理系统,自动化build,有check-in,有review,有分工,有合作,最重要的是——这是一个集市,一个超出象牙塔的集市,牛人相互吸引,你可以在互联网上找到和自己拥有共同兴趣的一帮人,真正做起一点事情,而不是交差,不需要受限于几十个人的一个小班级。Here Comes Everybody

为什么我这么有信心?因为这事儿已经发生了。这个想法也完全不是我原创的

正如很多事情一样,现在在国内发生的事情,往往是美国那头的历史。今年7月中旬,纽约一家公司的工程师老大发了一篇博客文章:Github is Your New Resume。指出一个惊人但再合理不过的事实:越来越多的IT公司在招聘的时候要求应聘者给出GitHub账号。甚至已经有人为GitHub写了根据GitHub上的历史自动生成简历的工具

仔细想想,这是必然的趋势,没有比这个再合理的事情了,既然StackOverflow的历史能够作为简历,GitHub的历史不本该就是更好的简 历吗:你想要具有实战经验,懂check-in懂review懂test和代码质量的重要性,懂交流和沟通的重要性,你本就应该在一个真实的项目当中去锻 炼这些东西,而这些在目前已经完全可以办到。正如邹欣老师所说,你的工作就是最好的面试

这件事情放在早几年,是完全没法做到的,因为我们那时候还没有GitHub。正如没有Twitter,没有微博之前,很多事情都不会成为可能一样,你有千钧之力,缺乏一个合适的支点,也没法撬动一整个社群。无组织中的组织,具有强大的杠杆效应。

这个事情里面,我唯一提出的东西就是:在目前国内这个现状下,苦闷的招聘者应该主动行动,给出一些建议项目,正如前面提到的书单计划一样,招聘者需要给出的只是引导和清晰明确的目标, 剩下的事情,应聘者自然会去完成,这些项目可以是实验项目,也可以是完全能做出点卖钱的东西的项目(如果好好做的话),唯一的不可或缺的前提是,项目不能 太小,单人就能完成的项目不理想,一两个月就能完成的项目不理想,最好足够大到能够锻炼到方方面面,偏大一点倒是无所谓的,因为一个尚未完成的项目完全可 以作为简历。当然,可以想见的是,真到了那个时候,学生们肯定又是不会满足于仅去做那些已经有许多人做过的项目了所以这里企业们一开始所建议的项目只是一个《Nudge》,是滚雪球之前需要的一点初始动能。后面的事情,他们自己会完成。

“GitHub计划”同样有一些明显的、甚至不可替代的优点:

  1. 清晰、明确,完全可度量。
  2. 防伪:同样不担心“泄题”。你伪造不了GitHub历史,伪造不了check-in历史,review comments,文档,交流记录…
  3. 它不但是招聘,也是不花精力的培养。善哉善哉。
  4. 评估的责任很大程度上交给了应聘者自己。

从你的GitHub旅程开始,你就已经一脚踏进了真正的企业,而企业的面试也已经开始。

书单+GitHub,就相当于一个两年左右的面试。

没有什么面试比持续两年的面试更具有信息量。

书单,加上项目,已经基本上覆盖了所需的全部技能。最妙的是,有太多的人在焦急的等待着他们未来的雇主给出明确的信号,他们想投入精力,去学习和实践,去成为企业需要的人,但是他们就是不知道往什么方向走,所谓有动力没方向。所以,雇主给出了清晰明确的要求,相信对于很多人来说反倒是一个解脱:“终于知道该干什么了”。《编程之美》为什么常居畅销榜?因为它透露了雇主眼中的需求,明确、清晰的需求,可以实现,并且知道怎么去实现的需求。

你提前两年就开始面试和培养未来的候选者,而且还不需要你花出一分精力,而且人家还很乐意,没有比这更完美的面试了。

想一想,以后那些没见过世面的公司看见你拿出GitHub账号给他看,该是多么惊讶同时又觉得多么合理。

而这一切,只是因为两个小小的改变:

  1. 由需求方(雇主)给出了清晰、明确的目标。
  2. GitHub这样的平台。

那么,学校/老师在这个事情当中的位置呢?说实话我不知道。没有哪个行业像IT行业这样特殊:没有什么东西不能够(应该)在互联网上学到的。自组织的力量完全大过传统的教育方式。而且,既然雇主都当了领路人了,我不知道还有中间开发商什么事儿。(注:这里说的是软件开发,并非计算机科学研究,后者另当别论

那么,这个改变会发生吗?多久会发生呢?当然,它在国外已经发生了,所以问这个问题多少有点无趣。但我还是预计很快就会在国内发生,毕竟,不是已经 有人要求出示博客,和经常浏览的网站了吗?也许5年左右(4年本科和6年硕士的中间值?))就会深刻改变整个人才培养/招聘的格局。当然,我并不是预言 家,所以不要把我的时间估计当真,我能肯定的是,这种方式是必然的大势所趋。

刚才我就收到一位同学邀请我上知乎回答一个问题“找工作的首要原则是什么?”,当然,这个问题的答案是:“弄清雇主的需求到底是什么”。


列一下我所认为的,你面试微软前必须要读的十本书:

  1. Code: The Hidden Language of Computer Hardware and Software (《编码的奥秘》)
  2. Computer System: A Programmer’s Perspective (《深入理解计算机系统》) / Windows via C/C++ (《Windows核心编程》 / 《程序员的自我修养》
  3. Code Complete 2(《代码大全》)/ The Pragmatic Programmer (《程序员修炼之道》,我也把这本书称为《代码小全》)
  4. Programming Pearls (《编程珠玑》) / Algorithms / Algorithm Design / 《编程之美》
  5. The C Programming Language
  6. The C++ Programming Language / Programming: Principles and Practice Using C++ / Accelerated C++
  7. The Structure and Interpretation of Computer Programs (《计算机程序的构造和解释》)
  8. Clean Code / Implementation Patterns
  9. Design Patterns (《设计模式》) / Agile Software Development, Principles, Patterns, and Practices
  10. Refactoring (《重构》)

(注:1. 以上同一条目下用“/”隔开的表示任选,当然你也可以都读了,相信我,时间是足够的。2. 读这些书并不意味着逐字逐句从第一页读到最后一页——当然你也可以这么做。怎么是聪明高效的读法,可以参考我之前写的关于如何阅读和查找/鉴别书籍/资料的博文

注意:以上是我个人认为你面试微软开发职位前必须要读的10本书,它不代表我的雇主的观点。它也只是一个初步的书单,肯定会受到我个人经验和眼界的限制。欢迎大家提意见。

此外,IT不同子领域的必读书单可能千差万别,所以在发布之前我把这篇文章发给了一些朋友,他们给出了自己的书单(你是不是能看到一些有趣的共同点呢):

云风(中国游戏编程先行者,前网易游戏部门资深程序员,简悦创始人):

如果面试,我会挑以下的我自己读过的书,让人选择他也读过的部分,再了解他对这些书的理解。这些书其实本质上就是两类,对所面对的东西(程序语言也好,操作系统也好,底层设施也好)本身的理解程度。以及另一类:对设计思想和原则的理解:

  1. C++编程思想
  2. Effective C++
  3. 深度探索C++对象模型
  4. C++语言的设计和演化
  5. C专家编程
  6. C陷阱与缺陷
  7. C语言接口与实现
  8. Lua程序设计
  9. Linkers and Loaders
  10. COM本质论
  11. Windows核心编程
  12. 深入解析Windows操作系统
  13. 程序员修炼之道
  14. 代码大全
  15. UNIX编程艺术
  16. 设计模式
  17. 代码优化:有效使用内存
  18. 深入理解计算机系统
  19. 深入理解LINUX内核
  20. TCP/IP 详解

冯大辉(丁香园CTO,贝塔咖啡创始人):

  1. 软件随想录
  2. 黑客与画家
  3. 重来
  4. UNIX编程艺术
  5. 编程人生

洪强宁(豆瓣技术总监):

StackOverflow上有一个程序员必读书单帖子,这里仅列出top10,更多参考这里

  1. Code Complete 2
  2. The Mythical Man-Month (《人月神话》)
  3. Code: The Hidden Language of Computer Hardware and Software (《编码的奥秘》)
  4. TAOCP (不解释)
  5. The Pragmatic Programmer (《程序员修炼之道》)
  6. Design Patterns (《设计模式》)
  7. The Structure and Interpretation of Computer Programs (《计算机程序的构造和解释》)
  8. Refactoring (《重构》)
  9. The C Programming Language
  10. Introduction to Algorithms (《算法导论》)

郑昀(窝窝团研发副总裁):

  1. 工程师入门:
    1. Code Complete 2
    2. 程序员修炼之道
    3. 深入理解计算机系统
  2. 工程师升级:
    1. 设计模式
    2. 重构——改善既有代码的设计
  3. 工程师转型:
    1. 快速软件开发——有效控制与完成进度计划
    2. 人月神话
    3. IT项目管理那些事儿
    4. 软件随想录
    5. 最后期限
    6. 走出软件作坊
    7. 你的灯亮着吗?——发现问题的真正所在

张峥(微软亚洲研究院副院长):

  1. Algorithms (by Sanjoy Dasgupta, Christos Papadimitriou and Umesh Vazirani)
  2. Data Structure and Algorithms
  3. The C Programming Language
  4. The Design of the UNIX Operating System
  5. Compilers (龙书)
  6. Computer Architecture: A Quantitative Approach
  7. Flow
  8. Outliers (why hard work and luck are both important)

邹欣(MSRA创新工程中心首席研发经理):

关于创新的书籍(http://book.douban.com/doulist/1253169/):

  1. The Myths of Innovation
  2. The Innovator’s Dilemma
  3. The Innovator’s Solution
  4. Crossing the Chasm
  5. Inside Intuit
  6. 盛田昭夫
  7. 杰克·韦尔奇自传
  8. 梦断代码
  9. Innovation
  10. 浪潮之巅

关于“精通”的一篇博客《技能的反面:魔方和模仿》:

http://www.cnblogs.com/xinz/archive/2011/08/07/2129751.html

在我教的《现代软件工程》课上,除了教科书,每个学生要看另一本相关的书籍并写读书分析。这个博客有一些同学的读书报告:
http://www.cnblogs.com/OMG-Team/archive/2011/10/25/2223247.html


读好书是如此的重要,因为好书往往带领你去到更好的书,更大的世界。