摘要: 重构之于软件开发, 可谓一个绕不过理不清的梗.
整个软件开发的范围触及世间各行各业, 每时每刻都在变更的需求, 每分每秒都在改变的结构, 以不变应万变, 在软件行业, 既不对也对.
不对, 是指不可能一成不变的去应对.
对, 是指前人总结了很好的经验给到我们去学习, 应用; 这些经验表现形式万万千, 大体的流程不会有太大差异. 阅读全文
摘要: 测试对于软件开发的意义, 勿需再多言语阐述.
而在所有的测试当中, 单元测试的粒度是最小的, 是进入其他阶段测试的门槛.
以上的话语虽然可能有人看不惯, 但当有过不一样的体会后, 总会得出一些不一样的看法. 阅读全文
代码结构理清, 章程已经文档化, 工程环境已经规定好, 不着手工程开始干活, 简直对不起之前花费心血准备的种种.
首先, 由于提取出来的基类, 以源码的形式存在并导入到各个模块, 所以必须要将其实现导入到模块工程里面, 而对应的头文件可通过vs的环境配置包含进来, 所以需要增加一个base的筛选器:
其次, 上文提到的, 关于部分各个模块各个类都需要使用到的函数被抽取到一个对应的工具集函数里面, 并且也是以源码形式存在于各模块工程, 所以同样增加一个tutorial的筛选器:
接下来就是关键的模块工程:
一、二、三、四、五个类? 对比前文的规划后的类图, 不是少了interface这一块?
本系列第一章提到, interface的主要负责模块对外的接口, 重整之后, 将interface彻底跟模块的业务逻辑分离, 原本由interface全局变量串联其他四个类(module/ui/param/driver)的工作, 在之后将完全被mediator所接管.
所以, 这里可以体现出一点关于增加多一个mediator类的用途:
1.mediator则承担了原本由interface调度的业务逻辑, interface单纯只负责对外接口的处理, 可以将interface跟模块的业务逻辑完全解耦.
2.往后如有业务需求在整体架构不变的情况下, 业务主体逻辑可以整体移植过去, 主要修改对应的interface部分即可.
最终完整的工程配置如下:
其中"头文件""源文件"都是按照工程建立时可自动生成的, 后面主要将interface部分在这里处理一下即可.
其他模块所有的源文件和头文件都按照各自的定位分好类, 存在于各自的筛选器中.
这里面的基本思路是:按照不同的定位处理好对应的依赖关系, 在源文件更多的情况下, 这个分类很有必要.
最后总结一下, 调整后的工程配置的优缺点:
优点:
1.按照不同的定位区分
2.从代码与工程配置上都将业务逻辑主体跟接口分离
3.方便以后的移植
缺点:
1.相关文件路径的配置麻烦
2.总体工程的观感上比之前要有更多内容
配置上的麻烦是一时的, 主观上的感受是可以被改变的, 配置界限分清之后, 对后面增加的测试更有大大的方便.
未完待续...
摘要: 历经挣扎后, 愈感力不从心, 决定自己先尝试将整体工程搭建起来, 然后一个个边缘小模块的实现和导入, 并在这个过程中持续的优化考虑不周的地方.
首先是入手的地方是大量重复的代码, 对于这些代码, 唯一的一个途径就是复用. 复用的实现方式有两种: 一是继承, 而是函数库. 阅读全文
摘要: 重构的现状:源码工程历经五年, 前后经历五六次人员变更, 20+人次左右的交接; 其中有应届毕业生到老鸟到脱坑, 也有中途其他部门调整岗位过来的同事; 二十多个模块的变更, 在公司相关规范不完善的情况下, 烙印下太多特行独立甚至堪称粗暴的痕迹, 最终成为现在的是一团即将再也看不到缝隙的大泥球,
而我----身处中心. 阅读全文