<!----><!----> <!---->
最近我在新公司加班做项目开发，这个项目用 struts+jdbc 来做的，用 jvm 的代理来获得 bo （这里是指业务逻辑），设计那叫一个糟糕啊，我不知道怎么脱身出来。只想逃离这个焦油坑，不想谈这个东西呢。
我还抽时间了解 xp 的一些概念，除了那个 pair coding 我感觉有些奇怪，其他的感觉都挺不错的。下面我来总结一下（鼓掌 …blah blah ）
一：确定版本计划，每周或者每两周（更短或者更长）时间发布一个版本出来，让业务人员、客户看到这个东西，提意见、需求。然后根据新的需求（假如变动不大的话）再来发布下一个版本。就这样直到项目完全发布。
二：测试，根据我的考虑， web 程序不怎么好测试，当然现在也有那个测试页面的。但我觉得把业务逻辑主要都在 bo 里面，就测 bo 功能就可以呢，而 dao 也简化，负责单一的 crud （我以前把业务逻辑都放到 dao 里的，而 bo 基本是空的）。 Dao 的事务、错误都 throws ，在 bo 里处理。
三：持续集成，用一些工具来做，我打算选择 hudson 来做这个。
四：版本控制，我目前在做的那个项目竟然没有使用版本控制工具，提交就把代码发给项目经理，磨刀不误砍柴工的道理都不懂。每次我手工 copy 提交代码时就囧。我给项目经理推荐 svn ，结果都不会用。 最后我找了个 Mercurial 来控制我自己的代码版本。
五：文档，需求文档是必须要有的，而且要精确描述（或者不描述）。最不爽的是那种有错误、没有及时更新的文档，影响开发速度、影响程序员心情。我觉的可以用 wiki 的方式来解决，如果是用 trac 来管理的话，业务需求直接写在 wiki 里，这样谁修改了，大家就都可以看到。
总的来说，我的思路就是围绕 xp 工具来做 Trac+Svn+Hudson ，系统设计用 Spring+Hibernate/jdbc+tapestry+Testng ，手头项目结束后我做个原型出来，让那些垃圾设计感到羞愧。