不愧是疑问解决神器！你强任你强👍👍👍

• 在过去，我习惯用这种方式来阅读书籍或文章：先快速浏览一遍，然后再进行复读，并最终总结所学的知识点。然而，长期以来，我发现这种方式并不能满足我最初阅读的目的。我相信许多人也有相似的经历，我们阅读某些文章或书籍，要么是为了扩展知识面，要么是为了解决某个问题，或者是对某个话题产生兴趣。然而，事实上，我发现自己在读完某些文章或书籍后，并没有完全理解和真正能够实践的关键要点，只是匆匆地过了一遍。

• 因此，我开始尝试寻找一种新的阅读模式（Q&A），即带着问题去阅读，带着思考去阅读。我尝试在文章或书籍中寻找我想要的答案，或者更深入地理解我关心的问题。最近，我开始阅读《重构：改善既有的代码的设计（第 2 版）》，并尝试使用问答模式进行阅读。通过这种方式，我发现我能够更好地理解书中的内容，并能更好的吸收和自我总结。

• Q&A:

• Q: Question

• A: Answer

前言

1. 这本书讲了什么？

• 解释了重构的原理和最佳实践，并指出何时何 地你应该开始挖掘你的代码以求改善。

2. 这本书的核心是什么？

• 本书的核心是一系列完整的重构方法，其 中每一项都介绍一种经过实践检验的代码变换手法的动机和技术

3. 重构的关键是什么？

• 理解，有条不絮的理解是进行重构的关键。

• 运用本书的重构手法，保证每次只走一步。

4. 什么是重构？

• 在不改变代码外在行为的前提下，对代码做出修改，以此来改进程序的内部结构。

• 重构就是在代码写好之后改进它的设计。

5. 这本书的核心部分？

• 从第 5 章往后的篇幅就是本书的核心部分——重构名录

6. 如何充分利用好这本书？

• 如果你想知道重构是什么 ，请阅读第 1 章，其中的示例会让你弄清楚重构的过 程。

• 如果你想知道为什么应该重构 ，请阅读前两章，它们会告诉你重构是什么以及 为什么应该重构。

• 如果你想知道该在什么地方重构 ，请阅读第 3 章，它会告诉你一些代码特征， 这些特征指出“这里需要重构。

• 如果你想着手进行重构 ，请完整阅读前四章，然后选择性地阅读重构名录。一 开始只需概略浏览列表，看看其中有些什么，不必理解所有细节。一旦真正需 要实施某个重构手法，再详细阅读它，从中获取帮助。列表部分是供查阅的参 考性内容，你不必一次就把它全部读完。

第 1 章　重构，第一个示例

1. 如何给别人讲东西？

• 若按照传统的做法，一开始介绍某种东西时先讲讲它的历史，主要原理等等，那会导致台下的人称为瞌睡虫，思绪开始游荡，眼神开始迷离，直到主讲人拿出示例，台下人才能够提起精神。

2. 重构的第一步？

• 得确保即将修改的代码 拥有一组可靠的测试

3. 重构过程的精髓？

• 重构过程的精髓所在：小步修改，每次修改后就运行测试。如果我 改动了太多东西，犯错时就可能陷入麻烦的调试，并为此耗费大把时间。小步修 改，以及它带来的频繁反馈，正是防止混乱的关键

• 重构技术就是以微小的步伐修改程序

4. 好的代码能够清晰地表明它在做什么？

• 变量命名是代码清晰的关键

• 在做任何提炼前，我一般都会先移除局部变量。

• 把复杂的代码块分解为 更小的单元，与好的命名一样都很重要

• 编程时，需要遵循营地法则：保证你离开时的代码库一定比来时更健 康。

5. 重构带来的性能问题如何解决？

• 大多数情况下可以忽略 它。如果重构引入了性能损耗，先完成重构，再做性能优化

6. 如何完整重构过程中的每一步？

• 编译、测试、提交

7. 第一章重构的重要节点？

• 将原函数分解成一组嵌套的函 数、应用拆分阶段（154）分离计算逻辑与输出格式化逻辑，以及为计算器引入 多态性来处理计算逻辑。每一步都给代码添加了更多的结构，以便我能更好地表 达代码的意图。

8. 重构早起的动力来源？

• 重构早期的主要动力是尝试理解代码如何工作。通常你需要先通 读代码，找到一些感觉，然后再通过重构将这些感觉从脑海里搬回到代码中。清 晰的代码更容易理解，使你能够发现更深层次的设计问题，从而形成积极正向的 反馈环。当然，这个示例仍有值得改进的地方，但现在测试仍能全部通过，代码 相比初见时已经有了巨大的改善，所以我已经可以满足了。

• S：

• 1.先尝试理解代码逻辑

• 2.找到一些重构的感觉

• 3.在重构的过程中发现深层次的设计问题

• 4.形成积极正向的反馈环

9. 什么样的代码才算是好代码？

• 没有好坏高低之分，除了个人品味，也是有客观标准的。

• 我认为，好代码的检验标准就是人们是否能轻而易举地修改它。好代码应该 直截了当：有人需要修改代码时，他们应能轻易找到修改点，应该能快速做出更 改，而不易引入其他错误。

• 好代码的检验标准就是人们是否能轻而易举地修改它。

10. 重构的注意点？

1. 不要着急

2. 先理解代码逻辑

3. 逐步拆分步骤，一步一步来

4. 遵循重构规则：编译 -> 测试 -> 提交

5. 不要嫌拆分的步骤过小而跳过重构规则

6. 一定不要心急

7. 不要只记得重构代码，要重构成好的代码时关键的一步

8. 好的代码更加利于扩展

第 2 章　重构的原则

1. 何谓重构？

• 重构的关键在于运用大 量微小且保持软件行为的步骤，一步步达成大规模的修改。每个单独的重构要么 很小，要么由若干小步骤组合而成。

2. 重构过程中，代码可不可以正常工作？

• 如果在代码重构中，代码有一两天是不可用的状态时，可确保在做的并不是重构，而是 结构调整（restructuring），而结构调整则是进行各种形式的重新组织和清理。

3. 重构与性能优化的相似之处？

• 重构是为了让代码“更容易理解， 更易于修改。这可能使程序运行得更快，也可能使程序运行得更慢。在性能优 化时，我只关心让程序运行得更快，最终得到的代码有可能更难理解和维护

4. 为何重构？

1. 重构改进软件的设计

2. 重构使软件更容易理解

3. 重构帮助找到 bug

4. 重构提高编程速度

5. 何时重构

• 三次法则：第一次做某件事时只管去做；第二次做类似的事时会产生反感，但无论如何还是可以去做；第三次再做类似的事，你就应该去重构。

6. 何时不应该重构？

1. 如果看到一段凌乱的代码，你并不需要用到或不需要理解时，就不需要重构

2. 如果重写比重构还容易，那就别重构了。

7. 重构给你带来的东西？

• 重构的唯一目的就是让我们开发的更快，用更少的工作量创造更大的价值。

• 重构的意义不是在于把代码库打磨的闪闪发光，而是从纯粹的经济角度出发的考量。

8. 我们为什么会进行重构？

• 我们之所以重构：因为它能让我们更快添加功能，修复 Bug 更快。

Q:

• 你的公司的技术领导会不会重视代码库健康的价值？

9. 遗留代码是好事还是坏事？

• 大多数人可能会觉得有一大笔遗产是件好事，但从程序员的角度来看会不同。遗留代码往往很复杂，测试又不足，而且最关键的时，是别人写的（瑟瑟发抖）。

• 若想重构之前的遗留代码，建议你不要一鼓作气的把复杂而混乱的遗留代码重构成漂亮的代码。建议从自己所接受的功能相关的代码重构起。

10. 重构与性能？

• 在重构中性能也是其中的一个话题，重构代码如果把大半的时间都耗费在一小半的代码中，那其实这些优化工作是白费劲的，因为被你优化的代码很少被执行。

• 记住，你花时间优化的代码时为了让程序运行的更快，而不是简单的优化一些代码。

• 好的优化方式时，在性能优化阶段，我们应该用一个度量工具来监控程序的执行，让监控工具来告诉我们那些地方，消耗的时间和空间比较多。这样我们就能找出性能热点所在的一段代码，而我们应该集中关注在这些热点上。

11. 重构的 Web 版网站？

• [重构](https://refactoring.com/)

系列首发于如上图平台，文章会持续更新，欢迎大家关注~