《程序员修炼之道 从小工到专家》读书笔记6
第 33 节 重构
1、重写、重做和重新架构代码合起来，称为重构。
2、当代码出现以下特征，就应该考虑重构了：
- 出现重复内容，违反DRY原则。
- 非正交的设计。
- 知识过时了，或者你对某部分的了解更深一步。
- 对性能造成了影响。
3、重构的原则：早重构、常重构。重构面临的敌人通常都是时间，但这个借口并不成立，因为之后由此引发的时间额外消耗很可能更多。
4、如何重构。
- 不要试图在重构的同时增加功能。
- 重构之前，确保拥有良好的测试。
- 采取短小，深思熟虑的步骤，不要一次改动太多内容。
第34节 易于测试的代码
1、软件 IC 是人们在讨论可复用性和基于组件的开发时喜欢使用的比喻。意思是集成电路芯片可以很容易的进行组合，我们希望软件开发也能达到这个效果。芯片的设计有完善的测试，同样的软件开发也可以做同样的事情。
2、针对合约进行测试及为测试而设计，即 TDD 测试驱动开发。
3、编写单元测试，对比较大的项目，将每个测试都放进一个子目录。
4、使用测试装备。构建一套完善的测试体系，它能够记录测试状态，分析输出结果是否符合预期，以及选择和运行测试。
5、推进测试文化，尽可能完善地测试你的软件，否则你的用户就得替你测试。
第35节 邪恶的向导
1、这里的向导指的是那些用于帮助我们构建程序自动生成的代码，通常他们还被称为脚手架。为什么称向导（wizard）是邪恶的呢，这是因为通过工具生成的代码，很容易被我们忽略，在这种情况下你编写的过程更倾向于靠巧合编程。
2、这里不是抵制向导代码，而是在强调，不要使用你不理解的向导代码。如果使用，一定要清楚它的机制。
3、开发每天都在使用不完全理解的事物，比如集成电路的工作原理，处理器的中断结构、用于调度的算法、各种系统库的工作机制等。需要注意的是，这些属于底层依赖，他们也是向导，但不是应用本身的一部分，我们可以对这部分有所了解，但他们不属于邪恶的向导。
第36节 需求之坑
从本节开始进入了第七章节：在项目开始之前。本章节讨论了在项目开始之前的一些建议。
1、完美，不是在没有什么需要增加，而是在没有什么需要去掉时达到的。这句话的一种解读时，不要搜集需求，需求太多，容易让我们抓不住重点，更应该深挖需求，围绕核心功能不断打磨。
2、挖掘需求，需要我们与用户一同工作，像用户一样思考。
3、制定需求文档。看待用例的一种方式是强调其目标驱动的本质，它强调的是要重视需要做成什么以及需要什么条件。需求文档最好配一些UML用例图。
4、需求的制定不能太具体，要保持一定的抽象。需求不是架构，不是设计，需求只是需要。这个有点类似于开发中的面向接口而不是面向具体实现编程。
5、维护词汇表。“客户”和“顾客”，可能表达不同的含义，但如果混用会让人迷惑，我们可以维护一个词汇表，专门用户描述他们的具体含义。
6、把需求文档发布到内网，参与人员都可以随时查看和提出意见。
第37节 解开不可能解开的谜题
1、戈尔迪斯结号称是没人能解开的结，后来亚历山大大帝来了，用剑劈开了这个结。
2、面对看似不可能解决的问题，一定要转换思路，不要受任何先人之见影响。不要在盒子外面思考，要找到盒子。
3、有时你会发现，自己在处理的问题比你以为的要难得多，总会感觉一定有更容易的方法。这时你可以退回一步，问问自己：
- 有更容易的方法吗
- 你是在解决真正的问题，还是被外围的技术问题转移了注意力
- 这件事情为什么是一个问题
- 是什么使它如此难以解决
- 它必须以这种方式完成吗
很多时候，对需求的重新诠释能让整个问题全部消失— 就像戈尔迪斯结。
第 38 节：等你准备好
1、倾听反复出现的疑虑。当你遇到一个反复让你疑虑的问题，需要注意它，给自己时间去理解，之后它可能就会变成某种更坚实的东西。
2、对于某些东西，我们可能不愿意轻易做出承诺，总希望再等等，更多意见的提出。但这很可能是一种拖延，怎么区分是有效的等待还是拖延的接口呢？我们应该快速地构建原型，并进行推延，可能很快我们就找到了更好的解决方案。
第 39 节：规范陷阱
1、编写规范是一项重要的职责，但问题是很多人可能会陷在这里，不断地增加规范项。我们可以做这样一个尝试，写一份简单的描述，告诉别人怎样系鞋带。
这可能是一份并不能帮助他人的描述，因为对有些事情“做”胜于“描述”。因为无意识的行为更快，考虑规范反而会拖慢进度。
2、对待开发文档也一样，不要编写过于详细的规范。因为很可能开发者在思考某个问题时会想到两种不同方案，经过简单对比，选择一个更优的那个。但面对严格的规范文档，一步步思考，这更可能束缚开发者的发挥。
