http://dtslob.spaces.live.com/?_c11_BlogPart_BlogPart=blogview&_c=BlogPart&partqs=amonth%3d12%26ayear%3d2008
Dreaming in code Blog Post 3
Dreaming in Code这书，读着读着就到了尾声，然后惊讶的发现关于后面章节的内容和我的想法，有很多在前面发的两三个blog里（仅涉及开头3章）就已经有了。可能这本书开头那些宏观的描述让我产生了不少想法吧:-P
所以这次呢，咱们就说说Chandler失败的几个原因，找到一些原因了自然就会有相应的解决策略。（我还是用中文罢，自己写着大家看着都舒服，而且我的英文还是不能完满的表达出心中所想）
Chandler走到现在这步田地，其实很难把原因说清楚说完全。我零散的整理出以下几点：
1. 目标过于伟大
Linus Torvalds说：“Don’t expect to get anywhere big in any kind of short time frame……If it doesn’t solve some fairly immediate need, it’s almost certainly overdesigned.”
所以这次呢，咱们就说说Chandler失败的几个原因，找到一些原因了自然就会有相应的解决策略。（我还是用中文罢，自己写着大家看着都舒服，而且我的英文还是不能完满的表达出心中所想）
Chandler走到现在这步田地，其实很难把原因说清楚说完全。我零散的整理出以下几点：
1. 目标过于伟大
Linus Torvalds说：“Don’t expect to get anywhere big in any kind of short time frame……If it doesn’t solve some fairly immediate need, it’s almost certainly overdesigned.”
为什么Chandler的目标会被反反复复的定义，架构也重复设计了很多遍？因为OSAF的人，尤其是Kapor，从一开始就只有头脑中的一个幻象。他们幻想着Chandler“应该”对所有的事件都统一处理，“应该”是p2p的架构，“应该”支持互斥锁保证数据同步（我的描述可能不严谨，只是来源于我看后最深的几个印象）。在没有初步设计、没有可行性方案的情况下，谁也不能保证这些“应该”做到的就能做到。有人会想，单是这些幻想倒也无可厚非，毕竟想法都是好的，想为人类造福，但是问题在于Chandler的内在使命是要一步到位！
另外一个过于宏伟的目标就是“任何人都能发现 Chandler对自己有用”。我很怀疑这种想法的现实性，至少程序员和非程序员的需求就很不相同。谁敢说自己的软件有如此的智能呢？我认为这不应该成为做软件的目的。在设计的初期要定位适合的目标人群，即便是微软也不会定位成全体地球人吧！
题外话：目标不可过大又不可过小，那末软件的价值如何确定？我想，在决定做一个软件之前还是要先想象一下，假设你想做的东西已经有了，人们为什么要用它？能不能不用它也活得很happy，或者这样的软件是否已经存在？Bill Gates来清华的时候我记得最清楚的一句话，“软件是一种习惯”。有时自己想做的东西确实有killer feature，但实际做出来可能还是没人用，那这时候就要看习惯和killer feature两者火拼谁能赢了。对几个Team做的Project，我也一直在想这个问题。我觉得我们组的画图软件，对于某些人群还是能破除习惯的（当然是在消灭不能忍的bug之后）。一是像CTex那样，针对的用户是想用Windows风格的界面去实现原本是Linux下的功能；二是作为画图方面的大众用户，我只会用Windows画图程序、不会画矢量图，而在用我们的DTSlob Graphics画图的时候能发现很多更加方便的功能（IPE虽已具备，但是用着麻烦），至少让我很想用它替代Windows画图程序——当然还有一点，如果大众装电脑时都没有装.NET的习惯的话，这个习惯如何能让大众建立起来呢？
2. 松散的组织
一个由 volunteer组成的non-profit机构，想来就来想走就走，没有合同、工资、上下级等等。这种形式倒是够平等的，本意是要每个人的思想都能得到挖掘，但却缺少了点条例性质的约束。再者，资金的数额似乎是用之不竭的，招多少人都无所谓，开发Chandler的先后几年间队伍渐渐的换了好几批。除此之外，开发过程中一直没有坚定的采用某种方法论（比如到2005年才开始做TDD），可能也与松散的组织有关。所谓以兴趣结成的团体其实是最不牢固的。
所以软工课也一样，一个Team所有人得同样的分就只约束了Team，而无法形成对每个人的约束。
3. 人人都是专家
书中几乎每个人首次出场时，都用了两三页的篇幅介绍Ta的历史，就像三国里的武将现身定会有一段精彩的特写。每个人都有大项目的开发经历，都曾担任大公司重要产品或开源项目的工程师、架构师等等。这样的一群人到一起做事，看似会集思广益，实则拖慢了进度。每个人都有一套独门武功，来了个对手大家一起上，互相之间动作协调不好难免会伤及自家弟兄。其实他们可能都明白原有经验不能照搬到新项目上的道理，然而一开会讨论实际问题也许就都忘了，各说各的理。孙刘曹手下的谋士皆常有意见利益不和之时，如求自保则归隐山中，如被收买则弃暗投明。书中提到，有一个人度个假回来发现自己原来写的东西被完全抛弃了，这样的心情可想而知，不走才怪。
忽然想起做电梯的时候，课上老师问有谁愿意写接口，只有Lonnie主动接了这活。等出了一套接口大家用起来，开始怨声载道。其实各人心里都是怎么想的呢？“都是一个班的，凭什么我要用你的接口，何况用起来还这么别扭”。不过如此。
所以我认为Kapor招的人里面最好有一部分是啥也不想、只管实现、无怨无悔的码农。这样的人是有其存在价值的。绝对的人人平等是不可能的。
4. 闭门造车
当 Kapor看到基于AJAX的Gmail、看到众多基于网页的PIM相当方便的实现了跨平台之后，他也感到很不爽。但是没办法，他之前也看到了这些技术，但是固执的没有采用。天上一天，地上一年。当OSAP悠哉悠哉的改着架构的时候，Web 2.0风起云涌了，Firefox小占市场了，谁还会再破除一次习惯，刻意要去接受古朴的Chandler呢？
另外一个过于宏伟的目标就是“任何人都能发现 Chandler对自己有用”。我很怀疑这种想法的现实性，至少程序员和非程序员的需求就很不相同。谁敢说自己的软件有如此的智能呢？我认为这不应该成为做软件的目的。在设计的初期要定位适合的目标人群，即便是微软也不会定位成全体地球人吧！
题外话：目标不可过大又不可过小，那末软件的价值如何确定？我想，在决定做一个软件之前还是要先想象一下，假设你想做的东西已经有了，人们为什么要用它？能不能不用它也活得很happy，或者这样的软件是否已经存在？Bill Gates来清华的时候我记得最清楚的一句话，“软件是一种习惯”。有时自己想做的东西确实有killer feature，但实际做出来可能还是没人用，那这时候就要看习惯和killer feature两者火拼谁能赢了。对几个Team做的Project，我也一直在想这个问题。我觉得我们组的画图软件，对于某些人群还是能破除习惯的（当然是在消灭不能忍的bug之后）。一是像CTex那样，针对的用户是想用Windows风格的界面去实现原本是Linux下的功能；二是作为画图方面的大众用户，我只会用Windows画图程序、不会画矢量图，而在用我们的DTSlob Graphics画图的时候能发现很多更加方便的功能（IPE虽已具备，但是用着麻烦），至少让我很想用它替代Windows画图程序——当然还有一点，如果大众装电脑时都没有装.NET的习惯的话，这个习惯如何能让大众建立起来呢？
2. 松散的组织
一个由 volunteer组成的non-profit机构，想来就来想走就走，没有合同、工资、上下级等等。这种形式倒是够平等的，本意是要每个人的思想都能得到挖掘，但却缺少了点条例性质的约束。再者，资金的数额似乎是用之不竭的，招多少人都无所谓，开发Chandler的先后几年间队伍渐渐的换了好几批。除此之外，开发过程中一直没有坚定的采用某种方法论（比如到2005年才开始做TDD），可能也与松散的组织有关。所谓以兴趣结成的团体其实是最不牢固的。
所以软工课也一样，一个Team所有人得同样的分就只约束了Team，而无法形成对每个人的约束。
3. 人人都是专家
书中几乎每个人首次出场时，都用了两三页的篇幅介绍Ta的历史，就像三国里的武将现身定会有一段精彩的特写。每个人都有大项目的开发经历，都曾担任大公司重要产品或开源项目的工程师、架构师等等。这样的一群人到一起做事，看似会集思广益，实则拖慢了进度。每个人都有一套独门武功，来了个对手大家一起上，互相之间动作协调不好难免会伤及自家弟兄。其实他们可能都明白原有经验不能照搬到新项目上的道理，然而一开会讨论实际问题也许就都忘了，各说各的理。孙刘曹手下的谋士皆常有意见利益不和之时，如求自保则归隐山中，如被收买则弃暗投明。书中提到，有一个人度个假回来发现自己原来写的东西被完全抛弃了，这样的心情可想而知，不走才怪。
忽然想起做电梯的时候，课上老师问有谁愿意写接口，只有Lonnie主动接了这活。等出了一套接口大家用起来，开始怨声载道。其实各人心里都是怎么想的呢？“都是一个班的，凭什么我要用你的接口，何况用起来还这么别扭”。不过如此。
所以我认为Kapor招的人里面最好有一部分是啥也不想、只管实现、无怨无悔的码农。这样的人是有其存在价值的。绝对的人人平等是不可能的。
4. 闭门造车
当 Kapor看到基于AJAX的Gmail、看到众多基于网页的PIM相当方便的实现了跨平台之后，他也感到很不爽。但是没办法，他之前也看到了这些技术，但是固执的没有采用。天上一天，地上一年。当OSAP悠哉悠哉的改着架构的时候，Web 2.0风起云涌了，Firefox小占市场了，谁还会再破除一次习惯，刻意要去接受古朴的Chandler呢？
在Dreaming in Code一书的第10章Engineers and Artists中，作者提到了许多大牛对软件将走向何方的考虑。这些意见大体分为两派：革命党vs. 改良派。
革命党的意见自然十分奇特，比如用自然语言写程序啊，把编程的过程生物化啊，等等。这派意见认为软件已经陷于各种理论的bound和各种工具和经验形成的桎梏之中，不脱胎换骨就无法继续发展。他们要start over，寻求一条“科学”之路。然而我认为这样的偏激有以下不妥。
1. 要说科学的话，任何一门科学都不会完全start over。不可否认的是新发现新理论总会对旧科学造成冲击甚至危机，但是冲击或危机之后其实又常常是在原有基础上实行扩展，至少没有“把写程序变为种程序”这么大的变化。
2. 假使我们果真start over，之后呢？是不是还会面临像现在一样的窘境呢？这些start over的主张恐怕都不能说明这一点。或许computation theory里的各种bound、complexity的本质性是人类在计算这一课题面前不可避免的，无论以什么形式实现计算。
3. 从利益群体考虑，如果真的推翻了computation一切的一切，工业界、学术界、新闻界能够允许人类在这上面60多年的努力全部幻灭吗？
改良派的意见就更加可操作。他们也想寻求科学发展，并且抓住了科学的一个最重要的特点：继承性。现今的程序员不想看或者看不到前人的经典设计和代码，就像小孩玩积木，自己就搭自己的，搭出来自己觉得好看就够了。然而科学的发展历史中很重要的一点就是文献的编写和总结，如此才能高效率的完成创造性的发现。至于程序员能不能拿到真正大制作的代码……我有个信念是互联网和世界的发展潮流就是终极的共享。
前方的路虽然太凄迷，请在笑容里为程序员祝福……
最后，copy尾声中的一段话作为结束：
“Making software is still, and truly, hard. But I can hear the objection: There are different kinds of hard. Raising a child is hard. Burying a parent is hard. Birth and growing; living with other people or without them; trying to love them; failing to love them; accepting someone else's death; accepting your own—these things are hard. Software? That's a different universe of hard, a lesser one.”
革命党的意见自然十分奇特，比如用自然语言写程序啊，把编程的过程生物化啊，等等。这派意见认为软件已经陷于各种理论的bound和各种工具和经验形成的桎梏之中，不脱胎换骨就无法继续发展。他们要start over，寻求一条“科学”之路。然而我认为这样的偏激有以下不妥。
1. 要说科学的话，任何一门科学都不会完全start over。不可否认的是新发现新理论总会对旧科学造成冲击甚至危机，但是冲击或危机之后其实又常常是在原有基础上实行扩展，至少没有“把写程序变为种程序”这么大的变化。
2. 假使我们果真start over，之后呢？是不是还会面临像现在一样的窘境呢？这些start over的主张恐怕都不能说明这一点。或许computation theory里的各种bound、complexity的本质性是人类在计算这一课题面前不可避免的，无论以什么形式实现计算。
3. 从利益群体考虑，如果真的推翻了computation一切的一切，工业界、学术界、新闻界能够允许人类在这上面60多年的努力全部幻灭吗？
改良派的意见就更加可操作。他们也想寻求科学发展，并且抓住了科学的一个最重要的特点：继承性。现今的程序员不想看或者看不到前人的经典设计和代码，就像小孩玩积木，自己就搭自己的，搭出来自己觉得好看就够了。然而科学的发展历史中很重要的一点就是文献的编写和总结，如此才能高效率的完成创造性的发现。至于程序员能不能拿到真正大制作的代码……我有个信念是互联网和世界的发展潮流就是终极的共享。
前方的路虽然太凄迷，请在笑容里为程序员祝福……
最后，copy尾声中的一段话作为结束：
“Making software is still, and truly, hard. But I can hear the objection: There are different kinds of hard. Raising a child is hard. Burying a parent is hard. Birth and growing; living with other people or without them; trying to love them; failing to love them; accepting someone else's death; accepting your own—these things are hard. Software? That's a different universe of hard, a lesser one.”
 项目总结)
 电梯调度程序)
