编码标准（coding standards）

项目开始的时候，我们决定采用Sun的“Java Code Conventions”作为我们编码标准的蓝本。随着项目的进行，大家不断地讨论并同意加入一些与项目有关的标准，例如：

* 所有的classes和所有的public and protected methods都必须要有JavaDoc注释；
* 对于packages，classes，variables的命名标准；
* 如何使用集合（collection）类型，如变量的类型需是interface，如Map而非HashMap；
* 如何使用实数类型，如规定用double而非float；
* 如何使用logging（我们使用log4j）；
* 如何处理exceptions，等等

源码审阅（code review）

源码审阅一直是项目的要求之一。但在项目的前半期，这点做得不是很正式。当然，一个主要的原因是大家想尽快地做出一些功能。这样造成的一个后果是源码开始有些杂乱并且不一致。项目后半期开始比较严格地进行源码审阅，并且规定一个“故事板”的源码在进入系统测试之前一定要有正规的源码审阅。

进行源码审阅时，审阅者一般是根据编码标准上所列的条款对源码进行检查，看是否符合标准。同时，也可对一些具体实现上提出自己的看法。这些意见用一张专门的表格一项一项地记录下来，交给编码者修改或给出进一步的说明。后，审阅者对源码复查，对每一项进行核对，满意之后签字认可。我们的经验表明，这样的源码审阅大大地提高了源码的质量以及可读性和可维护性。另外一个作用是使refactoring得以经常及时的进行。

源码重整（refactoring）

我们项目里，refactoring基本上是与编码标准和源码审阅同步进行的。项目的前半期，基本没有refactoring，尽管有些不好的码段或实现被不断的发现并记录在案。当然，主要原因还是由于大家想集中精力先做出一些功能。在项目的后半期，开始和源码审阅一起较严格地执行。和源码审阅一样，这样做的结果是大大地提高了源码的质量。

以上这些是对这个项目的一些观察与思考。总之，对开发人员来说，这个项目有许多的不确定性，这主要反映在需求与规范文件上，也反映在相关项目组之间的协调（或扯皮）上。项目组分散两地，测试环境的缺乏都是开发中的很大问题。在这种情况应用XP的实践原则，如密切沟通，单元测试，源码审阅与重整，能有效的（也许是艰苦地）推进项目的进展。

后记

记得几年前曾看过一篇文章是讲中国的MBA的教育的。大意是说工商管理是个实践性很强的专业，做MBA的一项主要工作是做大量的个案分析。而目前中国似乎还没有足够的个案，有待于现在的MBA们毕业后在工作中去积累。这些积累起来的个案将是今后MBA们一笔宝贵资源。由此想到软件开发，何尝不是如此。软件开发是个实践性很强的群体/团队工作，这点从三十几年前“软件工程”的提出时，人们已经认识到了。提出的方法也是层出不穷，但真正在实践中运用的并不多。这几年出现的以XP为代表的agile方法兴起，主要原因是在于它们是从工程实践中提炼出来，而其可行性至少在一定条件下或范围内又为他人的实践所证明。那么我觉得现在重要的不是高谈阔论，而是扎扎实实的实践，即在了解这些原则后如何在工程实践中加以运用。更进一步，如果能把这些实践记录下来，加以总结，这对自己和同道都是一件好事。基于这样的想法，在下不避琐碎，把自己对一个项目的观察与思考写下来，期望能抛砖引玉，看到更多的同道能把自己的经验写下来，与大家共享。