《构建之法》这本书很有趣，这本书里面像讲故事一样为我们列举了大量的例子。阅读《构建之法》后，让我明白了软件构建的过程不仅仅是写出一个程序，还需要根据用户的需求扩展应用程序各种功能，接着还要扩展一个能保证服务质量的软件服务；在软件构建过程中还需要拥有各种文件和数据来描述各个程序文件之间的依赖关系、编译参数、链接参数等等。而在软件开发的阶段中，本书使用一个航空产业的例子阐述了软件开发的各个阶段，分别为玩具阶段、业余爱好阶段、探索阶段、成熟的产业阶段，让我们更好的了解到软件开发的各个阶段是通过一开始我们对这个软件的兴趣开始，紧接着开始对软件不停的完善，直到最后完善到一个成熟的阶段。
《构建之法》中单元测试就是在测试程序中最基本的类中间测试一些最基本的功能点，并且单元测试需要测试API中的每一个方法及每一个参数，而且单元测试必须让最熟悉代码的人或者是作者来写。在单元测试过程中，应该覆盖所有代码路径，
俗话说，不以规矩不成方圆。在写代码的时候，我们往往写的只是自己看得懂就好的代码，而如果我们在公司中需要与别人合作，此时就需要让合作者明白我们的代码意思。《构建之法》中阐述了程序员的代码应该简明、易读、无二义性，每行的代码应该使用Tab键保持4个空格位置，而行宽则可以限制在100个字符；当我们有了复杂的条件表达式，应该用括号清楚的表示逻辑优先级，并且不要把多个变量定义在一行上；在为变量、类命名时，采用合适的命名规则，当为程序注释时，复杂的注释应放在函数头，且当程序修改时也要为相应的注释进行更新。写完代码之后，需要对代码复审，让我们发现代码的编码错误、逻辑错误、算法错误、潜在的错误等。
开发软件中，我们需要获取软件需求，应该通过获取和引导需求、分析和定义需求、验证需求、在软件产品的生命周期中管理需求来准确且全面的找到需求。在获取用户需求中，本书更是为我们引用了一个千秋图来解释，当我们要获取用户最需要的东西，就是要先找到一群目标用户的代表，加上项目的利益相关者来讨论用户需要什么，用户对软件的评价。而且需要通过详细的面谈，来广泛且深入地了解用户的背景、心理、需求等。也可以采用向用户提供设计好的问题，让用户通过问卷调查的方式来回答这些问题。
在阅读《构建之法》这本书以后，我存在了几个疑问，分别为：
1、软件的创新是否要基于在哪些方面上，什么样的创新才算是一个好的创新
2、团队合作中的交响乐团模式不清楚到底是什么
3、如何尽快的融入到开发团队中
4、所谓的用户体验，是否是一直根据用户的需求来对软件不断的修补
5、当前软件测试是否都应该进行外部公开测试