版权声明：欢迎转载，共同进步。请注明出处：http://blog.csdn.net/puppet_master https://blog.csdn.net/puppet_master/article/details/76356049
1.重复是一切邪恶的根源，许多原则与设计规则都是为了避免重复而产生的。如面向对象编程的基类，面向组件编程等等。
2.添加有意义的语境，对于命名，起一个比较容易检查的命名。比如都在一个工程里面，就没有必要为所有类增加一个相同的前缀了，否则当你搜索的时候，所有的东西就都会出来了。。。。
3.函数应该只做一件事，做好这件事，只做这一件事。而且要尽可能短小，让人一眼能从函数名字看出这个函数要干什么。
4.对于代码结构，最好是一个自顶向下的规则，方便我们阅读代码。比如上面依赖下面，先看上面，看完后向下依次看依赖项。A函数调用B函数，B函数调用C函数，那么最好的顺序就是ABC，而且距离最好不要太远，否则当我们看的时候就需要跳来跳去。如果两个函数是概念相关的，那更应该放在一起。
5.尽量避免多参数的函数，最好是两个以下。除非有足够的理由，才用3个以上参数的函数。
6.标识参数会让函数丑陋不堪，为true的时候做A，false的时候做B，相当于宣布了这个函数做两件事。
7.函数要么做什么事，要么回答什么事，二者不可兼得。一般是set设置某些状态，get或is返回某些状态。
8.并不是一开始就能写出短小精悍的函数，一开始函数都是比较冗长复杂的，需要打磨这些代码，让其逐渐整洁。
9.别给糟糕的代码加注释，重新写吧！如果代码本身有足够的表达力，那根本不需要注释。注释是弥补我们不能用代码表达我们意图的补救手段。
10.好的注释：文件头法律信息，提供信息的注释，对意图的解释，某些无法修改库文件等的返回值或参数的解释，警示，TODO注释
11.坏注释：喃喃自语，无用的注释（读注释比代码时间还长），误导性注释，日志式注释（文件开头的修改日志，有svn了，貌似不需要了），大括号后面标注括号的注释（说明函数太长），注释掉的代码（有svn）
12.过程式代码便于在不改动既有数据结构的前提下增加新函数；面向对象代码便于在不改动现有函数的情况下增加新的类。
13.得墨忒耳律：模块不应该了解他所操作内部对象的结构。比如a->b.c += d应该把b.c+d风风装到b的一个方法e，直接调用a->e就好了。
14.错误处理很重要，但是如果它搞乱了代码逻辑，就是错误的做法。
15.特例模式：创建一个类或配置一个对象，用来处理特例，将异常处理封装到特例对象中，客户端代码就不需要进行异常处理了。
16.尽量不要返回null值，也尽量不要把null作为参数传递给函数。
17.边界：当我们拿到一个库时，我们可以进行一定的封装，不直接使用库内函数，而是调用自己的接口，这样在库更新时非常容易替换。我们只需要把库当成一个黑盒子。
18.测试：F（快速），I（独立），R（可重复），S（自足验证），T（及时）
19.类要尽可能短小，如果名字不好起或者不能很好地用一句话说明这个类是干什么的，那就说明这个类可能有些大了。单一职责原则
20.依赖倒置原则：类应当依赖于抽象而不是具体实现。
21.将构造和使用分开，可以初始化在main中进行构造，也可以使用工厂。
22.无论是在设计系统还是单独的模块，别忘了使用大概可工作的最简单方案。
23.简单设计的四条原则（总要度递减）：运行所有测试；不可重复；表达程序员的意图；尽可能减少类和方法的数量。
24.优秀的软件设计大都关乎分隔-创建合适的空间放置不同种类的代码，对关注面的分隔让代码更容易理解和维护。
25.代码在我们离开时要比来时更整洁。
26.一些需要重构的内容：
1）注释：不恰当的信息，废弃注释，废弃代码，冗余注释
2）环境：尽可能容易构建，尽可能容易测试
3）函数：过多参数，输出参数，标识参数（选择算子参数），死函数
4）明显的行为未被实现：类名或者函数名应当符合知觉，否则就需要使用的人详细读代码细节。
5）注意不正确的边界行为：不要依赖知觉，需要对各种边界条件进行判断处理。
6）注意警告：不要忽视这些告诉我们可能存在隐患的忠言。
7）注意重复：有重复说明我们遗漏了抽象；重复是万恶之源。
8）基类不要依赖于派生类：基类要对派生类一无所知。
9）删除死代码：根本不可能执行的代码不要留情面。对于没用的注释，变量，统统干掉。
10）垂直分隔：变量和函数使用和定义尽量不要太远，私有函数最好在首次使用它的函数下面定义。
11）注意前后一致：一些命名，使用等统一用一套规则，利于阅读和修改。
12）不要人为耦合：比如一些外部的enum，放到类中，就无形造成了其他类和该类耦合。
13）特性依恋：类的方法尽量只对勒种的变量和函数感兴趣，不要垂青其他类中的变量和函数。（只能说是尽量吧）
14）不要太晦涩：有可能我们写得很专业，但是给看得人需要花很久才能理解。
15）斟酌变量或内容的位置：遵循最小惊异原则，放在最符合人类知觉的地方。
16）注意静态方法：如果静态方法有多重表现，是否考虑是不是需要有多态，改为非静态实现。
17）使用解释性变量：让程序可读的最有效方法之一就是将计算过程使用的中间值全都改成有意义的命名。
18）函数名称表达其行为：如果必须查询函数实现或者文档才能弄明白函数是干什么的，就说明函数应该改个名字了。
19）理解算法：在真正完成函数之前，我们必须理解这个函数是怎么工作的，而且还要验证这种解决方案是否正确。
20）逻辑依赖改为物理依赖：原始数据和业务逻辑的依赖关系最好改为函数方法和业务逻辑之间的依赖关系。
21）用多态替代if/else或switch/case：优先考虑多态实现。
22）团队开发尽量使用同一套规则。
23）用命名常量代替魔术：一些数字最好使用命名常量来代替，否则难以修改与理解。
24）准确：消除代码中含糊和不准确的内容，明确自己为什么这么做。
25）结构基于约定：基类强制派生类实现抽象方法会比switch更加让人遵守这个约定。
26）封装条件：一些if语句进行判断，但是不好理解，可以直接将这个判断条件写成一个函数，判断时使用这个函数，方便理解。
27）避免否定条件：使用！判断没有肯定判断直白。
28）函数只做一件事。
29）掩蔽时序耦合：有些需要按照顺序初始化的，可以按照上一个作为下一个的输入。防止其他人误用。
30）别随意：结构太随意或者位置太随意可能会让人误用。
31）封装边界条件：把处理边界条件的代码集中到一处，比如+1，-1等。
32）得墨忒定律：编写害羞的代码，只让其直接协作者了解内部。不要暴露给再上层。
33）不要继承常量：把常量放在继承树最顶层并不是个好选择。不如静态导入。
34）名称作用域越大，名称就应该越长，越准确。
35）避免编码：现代编程环境不是很需要m_，f_等前缀。
36）名称说明副作用：比如获得一个物体，不存在就创建，用GetOrCreate就比Get容易理解。