以前也是读了一些软件工程类的书籍，虽然有些比较容易让人感同身受，能引起阅读兴趣，但是其余的大多枯燥乏味，不够接地气，就像教材课本一样，然而在开始阅读《构建之法》的时候，却发现这本书有很多令人受益匪浅的地方，同时用它强大的实用性和趣味性，深深的吸引了我。
开篇概论，和其他的软件工程书籍一样，阐明了软件工程中的重要概念，诸如软件=程序+软件工程，以及软件工程的几个领域：软件需求分析、软件设计、软件构建测试与维护。唯一需要特别说明的是，概论中提出了软件工程的目标——作出“足够好”的软件。为什么说足够好而不是最好，因为世界上没有最好的软件，没有那个大厂会说自己做出来的软件是完美的，正因为如此，才有了从需求到开发不停的改善发展。虽然不是最好，软件的质量我们也要尽可能的保证，一个软件的质量可以被称得上足够好，不仅仅是因为它没有bug，还包括它开发流程的质量、它的可维护性、用户的满意度、它的可靠性等等。其中最令我感同身受的就是软件流程的质量，这里的软件流程的质量指的不仅仅是开发流程，更重要的元素是软件团队，团队成员的协作如果出现问题，软件的质量和按时交付其实很难保证。
软件工程的基本要求也被作者提及，首要的当然就是开发出符合用户需求的软件，其次就是按时交付，最容易被我们忽视的，就是软件的可维护性和可发展性，正因为没有完美的软件，所以软件的维护和发展是必要的，没有发展空间的软件在当今的软件市场里几乎可以说没有生存竞争力。
第二章讲的是软件工程师的个人技术和软件的开发流程，在开发过程中，软件的质量和开发效率是我们必须要考虑的，而在这个过程中，需要具备的基本技能有：单元测试、效能分析以及PSP。其中最值得我们团队反省的就是单元测试方面。
我们在编写程序的时候，总会通过不停的调试修改使之能通过编译，但是通过编译只能代表它的语法正确，不能代表程序的语义正确，而单元测试正好可以帮助我们检验程序（软件）的语义正确性，在实际的工作中，可以不必过分强调先什么后什么，重要的是高效和感觉舒适。从经验来看，先编写产品函数的框架，然后编写测试函数，针对产品函数的功能编写测试用例，然后编写产品函数的代码，每写一个功能点都运行测试，随时补充测试用例。
而到目前为止，我们团队的开发还没有一个明确的测试流程，我们总是通过不停的重复工作跑通程序，一没有一个正规的测试报告，二没有一个明确的测试方向，我们的任务甚至停留在，跑通就可以，没有BUG就可以，不闪退就可以，结果正确就可以。我觉得这是大忌，我们在开发过程中也没有考虑软件后期的维护，在以后的开发中，我们会在设计之初预留出一个测试周期，明确测试计划以及测试内容，这也是我们团队今后要改进的方向。