重构 改善既有代码的设计（第2版 平装版）(异步图书出品)
马丁·福勒
25个笔记
点评
认为好看
第1章 重构，第一个示例
是需求的变化使重构变得必要
如果一段代码能正常工作，并且不会再被修改，那么完全可以不去重构它
我得确保即将修改的代码拥有一组可靠的测试
尽管编写测试需要花费时间，但却为我节省下可观的调试时间
无论每次重构多么简单，养成重构后即运行测试的习惯非常重要
小步修改，每次修改后就运行测试
好代码应能清楚地表明它在做什么，而变量命名是代码清晰的关键
临时变量往往会带来麻烦
临时变量实质上是鼓励你写长而复杂的函数
format未能清晰地描述其作用。formatAsUSD很表意，但又太长
usd
好的命名十分重要，但往往并非唾手可得。
有了好的名称，我就不必通过阅读函数体来了解其行为
我会使用当下能想到最好的那个。如果稍后想到更好的，我就会毫不犹豫地换掉它
把与更新volumeCredits变量相关的代码都集中到一起，有利于以查询取代临时变量（178）手法的施展
重复一次这样的循环对性能的影响都可忽略不计。
因此对于重构过程的性能问题，我总体的建议是：大多数情况下可以忽略它。
如果重构引入了性能损耗，先完成重构，再做性能优化。
在事情变复杂时，我的第一反应就是采用更小的步子
怎样算变复杂呢，就是当重构过程有测试失败而我又无法马上看清问题所在并立即修复时，我就会回滚到最后一次可工作的提交，然后以更小的步子重做
修改了函数内部的变量名
以管道取代循环
彻底分离，我干脆把它搬移到另一个文件里
这说明，在合适的场景下使用面向对象是合理的——显然我们这个就是一个合适的使用场景。
微信读书
