本文探讨了重构的五个W及一个H（Why, What, When, Who, Where, How），详细介绍了为何需要重构、重构的定义、何时进行重构、谁应该参与重构、在哪里重构以及如何重构等内容。
重构的5W1H（实践总结）
为什么需要重构（Why）：提高软件内部质量，了解系统。
1. 减少复杂度是唯一的判断标准。
2. 内部质量：程序员能够感受到的，比如：可维护、可读性、灵活行、可重用行、可测试性。
3. 比如可读性：准确说出你的意思，时刻记住代码被阅读和被修改的次数远远多余它被编写的次数。
什么是重构（What）：
1. 定义：在不改变代码行为的前提下，对代码做出修改，以改进程序的内部质量，降低修改成本。
2. 描述：重构是一种有纪律的、经过训练的、有条不紊的程序调整方法，可以将整理过程中不小心引入错误的几率降到最低。
什么时候重构（When）：
1. 开发阶段最好，成本最低。
2. 没有专门的时间重构，随时随地进行。
3. 事不过三，三则重构。
4. 在增加子程序时，关注其它子程序。
5. 添加类时，关注本类以及和其它类的关系。
6. 审查代码时，作者和审查员一起重构。
7. 修改bug时，是否有类似。
8. 关注高复杂、多bug模块。
9. 确保代码在离开你的时候比来之前更健康。
10. 当你感觉需要撰写注释时，请先尝试重构，试着让所有注释变得多余。
11. 定义清楚干净代码和拙劣代码的边界，然后尝试把代码移过这条边界。
12. 不合适的时候
A. 项目已近最后期限。
B. 代码根本不能正常运行：需要重写。
Who：
1. 作者
2. 其它开发人员
3. 作者和代码审查员
Where
随地
如何重构（How）：
1. 嗅到“代码臭味”
A. 不要为拙劣的代码编写注释。
B. 程序中的一些代码为将来的某个时间才用。
a) 需求不明确。
b) 画蛇添足，增加了程序的复杂度，额外的测试和修改bug，拖项目的后腿。
c) 只需要关注现在的东西，交流层次。
d) 为以后准备的最好方法就是让代码清晰直白的表现现在的需求。
C. 参考《重构－改善即有代码的设计》
2. 掌握大量重构方法：参考《重构－改善即有代码的设计》
3. 安全重构策略
A. 风险驱动：列出主要的风险，提出相应的策略，根据重构风险级别来调整重构方法。
a) 自掘坟墓：挖掘自己的代码，很快发现了一些值得修改的地方，于是你挖得更深。挖得愈深，找到的重构机会就越多……
b) 维护阶段和开发阶段的策略是不一样的
B. 重构工具
a) 讲究速度、安全、Undo。
b) 简单、机械、重复的劳动用工具做。
C. 同一时间只做一项重构，重构的步伐请小些。
D. 把要做的事请一条条列出来，保持重构思路连贯，列表最好不要太长。
E. 设定目标，途中设置一个停车场，把在未来需要重构的内容，需要画的图……列出来，继续原有的目标。
F. 检查对代码的修改，特别是1至5行的代码修改（程序员比较轻视比较小的修改，常常不验证），同时验证修改。
G. 结对编程，代码审查。注意多交谈自己的意图
H. 阅读代码，Double Check，少依赖编译器，编译器只能查处简单的问题，可以利用编译器的警告信息处理简单的错误。
I. 分而治之，先分大模块（定义好大模块的接口）。
J. 学习原路返回，途中阶段性结果的Check In，写明注释。
K. 没把握时就停下来：无法证明自己所做的一切能够保持程序原意时。
L. 没有单元测试，测试周期长，必须要对业务比较了解。在重构结束后，Step by Step，走完整个流程。
Others
1. 重构中记录下其它需要重构的内容。确保记录下的需要重构的内容在两周内去修改。
2. 理想状况下：只有在有新的需求时才有重构。当前的代码应该是最适应当前的需求。
3. 不要把重构当做先写后改的代名词。避免用重构代替重写。
4. 一个心态：用自己全部所学去改进它
参考书籍
《重构－改善即有代码的设计》
《代码大全 2》
扫一扫
1570
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
