[attach]5545[/attach]
[attach]5546[/attach]
上面是 CKCR 的基础功能。后来在应用中发现，在系统各个场景下，系统核心数据输出的数据结构大部分是一样的。因此，CKCR 描述串的复用性就成为了一个问题。
为了解决这个问题，nice 在 CKCR 编译之前，引入了预处理的机制。可以通过特殊的语法，引用固定的数据结构描述。这个机制引入之后，带来了一个附加的好处，即沉淀系统的核心数据结构。
[attach]5547[/attach]
客户端/服务端协作问题，技术层面 nice 通过这个组件解决。那么，人的协作问题怎么解决?
首先，CKCR 的描述规则是简明的。所以，它可以直接作为接口文档输出。
其次，在接口文档的基础上，nice 服务端和客户端 RD 之间的协作，流程上有一个明确的方案。
定协议：双方 RD 沟通，约定接口协议并提供文档，双方各自进入设计阶段。
假数据：服务端 RD 快速提供 Mock 数据的伪接口，供客户端 RD 基础功能自测使用。
真接口：服务端 RD 提供真实接口，双方联调。
这样分步的开发方式，基本就解决掉了”联调靠喊”的问题。双方的工作基本解耦，并且也基本不影响双方的开发进度。
CKCR 开源地址
CKCR 这个组件的源代码，已经摘出来放在 github 上了，网址为：http://t.cn/RGn57Xk。
第一阶段总结
上面这些就是 nice 应对第一阶段 3 个问题的方案：
分层和模块化：通过两层架构，解决掉结构性问题。
客户端适配器：解决掉客户端差异的问题。
CKCR：通过 CKCR 及协作流程，解决掉客户端/服务端 RD 协作的问题。
这个阶段，主要通过整体的重构，解决掉开发的问题，同时为未来的架构调整铺平路。
当时的做法是”推倒重来”，现在回顾，这种选择就当时的情况来说是正确的。在那个时间前后，我们没重构系统所遗留的问题，在系统变得更加庞大之后，变得更加棘手。
不过，话说回来，
“推倒重来”的重构之路，毕竟还是充满了各种风险的，做这样的决定前，一定要做好充分的资源和风险评估。