原力的黑暗面

本人是一个《星球大战》的粉丝，同时也从一个程序员做起。觉得软件的开发和Jedi骑士的原力其实有很多共通之处。

原力是直觉

首先让我们回忆一下这个镜头：

 

Obi-Wan Kenobi第一次训练Luke的时候，让他用光剑去挡住一个不断移动的小球发出的激光。是不是觉得太容易了？于是Obi-Wan让Luke再试一次，这一次，他把Luke的双眼蒙上。

Obi-Wan：“这次放开你的意识，凭本能行事。”

Luke：“我看不见，有怎能搏斗呢？”

Obi-Wan：“你的眼睛会欺骗你，不要相信它们，用你的感觉。”

 

软件的开发何尝不是如此呢？仔细想想我们以前遇到的困难，取得的成功，都和我们的直觉有关。

比如，公司长期把瀑布模型作为唯一可用的生存周期，那种规整的开发模式让新员工感到新奇和敬畏。可没多久就会发现，这样做并没有做出多少技术成功的产品，不见得比以前的直觉的开发方法强多少。于是很多项目做了他们自己的选择：虽然嘴上不说，但行动上自发地离开了瀑布式开发，选择了迭代式开发，以至于现在，几乎没有一个项目是完全瀑布的，项目之间的差别仅在迭代的周期和方式。

有什么人告诉过他们瀑布式方法已经被废弃了吗？没有。他们这样做，只是相信他们的直觉。他们在开发的过程中发现瀑布式模型不能解决问题，反而带来了大量的麻烦，作为一个合格的工程师，就应该想办法去解决这个矛盾，虽然没有人告诉他们迭代比较好，但直觉告诉他们迭代有可能解决问题，于是他们走了这一条路。

2年多前我第一次接触了XP方法，它的思想让我耳目一新，开始重新思考我以前做过的事。我在做学生的时候做过不少项目，从结果上看也比较成功，当时并没有人指导，但迭代，重构，好像是很自然的事情。不迭代行吗？不行。因为开发时间不够，必须先把客户最需要的功能先做好，剩下的锦上添花的事慢慢做。不重构可以吗？我受不了自己的代码有大量重复和冗余，隔几天就会修改一堆代码，结果代码量是螺旋型上升的。啊，对了，我们居然用了On-site Customer！在一排开发计算机中，就有一台是客户单位的工程师长期占用的，每天他上班的任务就是不断用我们的软件，把发现的问题和一些建议反馈给我们。

当然，也有做得非常失败的地方，比如SCM。由于缺乏版本管理，经常改过的BUG又出现了，直觉告诉我们这有问题，需要一种控制手段，但当时还没有见过什么ClearCase之类的东西，所以也不知道如何解决。

是的，一切都是工程师的直觉，他们知道该怎么做。对于一个管理者来说，只需要给他们说一些以往的大的失败教训，不要走过多弯路就可以了（适当的弯路是必须要走的，只有在实践中失败过，才能记得牢。）。

但是不是所有人的直觉都可以来制定规程呢？不是，只有Jedi武士才有原力。原力来自于他们身上的迷地原虫。迷地原虫数量越多，原力就越强。对程序员来说，软件的迷地原虫就是他们编写的代码，对软件做的思考等等。如果程序员没有足够的软件开发经验，让他们用直觉来做事是自找麻烦。

好了，我们尝试一下，深呼吸，保持心情平静，发挥你的本能，问问自己一些问题：

你是否认为如果不写一点代码，光想“设计”很困难，最好能把自己的思想用代码验证一下，甚至只需要是一些框架性代码？

你是否在维护一些看不懂的代码就想重写一遍？

你是否觉得简单对软件非常重要？