每个团队都需要有自己的APPFUSE

来源:百度文库 编辑:神马文学网 时间:2024/10/04 03:49:25
一个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.核心的测试用例