9月份，代码方面的收获，就是在一次与同事的沟通中，偶然发现了做代码review的必要性和好处，
就是把项目团队召集在一块，每次由一位开发者就自己开发的内容，结合业务需求和详细设计，讲解自己的代码实现，
在大家共同的沟通讨论中，摸清楚具体的需求和代码的脉络，同时，又可以纠正一些实现的缺陷，的确是一种很好的项目管理方式。
把关键模块的代码都过一遍，做到遇到问题会查，会改，会基于目前的代码做新的优化。
具体地：
阅读了网贷五级分类的实现代码，相较于sql直接操作数据库的方式，使用java程序来做是相对麻烦的。
另跟同事沟通交流，加深了对以下几块内容的理解：
redis缓存：OB是内存数据库，为什么还要用缓存？
OB一般与应用部署在不同的机器上，而且对OB的访问要通过数据访问代理，这样会有网络和经过数据访问代理的时间开销，
这与访问本机的缓存的时间属于不同的量级。
分布式事务：互金核心为什么用到分布式事务，哪些交易属于分布式事务的范畴？
分布式事务，首先属于事务，在分布式应用的环境下，成为分布式事务，如核心的存款、贷款、转账、清算等交易，都属于
分布式事务的范畴。
互金核心的模块划分及其职责：
核心系统的交易与核算是分离的，资产交换中心类似于BIP的角色，做交易组合。
像贷款交易，会涉及到贷款系统与内部账系统的交易事件登记簿处理。
日终时，核算系统负责抽取各个交易系统的登记簿流水，根据与会计分录的映射规则，将白天的交易处理成会计账，并保证账平。
服务化：
服务是面向服务架构中的基本逻辑单元，面向服务是构建在面向对象基础之上，以IT企业战略角度来完善"逻辑单元"的重用性。
单元化：
阿里的架构中数据的分片交由数据访问代理完成，涉及到应用的sql改造，
在腾讯的终极架构中，在用户流量的访问入口，就将其分配到特定的DCN单元上进行处理，数据库不再做分片，sql无需做改造，
其余的好处还有：
1）数据库对外的表现不再是逻辑上的一个整体，而是独立切分的单元
2）应用的部署，每个单元都部署全套的应用，可以做到物理隔离
3）阿里的架构中，应用可以访问所有的数据，而腾讯的架构中，通过可能的少量应用资源浪费，做到应用仅可直接访问自身单元内的数据。
4）各个单元相互独立，每个单元的变更，如资源扩充等不会对其他单元造成影响，而阿里的架构中，只能做到对整个实例扩容。
5）系统应用的划分，应当从服务化的角度入手，而不是从系统模块切分的角度入手做分布式改造。