第六章阅读笔记及其个人感受
我们想要让编写代码所花的时间越少，想要尽可能在开发周期的早期抓住并修正代码错误，想要在一开始就少制造错误。如果我们能够深思熟虑的编程，那这些会对我们有所帮助：
- 总是意识到你在做什么。
- 不要盲目的编程。（试图构建你完全不熟悉的应用或者使用你不熟悉的技术）
- 按照计划行事，不管计划是在你的大脑中还是在别的什么地方。
- 依靠可靠的事物，不要依靠巧合或假定。
- 为你的假定建立文档，“按合约设计”。
- 不要只是测试你的代码，还要测试你的假定。不要猜测，要实际尝试它。编写断言测试你的假定。
- 为你的工作划分优先级，把时间花在重要的方面。
- 不要做历史的奴隶。不要让已有的代码支配将来的代码。准备好进行重构。
笔记1）为你的工作划分优先级，把时间花在重要的方面。
个人感受1）我以前j总是把时间花在小细节上，结果最后弄得特别拖延，耽误了整个项目的运行，这样做是不对的，要学会分清什么是重要的什么是不重要的，划分好优先级，先把控大方向，将时间花在重要的方面。
笔记2）不要做历史的奴隶。不要让已有的代码支配将来的代码。准备好进行重构。
个人感受2）重构，可以通过调整程序代码改善软件的质量、性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性。要知道一个完美得可以预见未来任何变化的设计，或一个灵活得可以容纳任何扩展的设计是不存在的。系统设计人员对即将着手的项目往往只能从大方向予以把控，而无法知道每个细枝末节，其次永远不变的就是变化，提出需求的用户往往要在软件成型后，才开始"品头论足"，系统设计人员毕竟不是先知先觉的神仙，功能的变化导致设计的调整再所难免。所以"测试为先，持续重构"作为良好开发习惯被越来越多的人所采纳，测试和重构像黄河的护堤，成为保证软件质量的法宝。
第七章阅读笔记及其个人感受
笔记3）与用户一同工作，以像用户一样思考
个人感受3）有一种能深入了解用户需求、却未得到足够利用的技术：成为用户。其实我们总是觉得挖掘需求很难，或者抱怨用户提的要求很过分时，那是因为我们没有站在用户的角度去考虑问题，甚至我们从来没有把自己当成过用户。可实际上，我们自己就是这个项目的第一个用户，我们要想一下，自己作为用户会有哪些想法或者叫需求。要学会建立需求文档挖掘而不是搜索需求，学会使用用例图（可以用UML活动图捕捉工作流，而且有时要为手边的事务建模，概念层类图很有用。用例可以含有指向其他用例的超链接，它们也可以相互嵌套。）
笔记4）不要在盒子外思考，要找到盒子
个人感受4）我们可能会遇到很多棘手的问题，这个时候列出所有的在你面前的可能途径，不要排除任何东西，不管它听起来是否愚蠢，然后分类，从最为严格的逐个击破。
第八章阅读笔记及其个人感受
一、注重实效的团队
不要破窗户
质量是一个团队问题。
煮青蛙
作为整体的团队甚至更容易被煮熟。
交流
团队作为实体需要同外界进行明晰的交流。
不要重复你自己
交流、不同的人指派不同的工作、即时聊天软件
正交性
围绕功能，而不是工作职务进行组织。
自动化
确保一致和准确的一种很好的方式是使团队所做的每件事情自动化。
知道何时停止绘画
团队是由个体组成的，让每个成员都能以他们自己的方式闪光。给他们足够的空间，以支持他们，并确保项目的交付能够符合需求。
笔记5）不要重复你自己
交流、不同的人指派不同的工作、即时聊天软件
个人感受5）我们的团队就是一开始特别乱，一锅粥，大家做同样的事情，结果效率低下，就连这件事情也没做好，所以啊得学会团队分工，不同的人指派不同的工作。
笔记6）早测试，常测试，自动测试。
个人感受6）一旦有了代码，就要开始进行测试，越早发现bug，进行修补的成本就越低。“编一点，测一点”，要通过全部测试，编码才算完成。
测试什么
- 单元测试
- 集成测试
- 验证和校验
- 资源耗尽、错误及恢复
- 性能测试（压力测试、负载测试）
- 可用性测试（真实用户在真实环境下进行的）
怎样测试
- 回归测试——把当前测试的输出与先前的作对比
- 测试数据——一种是真实数据，一种是合成数据
- 演练GUI系统——往往需要专门的测试工具
- 对测试进行测试——故意引入bug，以证实测试能够抓取
- 彻底测试
何时测试
许多项目往往会把测试留到最后一分钟——最后期限马上就要来临时。我们需要比这更早就要开始测试吧，任何产品代码一旦存在，就需要进行测试。
有些测试可能需要频繁进行测试，通常是单元测试和集成测试，每一次在代码签入源码仓库之前都要测试一下。
有些测试可能不容易频繁进行测试，比如压力测试，这些测试就不那么频繁，比如每周或每月一次。