《重构改善既有代码的设计》-重构原则(学习笔记)

       其实你的代码也可以如此简洁与优美，请试着做一次重构，强迫其完美。你会学到更多未曾发现的

       重构（refactoring）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。 在不该变代码外在行为的前提下，对代码做出修改。以改进程序的内部结构。重构是一种经千锤百炼成的有条不紊的程序整理方法，可以最大限度地减少整理过程中引入错误的几率。本质上说，重构就是在代码写好后改进它的设计。摘自《重构改善既有代码的设计》

            为何重构

1、重构改进软件设计。

重构与设计是相辅相成的，一直相互伴随。当代码混乱不看杂乱无章时，贸然改进软件的设计。则是诸多问题，如：牵一发动全身，修改原代码、增加新功能以及测试都没有可靠性。

2、重构使软件容易理解。

大多数的代码是给人看的，不是给机器。机器不需要我们为它翻译什么。当自己写的函数有数百行甚至数千行的时候，还在天天把XX设计模式XX架构挂在嘴边，要XX改进云云等。这些现实吗？开发人员都无法理解的代码怎么能改进？怎么能易于修改？

3、重构帮助找到bug。

重构如何帮助找到bug呢？重构其实是整理代码的一个过程，当把一个数千行或者数百行的函数，分解成数十个简洁，功能单一的函数时，你会发现每个代码都只有寥寥数行，那么写数行代码出错了好排查还是，从数千行代码中找错误更容易呢？（代码整洁往往是伴随着整个重构过程）

4、重构提高编程速度。

重构有助于保持和提高代码的简洁和整洁性，易于修改和添加新功能。

经常有开发人员抱怨，程序的架构或者代码有多么的混乱不堪。没有注释没有文档，不知其功能。面对糟糕的代码无从下手。bug横飞，天天被无休止的bug及糟糕的代码所纠缠，深陷泥潭。但是这些坑都是谁挖的，想必大家一定很清楚，拍屁股走人的前开发人员，周边的同事，或者自己。想从搬砖的状态中解脱出来，那么请重构自己的代码。

何时重构

1、添加功能时重构

如果重构会使旧代码结构清晰，更易理解。那么请重构。无法轻松的添加新功能时请重构。重构后更易添加新功能。

2、修补错误时重构

如果bug难以排查和发现那么请重构，易于发现bug和理解代码。（往往bug难以发现是因为代码不够清晰）

3、复审代码时重构

复审时一般会有诸多好的建议，更贴合实际，多数是解决当前bug或者结构不清晰。

何时不该重构

1、时效性来说，当既有的代码实在太混乱，重构它远不如重新写一个来更简单和快捷，那么请放弃重构。（往往又成为许多开发人员的借口，这么混乱的代码还不如重写，不愿意去重构。）

2、项目接近最后期限，请放弃重构。（往往应该早就进行重构，重构是一直伴随在开发过程中的。发现“坏代码”时就应该重构）

3、现有代码根本不能正常工作。那么请放弃重构。重构之前代码必须在大部分情况下能够正常工作。

           重构与设计相互补充，设计不可能尽善尽美，重构亦是如此。