历经挣扎后, 愈感力不从心, 决定自己先尝试将整体工程搭建起来, 然后一个个边缘小模块的实现和导入, 并在这个过程中持续的优化考虑不周的地方.
首先是入手的地方是大量重复的代码, 对于这些代码, 唯一的一个途径就是复用. 复用的实现方式有两种: 一是继承, 而是函数库.
这里大部分的代码复用选择了继承, 有两个原因: 一是各大模块都需要使用到这些处理; 二是部分实现不同模块有少许不一致, 需要在子类进行差异化.
同时还有一小部分代码由于在前文提到的五个类都需要使用到, 所以单独为这部分代码增加了一个工具集的文件.
基本上规划中的结构如下:
其中除了mediator这个类, 其他类跟之前基本保持一致, 之前的类图:
规划前的类图是不是也很简单清晰明了?是的, 但类图并不能真实反映出现在代码的实现状况, 现在基本上算得上是四个类通过接口类那个全局参数达成了两两耦合的境界:
现在修改其, 基本上是牵一而动全身, 说不准还破坏了原本兼容的版本, 可怕的是这个事, 十有八九会发生 : )
同时说明增加mediator是为了兼容另一个即将参与进去的平台而设计, 现阶段设计阶段是很有好处的, 实际状况由于还未开展所以还不知是好是坏 ┑(￣Д ￣)┍
当然, 除了上述代码层面上用代码以及工具集的方式将大部分函数复用, 但是实际上的编写代码上, 必须要有章程可依, 才不会重蹈覆辙, 毕竟以前五个类都能乱成一团, 现在多了一个mediator, 说不准还能乱出窗花的样式. 所以, 同时还编制了相关的一些代码风格规范(基于Google c++ style), git 提交规范, 注释规范, 工程建立流程, 编辑环境配置, 工程目录说明等文档:
上到联合国条例/国家的法律法规, 下到部分约定成俗的管理, 所有的条条框框规规矩矩的执行, 都必须有监督部门, 所以, 除了上述的规范章程, 同时还强制增加了一个前文提到的欠缺的过程----code review. 同时由于代码风格规范是基于Google c++ style, 所以可以使用其配套的工具cpplint进行风格上的检测, review的时候主要关注代码质量与逻辑实现.
在此过程中, 同时发现以前的模块工程很不统一, 虽然文件不离那几个类, 但却有可能有不同的目录配置, 所以同时将模块的工程目录都整合在一个相同的大环境下, 配合上述的代码提升抽象的层级(基类-子类), 所以同时整理了模块的工程目录, 工程目录同时也记录进文档, 进行规范化:
以上目录的命名, 基本上见名知义, 就不一一解析了.
到此, 基本上将整个重构的规划, 都大致捋了一遍:
1.代码层级上的复用选择
2.规范章程的文档化(含代码风格/提交风格/标准流程等)
3.工程目录与环境的一致性
4.很有必要的codereview过程
其中第一点主要是模块基础结构方面, 第二点是章程的标准, 第四点是工作环境方面, 最后是需要更多人相互合作才能完成并体现出效果的代码审核制度.
表达能力有限, 篇幅短小, 同时如有其它建议或者考虑不全的地方, 欢迎提出交流.
未完待续...