在项目开始之前
在开始项目的第一步是需求，寻找需求。项目的第一步都是搜集需求，但是需求并不是搜集的，而是挖掘到的。搜集的需求往往是模糊的，因为客户也不知道他想要什么，他提出模糊的需求，而我们又缺乏相关的专业知识，很容易造成误解，为了防止这种情况，一方面需要保持沟通，一方面建立需求文档。使用UML用例图也是理解需求的好方法。需求往往是模糊的，甚至它可能不是需求。客户提出的问题可能难以解决，但是他真的是问题吗？是不是这个难题是为了完成某个功能的步骤，也许换个思路，问题本事就解决甚至不存在了。而后作者介绍了准备。在面前的项目还只是一张白纸时，很多人会迟疑。这很正常，指挥站在乐队前，会寻找合适的时机挥动指挥棒，程序员也是如此，要重视你内心的疑虑。但你要分清楚那是真正的疑虑还是自己的拖延症。紧随需求挖掘的是制定规范，或者说这两者应该是紧密联系甚至是如影相随的。真正健康的编程环境中，规范不应该成为编程的阻碍，应该是贴合需求的编程规范保证着编程过程减少错误的出现。编程规范不应该是形式主义————这是最后一小节反复强调的中心。
注重实效的项目
在该章节中，首当其冲需要注意高效的是团队，该部分在我理解中，团队中每个人的实效组成了实效的团队。每个人要做的，恰是前面章节介绍的。第二个部分介绍的是自动化。项目需要团队协作，但是同一个软件包导入团队每个人的电脑上可能出现不同的bug，追踪这些bug，结果往往是千奇百怪的，人在厚厚的相同的操作文档的指导下是比不过电脑自动化的，我们可以利用自动化软件，来完成这一过程。在这一章节中着重强调了测试，一个有实效的程序员应该学会自己找自己的bug，而测试是多种多样的：我们用单元测试来捕捉局部的bug，用集成测试来解决整个软件运行中的bug。而我们要尽量保证每个bug只改一次，一次解决完这一bug，而不是一个bug搜索项目三四遍才彻底解决。下一模块讲述的是文档。这也是编程规范中该讲述的。每个程序员应该把文档放在手边，时刻注意需求和注释等文档。本书最后则是阐述了成功与失败：成功是温和的额外一公里，失败要做到负责。
在我看来，本书已经是对编程这件事的经验总结，是程序员从小工到专家一步步总结出来的经验。对知识浅薄，缺少实践的我来说，只能理解到我所经历过的一部分很对，如果要我谈读后感的话，只能不停点头对对对了，所以最后读后感写下来就像是总结一样，见识浅薄请原谅。
