gaming & coding

处理继承关系函数上移顾名思义，将子类逻辑重复的函数，移动到父类里。字段上移也是顾名思义的，要注意新字段需要对所有子类可见。构造函数本体上移将子类构造函数共有的行为上移至超类。需要考虑到超类和子类的构造函数调用顺序。函数下移如果超类中的某个函数只与一个（或少数几个）子类有关，那么最好将其从超类中挪走，放到真正关心它的子类中。字段下移同上以子类取代类型码构造函数中使用类型码，来实现不同逻辑。有些时候可以再多往前一步，引入子类。这里有两种处理方法：让不同的类型称为

第11章 重构API将查询函数和修改函数分离如果函数只是提供一个值，没有任何看得到的副作用，那么这是一个很有价值的东西。可以在任意地方调用该函数，需要操心的事情少多了。（命令和查询分离原则）举例说明“看得到的副作用”，一种常用的优化方法是，将查询多得结果缓存于某个字段中，这样一来后续的重复查询就可以大大加快速度。虽然查询时改变了对象的缓存，因为不论如何查询，总是获得相同的结果，所以这一修改时察觉不到的。函数参数化如果两个函数逻辑非常相似，只有一些字面量值不同，可以将其合并成一个函数，以参数的

第10章 简化条件表达式分解条件表达式将每个分支条件和分支执行分解成新函数。这个手法可以突出条件逻辑，更清楚地表明每个分支的作用，并且突出每个分支的原因。本重构手法其实只是提炼函数的一个应用场景，因为价值很大，所以特地强调。合并条件表达式检查条件各不相同，最终行为一致，这种情况下，就应该用“逻辑或”和“逻辑与”将它们合并为一个条件表达式。但如果这些检查的确彼此独立，的确不应该被视为同一次检查，我就不会使用本项重构。执行本手法的时候要注意，确定这些条件表达式都没有副作用。以卫语句取代嵌套条

第9章 重新组织数据拆分变量除了循环变量和结果收集变量，一个变量只应该被赋值一次。同一个变量承担两件不同的事，会令代码阅读者糊涂。字段改名数据结构中的字段命名很重要。修改一个类中的字段，有四个地方需留意：取值函数、设值函数、够着函数和内部数据结构以查询取代派生变量有些变量其实可以很容易地随时计算出来，可以去掉这些变量，将可变数据的作用域限制在最小的范围。计算常能更清晰地表达数据的含义，而且也避免了“源数据修改时忘了更新派生变量”的错误。如果源数据不可变，那么保留或者不保留派生变量都

第8章 搬移特性搬移函数目的：模块化。将相互关联的软件要素都集中到一块，并确保块与块之间的联系易于查找、直观易懂。原因搬移函数最直接的一个动机是，它频繁地引用其他上下文中的元素，对自身上下文中的元素关心甚少。如果在整理代码时，发现需要频繁调用一个别处的函数，我也会考虑搬移这个函数。内部的辅助函数，若其他地方也需要用到，可以搬移到更通用的地方。主要使用在嵌套函数的搬移，和类中函数的搬移。原文中Account类中的函数，搬移到 AccountTypel类中。搬移字段目的：优化程序中的

封装一、封装记录（记录封装成类）记录型结构可以有两种类型：第一种需要声明合法的字段名字比如{start: 1, end: 5}，C#中没有这种特性。第二种是语言库本身实现的，比如hash、map、dictionary等。使用这种记录的缺陷在于，一条记录持有什么字段往往不够直观，只能查看它的创建点和使用点。这条建议是对于可变数据，对于不可变数据可以将它保留为记录。重点在于将更新函数放在类中。读取操作的处理把所有对数据的读取提炼成函数，并将它们搬移到类中。优点提供了清晰的API列

第6章 第一组重构提炼函数何时应该把代码放进独立的函数，一个合理的观点是“将意图与实现分开”。当变量按值传递给提炼部分又在提炼部分被赋值，就必须多加小心。如果只有一个这样的变量，我会尝试将提炼出的新函数变成一个查询（query），用其返回值给该变量赋值。但有时在提炼部分被赋值的局部变量太多，这时最好是先放弃提炼，考虑其他重构手法，拆分变量或者以查询取代临时变量。内联函数略提炼变量表达式有可能非常复杂而难以阅读，这种情况下，局部变量可以帮助我们将表达式分解为比较容易管理的形式。注意

重构的原则重构与性能三种编写快速软件的方法时间预算法持续关注法利用统计数据专门优化测试系统确保测试不该通过时真的会失败。频繁地运行测试。对于你正在处理的代码，与其对应的测试至少每隔几分钟就要运行一次，每天至少运行一次所有的测试。警惕共享测试夹具。如果一个函数会修改测试夹具中的变量，就会影响到后面的测试。考虑可能出错的边界条件，把测试的火力集中在那里。虽然在LeetCode上刷题就已经知晓的道理了，但是再强调也没问题。不要因为测试无法捕捉所有的bug就不写测试，因为测试的确可