重构（第2版）
最新书摘：
-
豆友1529054852022-03-16所谓程序设计，很大程度上就是与计算机对话：我编写代码告诉计算机做什么事，而它的响应是按照我的指示精确行动。一言以蔽之，我所做的就是填补“我想要它做什么”和“我告诉它做什么”之间的缝隙。编程的核心就在于“准确说出我想要的”。然而别忘了，除了计算机，源码还有其他读者：几个月之后可能会有另一位程序员尝试读懂我的代码并对其做一些修改。我们很容易忘记这位读者，但他才是最重要的。计算机是否多花了几个时钟周期来编译，又有什么关系呢？如果一个程序员花费一周时间来修改某段代码，那才要命呢——如果他理解了我的代码，这个修改原本只需一小时。
-
豆友1529054852022-03-16如果没有重构，程序的内部设计（或者叫架构）会逐渐腐败变质。当人们只为短期目的而修改代码时，他们经常没有完全理解架构的整体设计，于是代码逐渐失去了自己的结构。程序员越来越难通过阅读源码来理解原来的设计。代码结构的流失有累积效应。越难看出代码所代表的设计意图，就越难保护其设计，于是设计就腐败得越快。经常性的重构有助于代码维持自己该有的形态。
-
豆友1529054852022-03-16Kent Beck 提出了“两顶帽子”的比喻。使用重构技术开发软件时，我把自己的时间分配给两种截然不同的行为：添加新功能和重构。添加新功能时，我不应该修改既有代码，只管添加新功能。通过添加测试并让测试正常运行，我可以衡量自己的工作进度。重构时我就不再添加功能，只管调整代码的结构。此时我不应该添加任何测试（除非发现有遗漏的东西），只在绝对必要（用以处理接口变化）时才修改测试。软件开发过程中，我可能会发现自己经常变换帽子。首先我会尝试添加新功能，然后会意识到：如果把程序结构改一下，功能的添加会容易得多。于是我换一顶帽子，做一会儿重构工作。程序结构调整好后，我又换上原先的帽子，继续添加新功能。新功能正常工作后，我又发现自己的编码造成程序难以理解，于是又换上重构帽子……整个过程或许只花10分钟，但无论如何我都清楚自己戴的是哪一顶帽子，并且明白不同的帽子对编程状态提出的不同要求。
-
豆友1529054852022-03-16好代码应该直截了当：有人需要修改代码时，他们应能轻易找到修改点，应该能快速做出更改，而不易引入其他错误。
-
豆友1529054852022-03-16虽然代码的行数增加了，但重构也带来了代码可读性的提高。额外的包装将混杂的逻辑分解成可辨的部分，分离的详单的计算逻辑与样式。这种模块化使我更容易辨别代码的不同部分，了解它们的协作关系。虽说言以简为贵，但可演化的软件却以明确为贵。
-
豆友1529054852022-03-14我得坦白，我并非总是如此小步——但在事情变复杂时，我的第一反应就是采用更小的步子。怎样算变复杂呢，就是当重构过程有测试失败而我又无法马上看清问题所在并立即修复时，我就会回滚到最后一次可工作的提交，然后以更小的步子重做。这得益于我如此频繁地提交。特别是与复杂代码打交道时，细小的步子是快速前进的关键。
-
豆友1529054852022-03-14好的命名十分重要，但往往并非唾手可得。只有恰如其分地命名，才能彰显出将大函数分解成小函数的价值。有了好的名称，我就不必通过阅读函数体来了解其行为。但要一次把名取好并不容易，因此我会使用当下能想到最好的那个。如果稍后想到更好的，我就会毫不犹豫地换掉它。通常你需要花几秒钟通读更多代码，才能发现最好的名称是什么。
-
豆友1529054852022-03-14这次改名是否值得我大费周章呢？当然值得。好代码应能清楚地表明它在做什么，而变量命名是代码清晰的关键。只要改名能够提升代码的可读性，那就应该毫不犹豫去做。
-
豆友1529054852022-03-10我再强调一次，是需求的变化使重构变得必要。如果一段代码能正常工作，并且不会再被修改，那么完全可以不去重构它。能改进之当然很好，但若没人需要去理解它，它就不会真正妨碍什么。如果确实有人需要理解它的工作原理，并且觉得理解起来很费劲，那你就需要改进一下代码了。
-
豆友1529054852022-03-10随着各种规则变得越来越复杂，适当的修改点将越来越难找，不犯错的机会也越来越少。
-
豆友1529054852022-03-10作为一个经验丰富的开发者，我可以肯定：不论最终提出什么方案，他们一定会在6个月内再次修改它。毕竟，需求通常不来则已，一来便会接踵而至。
-
crazy2013-08-09任何一个傻瓜都能写出计算机可以理解的代码。唯有写出人类容易理解的代码，才是优秀的程序员。
-
豆友1529054852022-04-23作为程序员，我们的职责就是设计出结构一致、抽象合宜的程序，而程序抽象能力的源泉正是来自函数。与其他抽象机制的设计一样，我们并非总能平衡好抽象的边界。随着系统能力发生演进（通常只要是有用的系统，功能都会演进），原先设定的抽象边界总会悄无声息地发生偏移。对于函数来说，这样的边界偏移意味着曾经视为一个整体、一个单元的行为，如今可能已经分化出两个甚至是多个不同的关注点。
-
豆友1529054852022-03-16很多时候那个未来的开发者就是我自己。此时重构就显得尤其重要了。我是一个很懒惰的程序员，我的懒惰表现形式之一就是：总是记不住自己写过的代码。事实上，对于任何能够立刻查阅的东西，我都故意不去记它，因为我怕把自己的脑袋塞爆。我总是尽量把该记住的东西写进代码里，这样我就不必去记它了。这么一来，下班后我还可以喝两杯Maudite啤酒，不必太担心它杀光我的脑细胞。
-
豆友1529054852022-03-11每当我要进行重构的时候，第一个步骤永远相同：我得确保即将修改的代码拥有一组可靠的测试。这些测试必不可少，因为尽管遵重构手法可以使我避免绝大多数引入bug的情形，但我毕竟是人，毕竟有可能犯错。程序越大，我的修改不小心破坏其他代码的可能性就越大——在数字时代，软件的名字就是脆弱。
-
豆友1529054852022-03-10复制一遍代码似乎不算太难，但却给未来留下各种隐患：一计费逻辑发生变化，我就得同时修改两个地方，以保证它们逻辑相同。如果你编写的是一个永不需要修改的程序，这样剪剪贴贴就还好。但如果程序要保存很长时间，那么重复的逻辑就会造成潜在的威胁。
-
bluetingting2012-07-17refactoring does not change the observable behavior of the softwareWhy Should You Refactor?Refactoring Improves the Design of SoftwareRefactoring Makes Software Easier to UnderstandRefactoring Helps You Find BugsRefactoring Helps You Program Faster即使在开发过程中，当你发现重复或相似的代码时，也应该立刻重构；当变化发生时，如果该变化影响不止一处，重构就应该粉墨登场。经常的重构可以保证代码常拭常新，如利刃一般锋利。“不要容忍破窗户”如果两个或更多的地方实现同一职责，则改变时会带来麻烦。所以要遵循DRY原则，单一职责。When Should You Refactor?The Rule of Three(Three strikes and you refactor)Refactor When You Add FunctionRefactor When You Need to Fix a BugRefactor As You Do a Code ReviewThe most common time to refactor is when I want to add a new feature to some software.Reasons:1.refactoring helps me understand some code I need to modify.2.another driver of refactoring is a design that does not help me add a fe...
-
bluetingting2012-07-17to make the software easier to understand and modify.
-
豆友1529054852022-03-11养成重构后即运行测试的习惯非常重要。犯错误是很容易的——至少我知道我是很容易犯错的。做完一次修改就运行测试，这样在我真的犯了错时，只需要考虑一个很小的改动范围，这使得查错与修复问题易如反掌。这就是重构过程的精髓所在：小步修改，每次修改后就运行测试。如果我改动了太多东西，犯错时就可能陷入麻烦的调试，并为此耗费大把时间。小步修改，以及它带来的频繁反馈，正是防止混乱的关键。