重构 改善既有代码的设计（读书笔记1）

 // 复制，粘贴给程序带来维护上的巨大挑战，一段相同的代码，绝对不应该出现在不同的两个地方。当然，你可以这样做，但是这种代码一旦出现问题，你会记得要修改几个地方吗？

 

 // 如果你发现自己需要为程序添加一个特性，而代码结构使你无法很方便地达成目的，那就先重构那个程序，使特性的添加比较容易进行，然后再添加特性。千万不要说有时间再做重构，有时间再做等于永远不会做（可以自己分析一下，首先，公司明面上给你的时间你都需要敲代码，而一旦代码敲完{就是所谓的‘有时间’}，估计就是验收的时候了，这个时候，你敢改动任何东西吗？）。

 

 // 重构之前，首先检查自己是否有一套可靠的测试机制，这些测试必须有自我检查能力，防止回归测试。

 

 // 重构，必须是微小步骤的进行，这样有利于发现引入的BUG。

 

 // 任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类理解的代码，才是优秀的程序员。

 

 // 有时候，项目初期对一个对象的职责认识的不清楚，换句话说，就是把方法写在了不该写的地方，这个时候，有一个规则可以帮助我们：方法应该放在它使用的数据的所属对象内。

 

// 使用查询代替临时变量，肯定会一定程度上降低性能，但是如果这种降低性能在可以接受的范围内，那么，减少临时变量的好处就呈现出来（个人认为谨慎使用）。

 

 // 对于任何可以立即查询到的东西，我都不会去记忆它，因为我怕它填满了我的大脑。

 

// 我不是一个伟大的程序员，我只是一个有着优良习惯的程序员。

 

 // 不应该抽出专门的时间来进行重构，重构只是为了后面更好的添加新东西，重构是应该随时随地进行的。

 

 // 一个比较好的准则：当我第一次做一件事情的时候，只管去做。第二次做类似的事情，我会反感，但是还是可以去做。第三次，则直接重构。

 

// 重构的三个切入点：添加功能时重构，修补bug时重构，代码审查时。

 

// 重构进行的越早越好，到了项目后期，是不应该进行重构的。

 

 // 当出现系统级别的问题时，比如CPU消耗很高，内存占用很严重等，这个时候一定不要去意淫问题，而是借助于工具去定位问题，然后解决问题。

 

 

 

 // 具体重构小知识点：
 // 1.对一段代码重构，希望抽成一个方法，那么代码中的局部变量如果在重构代码中没有修改，则可以通过参数传入方法。
 // 2.重构一个方法的时候，可能修改会引起调用者的修改，这时，提供一个新的方法，让旧的方法调用新方法是一个可行的方案。