当我准备来看这本书的时候，我并没有着急的就去翻文章的内容。因为我平常看书的习惯，所以我首先先看了一遍《构建之法》这本书的目录、序言甚至读者反馈。在认真的阅读了一番之后，我觉得书中序言的第一版读者反馈是我看完整本书后比较欣赏的一个亮点。
《构建之法》这本书让我觉得写这本书的作者一定是个饱经风霜、经验十分丰富的程序员，也是一个对于美有苛刻追求的文艺学者。书中无时无刻都充满着文艺气息。巧妙地将文艺和枯燥的编程完美的融合在一起，并结合经验用很通俗的文字表达出来。书中图文并茂，而且图片都十分的有趣又有新意，不是一本无趣枯燥的普通的教学用书。书中有举了很多的例子，还有用很多的外号代号，还有一些新闻、生活中的事例都通过邹欣老师和我们的软件工程联系在了一起。比如第八章的老人家环游中国骑行的例子；第十章的剪头发的图片例子。都可以看出邹欣老师是很用心的出了这本书。
构建之法的内容主要以设置情景，采用一问一答的形式为软件开发测试等各领域的一些常见问题用最简单的文字回答，对于一些比较难懂的概念性较强的专业名词也会以故事或情景及我们生活中的小例子来解释，让我们可以在轻松简单的文字或例子中明白其深意。
《构建之法》该书文理思路分析清晰，简单生动易懂，很适合我们这些还不是很专业的人。
读完《构建之法》之后我还是有以下这些问题不是很清楚：
在书第4章两人合作75页中提到的极限编程（即结对编程），是指一对程序员互补开发工作，但是在书的78页中提到这一队的工作可以定期交换角色，可是如果这对成员中的一个编写了软件的代码，突然间装换角色，另一人要接他的代码往下写，毕竟不是自己的代码，多少都得浏览代码需要熟悉代码的过程，那么这过程不就浪费了时间吗？
在书第5章团队和流程中，介绍了很多团队模式和开发流程模式，面对这么多的团队模式和开发流程，我们面对自己的项目应如何选择？团队的模式和开发流程两者的选择有什么必然联系吗？一般情况下是先选择团队模式还是开发流程？
在书第9章项目经理中，一直都是围绕着PM展开的，其中PM分为Project Manager和Program Manager（微软），那么在其他公司会设立Program Manager吗，或者说一家公司会同时设立Project Manager和Program Manager吗？
在书第13章用户体验中，提到的用户体验的软件产品是不是开发这先根据用户需求而开发出的软件快速原型（书第6章164中提到的）？再根据用户的体验的满意度进行完善软件的产品？
在书第15章稳定和发布阶段中第306页的15.1.2会诊小组，书中提到是由软件团队的各组成员组成队软件的bug等问题进行开会诊断讨论解决，那么该组的工作会和软件测试人员的工作起冲突吗？该组诊断讨论解决的问题是对软件测试后遗留下来的问题吗？