《重构-改善既有代码的设计》总结

一个好的研发工程师，不仅要懂得写代码，而且要懂得写好的代码，更要有产品思维和测试思维。——佚名

一、前言
1 什么是好的代码？

	代码块长度适中
	代码逻辑清晰
	函数名称语义化
	变量名称语义化
	...
	以上都是好的代码应该具备的特征！

2 NIH综合征
开发过程中都会遇到不好的代码，其实也不是不好，只是限于当时的环境无法做到更好，如果在遇到不好的代码，一直抱怨而不进行重构，就擅自编写自己的一套代码，那么，你可能患有NIH（not invented here，非我所创）综合征。具体可参考文章【NIH综合征】。

在研发过程中尽量克服这种思维模式，要明白在限定的环境中，存在即合理，如果现在看不合理，那就重构吧，从我做起，让它达到你认为的合理状态。

3 为什么写重构
写这篇文章，是在看了《重构-改善既有代码的设计》一书，写了3年的代码，虽然有一定的洁癖，但是读了该书以后，感觉书中很多的方法在实际工作中都用到，理论与实践，加深了对重构的理解。

二、重构
1 什么是重构
对软件内部结构的调整，目的是在不改变软件外在可观察行为的前提下，提高代码可读性、可扩展性、性能、降低软件维护成本等，重构是语言无关的。

2 为什么重构
改进软件设计
对代码更好的理解
改善软件可扩展性
降低后期维护成本

3 何时重构
重构没有具体的时间节点，它贯穿在整个项目研发周期中，比如事不过三、三则重构，当新增功能不容易或易产生副作用时，就需要进行重构。

4 哪里需要重构

1 变量名、函数名、类名命名语义化
2 函数参数列表太长，不利于测试和理解
3 变量重复定义和重复使用
4 代码重复
5 继承层级关系、属性、方法归属不明确
6 不合理的代码组织方式（类太大、方法体太大、自上而下的执行等）
7 过度设计（比如设计模式为了使用而使用）
8 难以理解的复杂判断条件
9 为了注释而注释
10 遗留的注释代码
11 过多强调扩展性
...

以上需要重构的地方，进行重构，就能总结出对应的重构方法，在实践中理解对应的方法是最有意义的，否则单纯的理论，并不能有很大的提升，本文所讲为基础重构，关于大型重构请参考相关书籍。

参考文档
《重构-改善既有代码的设计》
《大话设计模式》