Alvan - From the Hermit to the World

以前看过一篇文章说，一个习惯坚持21天就可能成为你一生的习惯，比如早起。我想，这大概就是常说的强迫症吧……

OK，冷笑话完毕，说正事。

一、
早上一到公司就到网上申请户籍证明，结果被系统告知今天客满，于是下午不得不跑了一趟延安西路900号。得到的经验是，落户在上海的同志们同学们，要到网上申请户籍证明一定要赶半夜零点申请。后天就要去签证面试了，加州的阳光，你要等着我啊~~~

二、
关于面向进化的软件开发模式，我来打个比方吧。传统的瀑布模式，就好比上帝造人。需求是这样的：
1、人必须是活的，能新陈代谢，能动，能跑，能繁殖
2、人必须能适应地球的环境，或者至少能适应部分环境
3、人必须有智能，会思考，彼此之间能交流
4、人必须有四肢，有五官，有五脏六腑
……
姑且列这么多吧，研究生物和人工智能的同学都知道这是个很难的课题，当然对上帝来说可能算不了什么，他可以分析这个需求，然后设计出人类的物理和心理架构，然后进行生物工程造出一个人类。当然，这其中会有一些bug，有一些出现在设计阶段，有些出现在实施阶段，反正结果很难控制。
而面向进化的软件开发模式，顾名思义，就是像生物进化那样。上帝可能很懒，或者没有把握一开始就设计出一个成熟的种群。于是他就做了一个最简单的生物——草履虫。它满足了一部分比较基本的需求，可以动，可以新陈代谢，也可以通过分裂来进行简单的繁殖。后面的正如我们大家都知道的，它进化成很简单的腔肠动物、节肢动物、两栖动物、爬行动物、哺乳动物，直到最后的人类。自然界进化的方式是变异，软件中进化的方式就是重构(refactor)。

重构在一些人看来可能是件很麻烦的事，意味着要将很多代码推倒重来；在另一些人看来可能是可有可无的事，只是将代码整理一番，剥离出一些函数一些类就行。当然，GoF的拥护者中也有一批重构的狂热分子，恨不得将一切代码都套上设计模式。我的看法是：
第一类人，他们面对的代码经过精心的设计，精巧漂亮。整个系统在设计阶段就考虑到很多可能性，划分为不同层次以方便不同级别的程序员开发，并且设计好各种可能的接口，宁滥勿缺。开发阶段，程序员也严格按照function spec来进行，就像流水线上的机械手臂，职能清晰。当几十个人，乃至几百个人都按照这个总体设计分工协作的时候，重构已经几乎没有多少空间。就像微软的某产品经理说的那样，当一个负责人接手一个模块的时候，他所面对的系统复杂度已经远远超出了人脑的处理能力，所以他们会刻意回避重构，除非这个模块在某一天彻底无法工作为止——只要他所负责的模块不在自己的任期内出问题，他们就不会做任何设计上的变动。
第二类人，只是错误理解了重构的内涵。refactor不是修饰代码，当然也不像restruct那样对整个系统进行颠覆性的设计。
第三类人，也许可以称为“重构原教旨主义者”，狂热者的行为是心理问题，不是软件工程问题。

为了让重构能够达到我们需要的效果，以下是几个指导思想：

1、自下而上的设计。
从功能点开始设计，而不是整个系统的需求范围。很多人反对这个看法：你今天完成功能A，明天完成功能B，如果将来A和B不能正常整合到一起怎么办？我的回答是，如果A和B在经过简单的修改后无法整合，那说明要整合它们的需求本身就是不合理的。也许听懂的人已经听懂了，听不懂的人我只能告诉你：半人马和人鱼之所以不存在地球上是有原因的。

2、先设计功能，后设计接口。
这恐怕又是一个难以被接受的观点，因为很多设计参考书籍都会建议你先设计出接口，然后按照接口设计不同模块。没错，现代工业的基础就是统一接口：没有统一的铁路轨距，造出的火车就无法上路；没有统一的螺丝尺寸，电脑机箱就很难装配；没有统一的主板插槽，各个厂商的设计的元件就无法协同工作。不过，你有想过为什么铁路的轨距是四英尺又八点五英寸？为什么全世界的PC机箱制造商都使用统一直径的螺丝？为什么主板CPU插槽不停在更新而IDE接口却十几年都未变过？是的，你也许真的想不到，火车是先于铁轨制造出来的，机箱是先于螺丝设计出来的，而CPU插槽更新的快是因为CPU更新的快——功能总是先于接口被设计出来的。如果你还坚持应该先协商好CPU针脚矩阵，再分别设计主板和CPU，那我只能庆幸你不是在Intel或者AMD工作的。当然，我还是要为你所工作的软件公司默哀了。

3、不要为后天的功能做设计。
前段时间有个颇为经典的游戏。让100个人每人在纸上写一个整数，范围是0-100，谁写的数字最接近100个数字平均数的2/3谁就是优胜者。你会写多少？
简单的说，如果大家都随意写，那么概率最高的平均数是50，50的2/3就是33，那么33也许最接近的答案。
当然，有稍微聪明一点的人会想到，考虑到大家都懂得概率，那么大部分人都会选择33，于是平均数就该是33，33的2/3该是22。
这个时候“更聪明的人”出现了，既然已经算到了22，那么也许大部分人会选22，然后结论就是22 的2/3，这还不算完，能想到22的2/3的就能想到22的2/3 的2/3……如此极限下去，最后的答案应该是0！
好吧，有人真的做过这个游戏，最后的结果是在 23左右。
这个事情说明一个道理，天才多走一步就可能变为蠢才，程序也是一样。为今天的功能写代码，为明天的功能做设计，后天？后天谁知道你的程序会变成什么样子？

先列这三条吧，应该足够简单，足够记忆。以后写什么我还没想好，想好了再补充修正。