项目改进

您好：

就本组的一些问题，提出一点改进建议。

1. 业务管理

   一般来说原始需求经过分析，整理出能够转换为代码的需求后，都需要完善的文档。这一点我们都做到了。但是我们并没有把所有的碎片文档整理成一个完整的文档。业务逻辑的变动非常频繁，往往都是开发人员直接修改代码，却没有做好文档管理。虽然文档管理很重要，但是长篇的文档管理是非常不合理的。实际经验是后续开发人员不会去阅读长篇的业务文档。所以我建议，使用一个在线的软件系统管理好我们AAM的逻辑，当有新的需求或者变更时，我们做好修改。在线软件系统的好处在于可以协同工作，可以不像Excel文档那样发来发去，而且交互快捷美观。举个例子：记录删除学校的业务逻辑，其一要删除班级并保存历史记录，其二要解除与班级学校相关的所有用户关系，其三要对学校做假删；其四，对solr和sme做好同步。另外，也可以将接口放入管理系统，所有人通过WEB浏览接口详情。

2. 代码管理

代码这块的管理含:后台工程，接口工程，中间件, 数据模型，缓存模型，网关工程，鉴权工程，转码工程。

 2.1 编写规范文档，文档要放入团队管理系统中。

 2.1 整理所有的工程，明确代码用处，编写人等。

 2.2 梳理代码写法，通常就两，列表查询和单个对象操作。代码的写法规范与框架息息相关。

 2.3 管理好数据模型，我们后台各个DB库都有很多垃圾表，过程，函数等。当前每当有新的DB改动，都是放入一个升级文件中，升级时候执行。这个过程倒是没错，但缺少一个环节，就是没有放入一个统一的文档中，并且，升级完后应该删除临时准备的升级脚本。

 2.4 目前缓存那块问题很严重，问题有很多，诸如缓存模型不透明，多模块公用AAM的缓存，缓存存储了大列表，连接数设置不合理等。

 2.5 无法做到实时统计。使用触发器定时统计只能放到深夜来做。因为统计的代码特别消耗计算资源。我们需要引进新的技术方案来处理实时统计功能。

 2.6 SQL写法上。诸如，不能关联太多的表，根据表的数据大小，减少关联数目。多采用异步查询方式。

 2.7 界面方面， 良好的界面交互不仅可以提高美观度，也可以提高性能。比如在大数据列表查询时，对核心表做一次分页查询，然后配合异步交互的方式单对象查询，就做到了速度与美观的双重功效，还充分利用了缓存。

3. 开发管理

 单人负责一个工程不太好，原因有其一，人员异动就等于功能丢失；其二，单个人处理问题或多或少都会出现死角，有的时候就类似于“当局者迷，旁观者清”。所以，我的方案建议如下。

 3.1 功能开发与修复，需要有两个人担当，一个为执行者，另一个是复合者。

 3.2 一周或两周一次，代码审核。

4. 最后一个问题就是AAM的版本日趋见多。

虽然目前AAM可以做到及时的部署，解决多环境多特异性的要求。但是功能整合的工作量较大。各环境版本的主要区别还是在于界面。

我最近想到的一个方案是，将不同的页面功能独立出来，用一个工程只做界面，所有的数据查AAMIF工程。只用一个后台工程即可。

如果有差异性就在界面工程里开发新的菜单即可。