【代码重构（Refectoring）系列教程 基本概念二】何时应该重构？如何去重构？

何时去重构

  三步原则

  当你第一次开发某个模块时，你只是将它完成了。
  当你第二次开发某个相似的内容时，尽管你对重复感到厌烦，但你还是要去做相同的工作。
  当你第三次开始做这件事时，你就应该开始重构了。

  何时应该新增一个功能

  代码重构可以帮助你更好得理解其它人的代码。如果你要与其它人的“脏代码”打交道，你应该首先将它重构。干净的代码更容易被理解。不光为了你，也为了今后要是使用这块代码的人，你都应该对这块代码进行重构。
  重构使得添加新的功能变得更容易。在干净的代码上做修改会容易很多。

  在你修复一个bug时

  代码中的bugs就像那些现实生活中住在最黑暗，最肮脏的人一样，他们处在代码中最糟糕的部分。理论上，在使代码变干净的过程中这些bugs也会自己浮现出来。
  管理者会欣赏那些主动去进行代码重构的人，因为这省去了今后为代码重构分配专门的工作的步骤。一个开心的老板也会让程序开发人员更加开心！（养成这个良好的习惯，会让你的boss更加欣赏你～，那么你的绩效自然也会更不错😋）

  在代码评审的过程中

  代码重构可能是在代码发布之前最后一次对代码进行整理的机会。
  在代码评审的过程中，最好要叫上一个代码的创作者。这样你们修复一个简单的问题会更快，并且可以估计修复复杂问题所需要的时间。

如何重构

  代码重构由一系列小的改动完成，每一个这些小的改动都应该在保持原来程序正常运行的基础上使代码变得更好一点。
  

迅速开始代码重构

  代码应该变得更干净
  如果在你重构以后，代码仍然不干净。好吧，很抱歉地说，你浪费了你人生中的一个小时。我们来搞清楚为什么这种事情会发生。
  这种情况经常发生在你没有通过一个个细小的改动来完成重构，而是将它们混在一起，做了一个大的改动。这种情况下你很容易变得发狂，特别是在你的时间很紧迫的情况下。
  这种情况也会发生在当你重构非常臃肿的代码的时候,不论你如何重构，这块代码总是看上去像一场灾难。
  这种情况下，你应该考虑完全重写代码的某一部分。但是在这之前，你应该准备好测试用例，并且预留出足够多的时间。否则，代码最终会变成我们在第一自然段说的这种情况。

  代码重构的过程不应该产生新的功能
  不要将新功能的开发和代码重构混成一滩。尝试着分离这些过程，至少在个人提交记录中要将他们分离。

  代码重构后所有现成的测试用例仍应通过
  有两种情况，重构后的代码将会通过不了测试用例。
  ●重构的过程中引入了新的错误：这种情况很无脑：继续重构并且修复这个错误即可。
  ●测试用例过于低级：比如，对类的私有方法进行测试。
  这种情况下，责任应该归咎于测试用例。你应该要么重构这些测试用例，或者重新写一套新的，高水平测试用例。符合BDD-Style（Behavior-Driven Develoment)的测试用例可以很好的避免这一种情况的发生。