整合内容分为以下部分：
一、重构原则+最近看ROR获得的一些新体会。
二、主要整合内容。（这部分比较乱，使用Ctrl+F查阅比较方便。
三、之前几章的项目分享。
这篇文章的使用方法除了Ctrl+F之外，还可以直接拉内容到百度，直接看别人整合的单条信息，相对更完整。
那么，开始吧。
一、重构原则+最近看ROR的一些原则。
为即将修改的代码建立一组可靠的测试环境。
临时变量助长冗长而复杂的函数。
最好不要再另一个对象的属性基础上运用switch语句。如果要switch也要在类自己的数据上使用。
事不过三，三则重构。
首先写出可调的程序，然后调整它以求获得足够速度。
一个好的名字可以省去读函数内容的操作。
每当需要注释说明时，可以被写进一个函数里，并以用途命名，关键不在函数长度，而在函数做什么，怎么做。
条件和循环也是提炼信号。
针对外界变化的所有相应修改，应该只发生在单一类中，这个类的所有内容随外界变化。
一个函数使用几个类的功能，它应该被放在最多被此函数使用的数据一起。
对于出现在不同类/方法内的一些绑在一起的数据，应该给它们设置对象。
少用switch，switch代表重复。
两个帽子原则：不要边写代码边重构，带上写代码的帽子，觉得需要重构了，再带上重构的帽子去做，如此反复。
注释多写为什么这样，过多注释不一定是好，尝试重构。
先编写测试代码可以将关注点放在接口而非实现。
每当出现一个BUG，先写一个测试单元测试BUG。不要修改以前的测试单元，因为它可能会在修复BUG后出错。
测试：异常，边界
测试太多带来的效益呈现递减态势。但是我们尽量测试大多数BUG。
小步前进，频繁测试。
即使想要提炼的函数非常简单，只要新函数名能更好地示意代码意图，也应该提炼它。
重构出来的函数优先使用private修饰，日后可以慢慢放开。
网友评论