思维导图转载https://www.processon.com/view/60fbcae1e401fd7e997aa66e重构的基本功识别坏味道、测试先行、行为保持1.识别坏味道、测试先行、行为保持的变更动作是重构的基本功。2.TDD测试驱动开发 先写测试再写实现代码用测试来驱动代码的设计和开发。TDD 的基本循环三个步骤——也叫红绿重构循环Red-Green-Refactor1.Red写失败的测试写一个还没实现功能的测试代码运行它测试必然失败。2.Green写代码通过测试写最简单的代码让测试通过不求完美只求通过。3.Refactor重构代码在测试通过的前提下优化实现的结构让代码更优雅、可维护。然后重复这个循环写下一个测试再实现再重构。3.保持代码易读、易修改的关键就是重构。4.需求的变化使重构变得必要5.设计模式为重构提供了目标6.重构前先检查自己是否有一套可靠的测试集。这些测试必须有自我检验能力否则就得耗费大把时间来回比对这会降低开发速度。7.在做任何提炼前我一般都会先移除局部变量。8.如果重构引入了性能损耗先完成重构再做性能优化。9.重构过程的精髓所在小步修改。每一步都伴随着一次编译、测试以及向本地代码库的提交。特别是在事情变复杂时。10.“计算逻辑的差异是由类型代码确定”最自然的解决办法类型多态。11.更愿意有自测试的代码但如果没有自动化重构的工具包也很好。12.如果你对大多数程序进行分析就会发现它把大半时间都耗费在一小半代码身上。13.除了用来记述将来的打算之外注释还可以用来标记你并无十足把握的区域。你可以在注释里写下自己“为什么做某某事”。这些信息可以帮助将来的修改者尤其是那些健忘的家伙。14.测试应该是一种风险驱动的行为我测试的目标是希望找出现在或未来可能出现的 bug。所以我不会去测试那些仅仅读或写一个字段的访问函数因为它们太简单了不太可能出错。测试的重点应该是那些我最担心出错的部分这样就能从测试工作中得到最大利益。15.当测试数量达到一定程度之后继续增加测试带来的边际效用会递减如果试图编写太多测试你也可能因为工作量太大而气馁最后什么都写不成。你应该把测试集中在可能出错的地方。