看出笔记-第二章-重构原则

调整代码结构，使其简单易懂，易于维护与拓展。

目的

使代码更易于理解和修改，并且，对外应该是透明的。即重构了代码，系统对外的服务是不应该有所改变的。另外，性能优化也会改变代码。但是性能优化通常是针对函数的，即修改某一函数代码，使之执行时间缩短、结果不变。

原则

在软件开发过程中，应该只存在两种行为，添加新功能和重构。即任何对代码的修改都应该是一个重构的过程。当然，那种一两行代码bug修改的除外。这或许就是一种开闭原则。另外，不要一边重构，一边添加新功能。

作用

1、改进软件设计
在开发过程中，为了快速完成任务。copy通常是最简单有效的方式，甚至我根本就不需要理解这个段代码的具体操作是如何做的，只要执行结果是我想要的，那么我就copy过来用。当有问题时，我再debug调试修改。这导致系统代码愈加臃肿不堪且结构混乱、难于理解。维护难度增大。拓展困难，难以看出代码意图和设计。
2、使软件更容易理解
代码不单是给机器执行的，也是给人看的。总会有人需要阅读并理解你的代码，从而进行修改维护。易于理解的代码不仅易于拓展跟维护，还可以清晰框架结构。加深对系统的理解。
3、帮助找到bug
易于理解的代码，可以便于定位bug出现的位置。代码被重构为多个细小的组件后，相应的，查找bug的范围也会减小。
4、提高编程速度
重构可以提高质量。改善设计、提升可读性、减少错误、在项目后期的维护阶段，不论添加新功能还是修复系统漏洞都会相对简单不少。

何时重构

1、添加功能时重构
工欲善其事必先利其器，要想添加新功能，必须要先理解现有的代码。如果代码混乱，难以理解，那就重构它吧。因为这玩意估计除了写出来的人懂之外，其他人都会看懵逼。
如果现在的代码设计难以满足新功能的添加，那就重构吧。随着你每天的进步，重构出来的代码也会比之前的好，或许以前没有发现的瑕疵也能在重构中得到弥补。没有什么事情是重构不能解决的，如果重构一次不行，那就重构两次三次。

2、修补错误时
如果收到一份错误报告，这就是需要重构的信号。因为显然代码还还不够清晰，没有清晰到能让你一眼看出bug。没什么会有bug？因为你写得代码自己不了解，你自己都没彻底了解的东西，还指望别人能理解吗。所以，重构吧，骚年。

3、复审代码
复审是一个取他人之长不自己之短的过程。一个人的想法终究是有限的，三个臭皮匠，胜过诸葛亮。如果你写得代码别人看不懂，那么重构是必须的。复审也是个知识传播的过程，看看别人的代码，在对比自己写的代码。暗中比较，自我反省。重构重构重构。

何时不重构

代码错误百出，改好这里，那里又有问题。这种时候不应该重构，而是重写。删掉它，重新编写比重构来的轻松。

重构与设计

重构可以简化设计，在开发过程中，可以通过不断的重构来完善设计。灵活的设计会使系统变得复杂，设计也可能会有遗漏，所以做一个简单的设计，简化系统，然后通过重构不断完善它，从而提高产出、降低需求变更带来的风险等。

性能

重构或许会降低系统性能，但是在优化阶段，重构后的代码更容易调整。代码被重构为多个小部件，在性能优化时，往往可以花较少的力气得到较大的收货。