构建之法》，它很通俗的将软件工程阐述清楚。读过之后，对于工程有了一定的认识，一个工程，它与我们现在所学的通过写代码实现一件事情，实现一个项目是不一样的，现在所学所做的这些，还远不及工程这个概念，实现一个工程，需要完整的team，team中每个成员，软件工程师需要有一定的个人能力及职业素质等等。而我现在所学的，仅仅是在向着一个合格的“软件工程师”发展着，虽然有很多内容看不太懂，但还是总体上软件工程这个专业、对于自己将来该干什么，怎么做有了大概的了解与方向。
本书第一章主要讲了相关的理论和知识点。首先还是那句老生常谈的名言“程序=数据结构+算法”、“软件=程序+软件工程”。就像书中所说，我们学过链表、二叉树等，但是除过特殊要求必须使用链表外，在日常的编程写代码的时候从来没有用过这些链表啊什么的。再来看书中的例子：一家长因需要出题做了一个程序，后来老师有了要求需要把这个程序做完整，此时就出现了用户和需求，进而初步引入了工程的概念。作者还介绍了软件工程的概念、软件工程的特殊性等。总之读过这一章后，对这个专业有了进一步的了解，并且意识到“工程”的概念。
第二章首先讲到了单元测试，在此之前从未了解过这个概念。在日常的代码编写过程中，我们会借用别人的代码，或者是一起合作，某人负责的某个模块被其他人调用，这时候由于对代码的不了解，会出现错误，那么单元测试就是一个很好的解决方案。作者以VSTS为例，介绍了单元测试的方法。在刚接触到“单元测试”这个词的时候，本以为平常在完成一项任务的时候，在完成某一小功能或者小模块的时候，会举一两个例子进行测试，看是否正确，本以为这就是单元测试，但其实这只是单元测试的一块，或者是类似单元测试。讲真的这一块没有太读懂，作者说单元测试必须由最熟悉代码的人（程序的作者）来写，但是我一直以为单元测试只是一个操作。
第三章写到软件工程师的成长，首先是个人能力的衡量与发展，作者用足球队来做比，足球队中也存在个人流程，也有“阵型”，涉及团队的配合。软件团队和团队内的工程师也是这样，软件中绝大多数的模块是由个人开发或维护的。我认为这章的重点在于成长。作者还指出软件工程师的几个思维误区。分析麻痹：总想着把所有的一切都分析清楚了才开始；不分主次，想解决所有依赖问题：为了完美的完成最初的目标而不分主次；过早优化：陷在一个局部问题中一直改进；过早的扩大化。我觉得以前我就处于分析麻痹和过早优化中。作者还以玩魔方为例，通过前人的方法和经验达到最终的目的不叫精通（通过口诀完成魔方不是精通）。