关于构建之法的读后感：
"具备良好的阅读能力并能够清晰的表达出来是作为一个软件工程师最基本的素质和要求。因为只有这样，我们才可以更好的读懂客户的软件需求，并按着需求更好的做好我们自己的产品。这体现
需求分析对于软件团队来说是十分重要的。这关乎到软件是否能够收到针对人群的欢迎，软件团队必须慎重考虑并且在开发过程中必须考虑到这个元素，而这里就详细的描述了需求分析。
在第10章中提到的如何定义典型用户和典型场景，以及从典型用户到场景，从场景到任务的过程。作者在写书的过程中有了典型用户之后，我们还得决定每一个典型用户的目标 — 他/她使用系统想要达到什么目的。对于每一个目标，列出达到目标所必须经历的过程，这就是场景，也可以叫故事这本构建之法包括了软件设计与实现，用户体验，软件测试质量保障，稳定和发布阶段以及IT行业的创新等等。
软件开发是一种集体活动，其中必然面临各成员间的协调、统一问题。银行每天都要对各网点进行清算结账，软件开发也是一样的，必须找到一种方法来衡量每天的工作，保证每天的工作能够有效的持续下去，最终把软件开发的过程变成一种内在的过程。这种方法就称为每日构建或是持续集成。每日构建构建的过程是完全自动化的，通过预先定义好的指令，机器将按照指令顺序执行完所有的构建步骤。它让开发者可以每天进行系统集成，从而减少了开发过程中的集成问题。持续集成可以减少集成阶段"捉虫"消耗的时间，从而最终提高生产力。它使得绝大多数bug在引入的同一天就可以被发现。而且，由于一天之中发生变动的部分并不多，所以可以很快找到出错的位置。对开发人员而言，每日构建带来的好处就是签入即更新。
软件构造是个复杂的过程，但总体来说就是分析统一——实现设计——软件测试——编写文档，但这不是一条线的流程，因为很可能因测试不过关而重复无数次，这也是程序员害怕BUG的主要原因，为了尽快达成软件的实现，公司内部、团队内部都会建立每日目标，提交每日报告，以此督促员工的完成工作，只要不歇息，这一个过程将会是十分流畅的。但实际上，会有不少突发事件，包括训练新员工、项目完全重构、项目丢失等十分麻烦的事情，所以项目也不应该十分紧张，留有余地总会是好的。
我印象颇深的是作者在对风险管理水平的分级，一共四层，第一层一惊一乍的以为是大问题但却不去理会，没有预案；第二层准确来说是拖延，但确实采取行动去防止并解决问题，说是缓和但也只是让时间去解决问题，也没有可取之处；第三层就是有经验的应对，如何解决问题早已心有成竹，不会有大问题；第四次化危机为机遇，这是面对大危机也能自如应对的才能，项目被毙掉了或许就是这个项目的死亡，但提前布局针对前景进行开发工作，而且留有后路，这样就能在危机四伏软件工程中做一只不灭的小强。
这些例子都说明了领域内的专家有时没有领域外的创新者有创意。我想更多的是没有从实际出发考虑顾客和群众的感受，就像有时候我们做题一样，看一遍题知道了它应该用什么公式，用什么原理去解答，然而就是实际动笔去解，真正到了考试，我们碰到同样的问题，也就只能停留在:"这道题我当时碰到过！"却迟迟解不出来。所以创新的前提是实践，不能停留在想法上。
形式化方法建立在严格的数学基础上，其目标是希望能使系统具有较高的可信度和正确性，并能使系统具有良好的结构，使其易维护，关键是能较好地满足用户需求。“形式化方法”一词虽然一直被广泛地应用，但在不同程度上，因理解不同，使其具有了不同的含义。一般说来，形式化方法是指具有坚实数学基础的方法，它是数学上的综合、分析技术的应用，用于开发计算机控制的系统，经常有推理工具的支持，它可提供一个用于模型设计和分析的一个严格而有效的途径。