读了这本《构建之法》的教材之后，感觉这本书突破了教材的界限，以往的教材都是很死板很老套的在讲理论知识，然而这本《构建之法》的书却是以一种类似小说的方式来将软件工程的实际操作和理论知识相结合，并且书中用不同的人物来展现不同人对软件工程这一门学科的看法还有一些行为操作习惯。
- 第一章 书中用了很多生动的例子来讲述软件工程的实现，在第一章概论部分，讲的都是对软件工程这一定义，书中第一个例子是举了一位家长为了让孩子随时能做四则运算的算术题，这位家长用自己的特长编译了一个小程序出来，而且得到学校老师其他家长的称赞，然而随着老师提出的要求，这位家长阿超又在程序上做了改进，书上就是用了这样一个例子说明了程序需要有一个软件服务，延伸出了在软件团队中需要从需求分析开始，把需求梳理出来，然后逐步展开后续工作，设计-实现-测试，到最后的发布软件阶段。书中内容让我明白了在同等功能的软件上，想要赢对手，就要在用户体验上下点功夫了。软件=程序+软件工程扩展成又是软件企业=软件+商业模式，所以说软件企业的商业模式也会影响软件的需求。接着又用航空业与软件业做了比较，这两个行业的发展也是有着相同类似的不同阶段，接着又是说计算机科学与软件工程的侧重点，这样详细的介绍让我对软件工程这一学科有了深入的了解。对我们这些以后做软件的人来说，做一个好的软件成功的软件，那就是衡量一个软件的开发效率、用户满意度、可靠性还有可维护性。
- 第二章 在这一章中，开始讲软件工程技术方面的东西，特别是软件测试方面的东西具体有单元测试、回归测试、效能分析和PSP。写单元测试用的工具是VSTS，书本上也明确的写出了操作步骤，有设置数据、使用被测试类型的功能、比较实际结果和预期的结果，但是具体的操作还是等老师来示范下了，毕竟我还是菜鸟。后面又用到小飞和阿超的对话，这又吸引住我了，刚好小飞的一些问题就像我们的问题一样一一的列举出来了。“效能测试，分析，改进，再效能测试”这一流程，让我知道这是在提高程序的时效性的，这个在团队项目中是很重要的。
- 第三章 到了第三章的了解软件工程师的成长经历，这告诉了我个人在团队中也有独立的流程，书中用了很多不同职业例子说明了这一点，例如球队中的摆布和技术要求，又用很多以问答的方式来解释衡量一个人的工作质量，这告诉我们不要仅仅以完成代码来写代码，，如果一个程序员为了简单的问题而不断‘re-work’这个就是工作效率不高的表现。在团队工作中，稳定、一致的交付时间是衡量一个员工能力的重要方面。
以上就是我读《构建之法》获取到的一些知识和感想。然而看完之后我都还有一些问题不明白：
-
-
- 1.计算机科学和软件工程在现实上区别真的好大吗？（第一章1.2.2）
- 2.在软件中“BUG”有没有必要有？以为书中30页写到汽车业中没有BUG未必就是质量完美！（第一章1.2.4）
- 3.单元测试和回归测试在程序测试上可否只用其中一种，直接用回归测试？ （第二章 2.1）
- 4.如何更好分解一个项目需求？（第二章 2.4.2）
- 5.用什么来衡量软件工程师的能力？不同阶段好像有着不同衡量的方案，具体是怎样的？（第三章 3.1）
-
（字数：1250）