每个团队都应该有一个Appfuse式的项目

转自：http://www.blogjava.net/calvin/archive/2005/09/13/12878.html 

 

   一个Appfuse式的项目，会通过项目里最典型的几个场景，demo团队目前的体系框架和设计模式。 

   它的好处有一打，比如为所有项目提供共同的Library Stack，提供最可靠的代码蓝本，保证大家的模式和代码风格一致，加快知识在团队的传播，方便新人的融入，还有为试验代码提供一个稳定简洁的环境。

   所以，一个长期合作的团队，需要这样一个MyAppfuse。

   但还要有三条铁的纪律，才能保证辛苦做出来的MyAppFuse不是个寂寞的芭比。
   一是强制更新，所有团队approval的最新模式都要refactor到MyAppfuse中。
   二是规范更新，每次更新都要严格测试并编写更新记录、移植文档。
   三是强制Copy Start，所有代码都必须从MyAppFuse里Copy而不是随自己喜欢找任意项目的代码。

   现在开始规划一个Appfuse式项目。我觉得包含如下Content：
   1.设计典型的应用情景。
       我平时的ERP项目，最典型的情景莫过于：
       *基础资料管理（如产品资料的CRUD)
       *单据管理（如订单的录入与管理）
       *典型报表

       每个场景应该有简单与复杂两种模式，方便Developer选用。
       场景要仔细设计，尽量演示到所有重要的技术要点。
       但场景又要尽量的少，尽量简洁，减少每次模式升级的成本。

   2.挑选出其他比较重要的特性。
        如Quartz、ClickStream，也一并放入MyAppFuse中。

   3.把所有用到的框架、类库、瓶瓶罐罐统统打包。
       并附上索引和说明作为团队公用的Library Stack，每次library升级都要认真检测。

   4.编写文档。
        类似Appfuse的Tutorial，编写文档说明各个场景用到的技术要点与模式，说明如何二次开发。
        类似Appfuse的Migrate，详细说明如何升级到MyAppfuse新的版本，促进新模式的传播。

   5.简单代码生成工具。
       类似Appfuse的AppGen，用Groovy Template或FreeMarker编写简单的代码生成模版。

   6.核心的测试用例

    后记:这个MyAppfuse终于开源成http://www.springside.org.cn