这篇blog原本还是打算在Word 2007里写的， 后来作为草稿发上来，发现还有不少不如意的地方，还是在线写吧。

想说的事情挺多的，一件一件的说吧。

一、敏捷中国大会，6月6日在上海交大举办了一场。专门介绍ruby的，昨天在csdn的martin fowler的中文blog上，也贴出了完整的演讲全文。《Ruby是一个非常好的开发工具》，《现场演示Ruby编程》，《细数Ruby语言优缺点》。关于这次活动的一篇Blog按理我早就该写了，但是却一直没有写出来。有两个原因，一个是那天老马在开讲之前，熊节是打算在边上当翻译的，谁知道交大的同学们牛啊，纷纷表示，不必翻译，都听得懂的，我一个学俄语的人，在那里抗议也没什么用，大家都一副听力很好的架势，老马在上面叽里呱啦的讲着，下面的同学们不时的笑着……我呢，也只能随着大家的笑声，冲着老马空洞的笑着……；第二个原因呢，是个原本打算等CSDN的演讲的翻译出来，我也好引用一下，谁知这一等，就是半个月，我都已经换了一个工作了。

说实话，那天老马的演讲，我没听懂，不过因为他在那里现场coding，所以我还是看懂了一些代码。Ruby的代码给人留下了深刻的印象，而且我不知道是不是Martin故意装作是一个初哥，反正看起来他对ruby的语法也不怎么熟悉，不过ruby厉害的地方就在于，你就算是个初哥，边试边弄，也能把程序鼓捣出来。

原本的计划是介绍Ruby DSL的，不过时间明显的不够用，关于DSL的部分反而讲得很少，还好这两天armlinux-w翻译了一篇专讲Ruby DSL的文章过来：《用Ruby 创建领域特定语言》。当时看到Martin演示的，用Ruby语言描述的配置文件时，脑子里颇有些想法，也写了问题交上去问，不过老马也来不及一一回答，后来想想，提的那个问题，也没有经过自己的深入思考与实践，不提也罢。

倒是我提的另外一个问题，颇有些价值，当时正好交大的林德樟老师也在，我以前就对林老师的那句语录有所不满《XP是草书，UP是正楷，先草书后正楷，就会乱套》。在自己的Blog上也和林老师的门徒们吵过架，如今Martin教主本人既然来了，我等看客正应该把这仗挑起来才是。于是我就提了一个问题，让两位专家都来评价一下这句话。可惜的是，后来他们两人的精彩交锋，我也没怎么听懂，还是林老师还用中文阐述了一遍自己的观点，我算是了解了一下他的逻辑。

原来我以为，林老师这样的说法，是出于在校教师“和稀泥”的考虑。这下我才了解到，原来林老师是真的这么认为的。而他这么一种说法的依据，还是惯常的“中国国情论”。或者称之为“补课论”。因为美国人是现有软件工程，才有极限编程，而我们现在的软件产业还落后人家几十年，所以不把软件工程这一课不上，是不行的。然后林老师还颇有些“攻击力”的询问Martin，当初你先写了UML，后来又写了XP，不也是这样一个心路历程吗？老马如何回答，我也没有听懂，但是在我看来，林老师混淆了三个概念，一个是国家级的软件产业的发展水平，一个是企业级的软件开发的管理水平，一个是开发人员的技术与理论水平。这三个不同的水平被他搅在一起，用于支撑自己的说法，实在是所以，会后我又追上去问林老师，我提出了三个概念混淆了云云，没想到林老师相当和蔼可亲的对我说：“嗯，你说的没错”，然后又说到关于大学的软件教育的问题，我在说很多刚毕业的学生，对于软件开发的理解，往往停留于知识点的积累上，而没有去思考，我打算把这些知识点，组合起来运用，以达到什么目的。很多学生，只是说我知道什么什么，而不会说，我会做什么什么。林老师又和蔼可亲的对我说：“嗯，你说的没错。我一直跟学生们说，学校和企业是完全不同的，真正的知识，只能在企业里才能学到。”然后我又说，其实软件学院应该多推荐学生去企业实习，还有就是多鼓励学生参与Open Source的项目呀。林老师还是和颜悦色的对我说：“是啊，不过现在的企业，要他们肯接收学生实习，不容易的。在美国，每年暑期都会有大量的实习生招聘，这其实就是企业在做慈善呀。再说现在的大学老师，对Open Source的了解，也很少的呀。”然后，我就跟林老师告辞了。作为一个老师，他给我留下了很好的印象，但是，我更加悲观的发现，要通过学校教育，提高软件开发人员的素质，好难啊！

会后大家又找了一家小饭店FB了一下，CSDN的霍泰稳也来了，我还给他们提了一个建议，以后CSDN最好能够搞一个系列的活动，不断的把世界各地的软件大师们请到中国来，巡回演讲，收取门票，整理成每年基本的《软件大师在中国》这样书出版，还有视频光盘也可以卖钱，各位大师的中文Blog也都建在CSDN，应该是一桩双赢的好事啊，就看他们是不是打算做了。

(待续)

不要出来搞笑说：

没有bug的程序？????????
靠，站着说话不腰疼。那个公司可以做出没有bug的软件来？
当然，没有写过程序的人不出bug!!
估计这位同志不会写代码，是个理论专家。
还是不要这么狂的好。
我估摸按你的标准，你是肯定不会被别人录用的！

123说：

你是编程的吗？
无“BUG”搞笑吧你
测试是不能查出所有BUG的
而且不是所有测试都能穷举的
只能是测试覆盖率达到一个标准
BUG出现的概率达到标准
才算产品
“ZERO-BUG”做梦去吧

文档是项目的知识，这些知识必须集中管理、容易获取、人人可以编辑。

项目在生长，代码在增加，文档也必须能够跟随项目自然生长，强行划分设计阶段和开发阶段，是不可取的。

Wiki不是传统的项目文档，而是一个应交流需要，可能随时增删改的知识库。项目组的成员，遇到问题，就应该首先查看Wiki，如果这是Wiki中没有，那么他应该找人询问。而那个知道答案的人，如果他不想再今后不断的回答同一问题，就应该把这个答案写入Wiki，这就是Wiki条目增长的自然动力。

传统文档最大的问题在于浪费，而Wiki通过持续修改，按需提供的方式，保证了所有写下的文字，一定有超过一个人需要读它。

Include功能，增加include标签，可以在一个条目中，引入其他条目的全文，而不是仅仅增加一个link。

文档的层次结构，当项目的文档条目逐渐增加，分门别类的条目，更加便于查找，也可以有效的避免条目重名的问题。

一个Click，就能够创建新一个条目，用于填写当天的工作安排。

每日15分钟文档制度，基于“填写当日工作”的功能，我规定每个项目组成员，每天要花三个5分钟来写文档，早上的5分钟，填写当日工作计划。中午的5分钟填写上午的工作情况，下班前的5分钟，填写下午的工作情况。这样，每天的文档工作相当轻松，但是文档能够保证持续的跟随项目成长下去。更进一步的，这样的制度，对于项目的进度控制，也很有帮助。

User Case条目驱动，所有分解出去的User Case，在分配到责任人之后，该责任人的第一项工作，就是在Wiki中写下对于这个User Case的理解。随后项目进展，也应该持续的维护这个条目。

同时进行Bug的管理，Bug也作为Wiki中的条目，以便于和其他条目项目引用。

每次Check In CVS时，必须写注释。这是更加细节的文档，然后我还做了一个小程序，能够自动的从CVSTrac中读出当天Check In代码的注释。供每个人在写当天文档的时候引用。

　　文档驱动、测试驱动、用例驱动、模型驱动、特征驱动。。。。他们都要解决的是什么问题？

　　要回答这个问题，还真不容易。我们得问一个更加重要的问题，真正驱动项目的，究竟是什么呢？我想，应该是需求吧？

　　那么，这些“文档”、“测试”、“用例”、“模型”、“特征”，究竟是什么呢？对于需求的描述！我们之所以不会直接用需求来驱动项目开发，而是要借助工具，来帮助我们描述需求，就是因为口语化的需求描述是非常模糊的，充满歧义的。所以，选择什么来驱动我们的项目，其实就是要看，以上这些工具，哪一个能够更好、更准确的描述需求？

　　文档其实是最难准确描述需求的一种方式，如果是纯文字的文档，就更难。我们的技术总监，非常喜欢读写文档，我最近也创下了一天写47页文档的最新记录。但是，当我们开会的时候，我还是经常需要提醒我们的技术总监，麻烦他再仔细看看文档第XX页的第XX段，以及配合着另一份文档的XX小节，来确切的理解我的意思！如果没有我的解释，他就会误解我的文档。

　　当然，如果要写出不需要我来解释，他就能理解的文档，那么文档的工作量，将会极其惊人！我以前写过一篇blog，《Jacobson博士演讲观后感》是我对UP的创始人的极度反感的集中体现。GHawk，以及交大林老师的所谓“UP”的观点，当然不可能获得我的赞同。在GHawk的最新一篇blog：《UP & XP之争，意义何在？(续)》中，GHawk说：“唯一的问题是：“如何确保测试用例的质量”。显然，我们不能把一把不直的尺子度量出来的结果作为可靠的参考依据。怎么解决呢？“结对编程”么？嗯，这是一个不错的方式，那么最终该信赖谁呢？是Pair中的A还是B呢？或者，是Leader么？那么又是谁提出的要求呢？是老板么？还是客户？政府？法规？市场？……问题没有终结了。”

　　由此我可以推断，他对于XP的认识，基本上是停留在猜测的阶段。对于这篇blog的观点，我就不逐一反驳了，我的猜测是，他经历过一次失败的XP尝试，而究其原因，我猜测是因为他们那个所谓的XP Team中，没有一个人，曾经实践过一次正规的XP开发。

　　再来看模型驱动，这中间有一个大问题，因为需求是“问题域”的范畴，而模型，则是“解答域”的范畴，试图通过解答域的精确描述，来实现对于需求的准确描述，肯定不靠谱啊。

　　特征驱动，我认为FDD其实是老方法的新名词，具体的实践，可能更加接近测试、迭代式的过程。了解不过，所以我也不打算多说。

　　用例驱动与测试驱动，其实我认为这是一个硬币的两面，用例要尽快的翻译为测试用例，而测试用例，正是为了更加准确的表述需求用例。这是我能够想到的，驱动项目开发的，最好的方法！