背景介绍
最近在团队工作中花了不少心思主导建设了测试平台，前期的建设思路是能用就行，随着建设的深入，逐渐需要学习下代码架构设计方面的内容了。于是参加了公司组织的代码重构与模式的培训，通过培训，感觉收获颇丰，故有此文，上一篇是从代码设计原则角度出发内容的总结，本篇是从重构的技术细节出发，进行的总结。
从名字开始规范
避免使用泛泛的名字
例如temp,foo,i,var等，尽量替换成含义相对明确的变
例如下面这段代码，你能想到上面retval是什么吗？是：return value
如果替换成这样的，阅读起来就更加清晰一些
在循环中，i，可以加上循环的前缀来命名
for (int i = 0; i < clubs.size(); i++)for (int j = 0; j < clubs[i].members.size(); j++)for (int k = 0; k < users.size(); k++)if (clubs[i].members[k] == users[j])cout << "user[" << j << "] is in club[" << i << "]" << endl;if (clubs[ci].members[ui] == users[mi]) // Bugif (clubs[ci].members[mi] == users[ui]) // Ok为名字附带更多的信息
例如：时间的命名，带上单位；加上形容词等方式。
Start(int delay) #这个延时是秒还是毫秒？Start(int delay_ms) #毫秒延时，很清晰 
避免让人误解的名称
- 例如：Filter的含义。传参：addr="郑州"，是要郑州的还是不要郑州的？
- 例如：start-end，可以换成first,last，可以清晰边界
- 例如给布尔值命名：
- bool read_password = True 这种含义不清，可以加上is can has should等
- 避免使用否定词：例如bool disable_ssl =False
提升代码的可读性
按照杂志的思想组织，而不是报纸的思路组织。
杂志有目录，整体有结构，从哪里开始都可以
提取公共部分
例如下面的修改：
修改前：
修改后：
用函数来整理不规则的代码
修改前：
修改后
把声明按块组织
修改前
修改后：分块添加注释
使用自描述代码替代大量注释
修改前
修改后
关于注释
- 好代码 > 坏代码 + 好注释
- 避免喃喃式注释。
- 注释尽量写背景信息，也就是为什么要有这个。
什么情况下写注释
给常量添加注释
EG：NUM_THREADS = 8 # 只要 >= 2 * num_processors, 就足够了.
给意料之中的提问加注释
// 只有与空vector交换才能真正回收内存
公布可能的陷阱
让注释保持紧凑
可以适当的使用一些符号，不必是纯文字表达。
修改前
修改后
正如下图
优化 条件判断与循环
先处理正向逻辑
反例：
调整为：
只在简单的条件下使用三目运算符
避免使用do……while
通过提前返回减少嵌套
例如：
修改为
较少循环内嵌套
拆分复杂表达式
用解释变量简化表达式
把超长表达式拆分成更容易理解的小块
不要滥用短路逻辑
换个表达的角度
例如：判断重叠的逻辑
正向逻辑的表达：太复杂
反向分析：
通过查表简化逻辑
如何写一个好的Unit Test
提取为统一函数
修改前：
修改后：
写在最后
这部分总结是将代码重构细节操作的角度进行了总结，里面有不少例子，看了就能懂，拿来就能用，对于我这种经验不足的人来说，刚刚好。因此这次培训也算是打开了我进行代码重构、代码架构设计的一扇窗，希望之后能继续深入学习、实践！
