敏捷迭代开发，有PO人员确定每个迭代的开发故事点，按敏捷过程确定开发内容、时间后，由各自负责任务的开发，着手进去开发。功能完成首先交由需求人员来验证功能是否完备，而不是由测试人员来验证，达到验收标准后再由测试参与进来。
数据库操作得基本方法、实体有MBG完成，生成的东西很多，写法也很规范，有个不好的地方就是生成的实体里没有表的comment字段。最多多就是把对应的表字段的名字显示出来，意义不大，有兴趣的朋友可以从github上clone份代码，把中文注释生成到实体中。
因系统是分布式架构，引入了dubbo zookeeper。但在开发阶段，可以不引入dubbo,zookeeper，直接利用jar依赖的形式来做，开发效率上要高出很多，也省掉一些麻烦。比如大家都用的话，因代码新旧或缓存的问题，难免暴露不同版本的接口出来，服务接口错乱导致功能不可用，甚至影响其他产品的正常使用，开发结束后再引入dubbo配置下即可。
接口繁多，开发调试单独由一人负责接洽，减少沟通成本以及不必要的学习成本。把全部接口写完后，通过junit与各方进行联通性测试，而后进行组织测试数据进行联调测试，保证在没有接入业务代码前，通过接口可以测试用例完全走通业务。
业务代码开发时，对外接口仅是接口，没有实现类，要使正常的代码逻辑向下进行，由此引入模拟层模块，为接口提供模拟数据，其实就是死代码，不管什么请求过来，都能响应。当然，如果想真是模拟接口返回数据，就需要模拟层加入一些判断，比如接口参数的合法性检验，针对不同参数做出不同的响应等等，事实证明，这两个举措是非常有必要的，起码在开发阶段就能消灭掉不少问题，而非等到真正接口联调时。
前端人员开发，为降低沟通协调成本，同样需要编写控制层代码，如SpringMVC的Controller编写，前端开发结束后，完全可以自己测试，只需要在模拟层编写简单的数据返回即可。等真正测试时，把模拟代码去掉直接换成Service层的代码。
这么做目的有几个：
1、页面请求调用后端时，后台开发不参与，由自己控制，沟通成本几乎没有。
2、基本的检验可以全部完成，页面端及请求转发前都是自己编写。
3、页面功能的开发，不受制于后台功能的进度，保证了自己的进度。
当然，这对前端开发而言，要求有些高，在这个项目里是有我们的后台开发转过来做的。现在不少的前端人员很多都只专注于js。
至此，可以看出，页面开发，前端开发，后台开发，接口开发，虽环环相扣，但进度上又相互独立。
Junit测试用例的编写是要求100%通过的，但有依赖的三方接口，成功率就比较难保证。引入mockit很好的解决了这个问题。即便是在接口不同的情况下也能模拟接口返回响应的数据，这在一些接口系统比较多的产品很是实用。
代码质量监控通过sonar来完成，当然还要结合CI工具jenkins每个构建周期内都生成代码质量报告。目前Jenkins在往CD的方向迈出了很坚实的一步，有兴趣的朋友可继续深入下。开发过程中，逻辑尚不完善处，或代码走查审核时，必须添加FIXME注释，以便下次快速定位。
由于多渠道多终端的存在，数据在实用过程中要多考虑时效性及准确性的问题，避免使用过时数据做业务，造成数据的不一致。基金的赎回就是一个很好的场景，一个终端打开赎回页面显示的数据，再真正提交前一定要做验证，毕竟在此工程中，其他终端也可以发生赎回操作。
关键业务防重处理，dubbo自身有对交易超时，自动重发几次的特点，在特殊的交易中此功能就是一个炸弹，这个地方需要是设置重发次数为0。常见的转账，下单，卖出，发货等业务场景都必须有防重机制，防止数据重复。在页面可通过js控制按钮的点击，后台也需要增加对重复请求的过滤，实现方式可通过Token形式或通过Request中增家检验位来实现。
