代码重构能力体会总结



代码重构能力先面向对象设计、设计模式、框架子系统的学习应用，最后重构的落地实践。



一、面向对象设计体会





• 面向对象设计原则：开闭原则是根本和基石，依赖倒置原则、里氏代换原则、单一职责原则、接口隔离原则都服务开闭原则

• 软件涉及的业务领域比较广，设计的目的和原则都万变不离其中，设计的目的是高内聚、低耦合，面向对象设计原则服务面向对象设计的目的（高内聚、低耦合（易扩展、更强壮、可移植、更简单））， 抽象程度越高越稳定

• 学习面向对象设计重点还是在面向对象设计原则和面向对象设计目的的学习理解

• 对应业务需求的理解，需求产生的价值不确定性



二、设计模式

1.设计模式的定义

每一种模式都描述了一种问题的通用解决方案。这种问题在我们的环境中，不停地出现。

设计模式是一种可重复使用的解决方案。

一个设计模式的四个部分:

• 模式的名称一由少量的字组成的名称，有助于我们表达我们的设计。

• 待解问题一描述了何时需要运用这种模式，以及运用模式的环境(上下文)。

• 解决方案一描述了组成设计的元素(类和对象)、它们的关系、职责以及合作。但这种解决方案是抽象的，它不代表具体的实现。

• 结论一运用这种方案所带来的利和弊。主要是指它对系统的弹性、扩展性、和可移植性的影响。

2.设计模式的定义

从功能分

• 创建模式(Creational Patterns )：对类的实例化过程的抽象。

• 结构模式(Structural Patterns)：将类或者对象结合在一起形成更大的结构。

• 行为模式(Behavioral Patterns )：对在不同的对象之间划分责任和算法的抽象化。

从方式分

• 类模式：以继承的方式实现模式，静态的。

• 对象模式：以组合的方式实现模式，动态的。



3.设计模式

超声诊断系统测量子系统的模式设计ou

背景：超声医生通过测量菜单或触摸屏的选择定量分析的测量工具图元（直线、椭圆、角度、描迹、角度等），测量感兴区域的相关测量值并显示。



简单工厂模式：一个类来负责创建其他类的实例，被创建的实例通常都具有共同的父类

测量工具图元使用简单工厂创建

单例模式：单例模式保证产生单一实例，就是说一个类只产生一个实例

测量工具图元单独创建

模板模式：它是通过“继承”的方法来实现扩展，基类负责算法的轮廓和骨架，子类负责算法的具体实现

,必须带有模板方法

测量工具图元事件方法

策略模式：是扩展功能的另一种最基本的模式，它是通过“组合”的方法来实现扩展，系统需要在多种算法中选择一种

适配器模式：系统需要使用现有的类，而这个类的接口与我们所需要的不同

测量工具图元绘制机制可以采用不机制（QT、ＯＰＥＮＧL、SDL）去实现

测量外部参数接口进行转换适配

组合模式：是一种“对象的结构模式

测量菜单的树形组织

观察者模式：建立对象间一对多的关联关系，并能使一个对象的变化被所有关联对象感知

测量菜单或触摸屏的同步刷新显示

装饰者模式：在不改变对客户端的接口的前提下(对客户端透明)扩展现有对象的功能

不同测量工具图元绘制形状



三、框架学习思路

• 思路：采用分解的思路、对技术原理、技术细节的解剖

• 工具：采用ＵＭＬ静态和动态图：部署＼组件＼类＼时序＼状态图

• 过程：从一个基础的使用者到一个高级开拓者



四、重构经历

2013年初团队开始接手一个超声诊断系统，该系统从2002年开始开发，经历3个平台的机型的迭代，代码总结50多万，接手是代码和设计上存在的问题和现象

1）代码严重耦合：一个代码文件2万行，一大堆逻辑判断，界面和逻辑严重耦合、全局变量满天飞

2）设计思路：使用C++的过程编程，逻辑状态控制采用硬件TAG思维，使用OPENGL加队列的方式来实现GUI和图像的绘制，没有GUI的层

3）该系统支持6款机型，存在大量的编译宏

4）修改代码导致线程安全的问题频繁出现，导致客户出现偶发问题



1. 重构过程

系统重构里程碑见下：





1）熟悉系统 2013年

梳理系统的目录结构和编译运行文档：让组员可以正常去调试和熟悉代码，改一些bug进行练手加强代码的熟悉

熟悉OPENGL加队列绘制和事件响应机制、线程结构和关键功能实现（前端控制、成像模式、存储回调），并输出文档:让组员熟悉系统架构和相关约束

2）开发小的功能和模块代码拆分 2013年

采用新建目录物理上隔离填加新的功能

3）大模块的替换 2013年7月-2017年7月

使用公司内部已有超声系统的模块进行替换，采用前期方案验证，再进行集成开发和发布版本的方式

患者DICOM和系统设置 （2013年7月-2014年7月）

内存不足机制的替换（2014年7月-2014年9月）

测量和报告（2013年12月- 2014年12月）

自动化测试框架引入（加强软件质量提升和过程中问题及时解决）

4）编译宏处理和AO模型、状态机引入、主界面重构、新功能开发（2015年1月-2017年6月）

AO模型解决部分线程安全问题

状态机进一步合理拆分子模块和状态

主界面重构：主界面控件进行封装解决一些刷新的问题

5）新的平台软件基础架构的引入全面适配替换（2017年7月-2018年12月）

主要考虑前端和成像方案不变，软件采用将前端和成像方案适配的新的方案中，开发对比工具同时保证两套方案能运行进行对比验证



1. 重构体会和总结

1）系统业务和架构的熟悉，并输出文档进行交流，这样便于加深系统的理解熟悉

2）从BUG、小功能、模块循序渐进的实战，提供团队的实战能力和信心

3）熟悉和有实战之后，采用工具、框架、子系统进行逐步替换

（采用前期方案验证，再进行集成开发和发布版本的方式，这样保证版本发布的技术和进度风险）

4）自动化测试为重构和开发过程中的基本路径正常提供保障

5）框架相关约束尽量考虑在框架机制中，提供傻瓜式框架给开发人员，避免开发人员的犯错机会