第31节 靠巧合编程
从本节开始进入书目的第6章，本章主要讲在编码时应该注意的各类事项。传统智慧认为，项目一旦进入编码阶段，工作主要就是机械的把设计转换成可执行语句。我们认为，这种态度是许多程序丑陋、结构糟糕、不可维护的最大一个原因。编码不是机械工作，要想让程序长久无误的运行，每一分钟都需要做出决策，且需要对这些决策进行仔细的思考和判断。
1、靠巧合编程即代码正好是可运行的，至于为什么能够正常运行，却不清楚。这是我们应该极力避免的。
2、在打算重构某个看起来有问题的代码时，我们会面临这样的疑惑，是否有必要冒着把能工作的东西弄糟的风险呢？这时我们可以考虑一下几个理由：
- 它也许不是真的能工作，只是看起来能工作。
- 你依靠的边界条件也许只是一个巧合。
- 多余和没必要的调用会让你的代码变慢并增加新 bug 的风险。
3、如何深思熟虑的编程，有以下建议：
- 总是意识到你在做什么。
- 按照计划（设计）行事。
- 依靠可靠的事物而非假设。
- 不要只是测试你的代码，还要测试你的假定。
- 不要让已经做完的事情限制你的下一步，做好重构的准备。
第32节 算法效率
1、注重实效的程序员几乎每天都要使用估算，估算的资源包括：时间、处理器、内存等等。
2、估算算法即是我们熟知的时间复杂度，用O()表示，它有以下几种常见类型。
- O(1)，常量时间，不随数据的多少变化
- O(n)，线性时间，简单的循环
- O(m*n)，嵌套循环
- O(log(n))，二分法，平衡二叉树的查询
- O(nlog(n))，分而治之，快排
- O(2^n)，指数级，斐波那契数列
3、不同的时间复杂度在达到一定数量级的时候将相差很多，所以某些情况我们要想方设法优化算法的效率。我们主要需要关注的是是复杂度的阶。在确认了算法之后，还需要对其进行测试。
4、最好的并非总是最好的，是否使用最优算法，还需要根据我们遇到的实际情况。有时数据量很小的情况，算法的效率是可以忽略不计的。
第 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、把需求文档发布到内网，参与人员都可以随时查看和提出意见。