一定要有一个有高度扩展性的基础框架

这是少有的经验，但是也是未完成的经验。

服务接口的通用性会很强，必须能容纳未来的、不可预见的需求。因此，它必须有高度的扩展性，否则，未来肯定会面临“艰难的选择”：要么框架重构，要么抛开框架去开发专用接口。

kepler这次的改造，写了一个扩展性还可以的业务框架。但是这个还不够。成熟的业务框架，除了扩展性之外，还应该简化开发工作。

基础框架未定型的情况下，不要发布上线版本

具体的说，这次10411分支上，用的是未定型的框架；而kepler-loan分支上，则是经过优化后的框架。

这导致了两个分支中的代码冲突太多，无法在同一天上线，因此推迟kepler-loan的上线时间。

服务端和客户端需要注意乐观锁问题

由于hibernate的乐观锁是利用version字段来做的，这导致了客户端、服务端同时对一个数据进行更新时，后完成更新的（一般是客户端）会抛出乐观锁异常。

具体业务尽量通过组合通用接口来完成，而不是开辟专用接口

客户端注意接收服务端数据时的类型转换

默认情况下，spring提供的RestfulTemplate会将服务端返回的json串解析为LinkedHashMap。如果需要将返回结果转换为其它类型，应当在调用RestfulTemplate时指定返回数据类型。

或者使用RestClientFactory（没错我就是来推销自己写的代码的），在调用时指定ResponseAs即可。例如这样：

RestfulResult result = this.restClientFactory
    .newClient()
    .setUrl(this.variables.getBizAccountRESTURL() + "bizAccountEvent/LOAN/")
    .addHeader(HttpHeaders.CONTENT_TYPE, MediaType.TEXT_HTML_VALUE)
    .setBody(JsonMapper.defaultMapper().toJson(requestBodyMap))
    .responseAs(RestfulResult.class)
    .post();

技术/开发人员主导的系统改造、优化，必须与产品、业务人员充分沟通

技术主导的改造、优化，会比较专注于后台的代码流程，而忽略/忽视业务人员操作的习惯等。因此，改造前、改造中必须有充分沟通。避免改造完成后，业务人员不接受改造结果的问题发生。

分布式服务调用一定要用重试/补发机制

无论同步还是异步，在主流程之外，一定要有针对异常的重试或补发机制。

灰度上线

对影响范围或者功能/性能风险较大的功能 ，做灰度上线。

如新、旧代码同时上线，以一定方式保证热切换。或者新旧代码同时运行，对两套代码的功能、性能等进行对比和监控，待新代码稳定后再全面切换。