关于《构建之法》读后感
翻开《构建之法》，第一眼看到的是其他读者对该书的读后感受评语，看了这些评语便引起了我的好奇心，这本书真有他们说的那么好？软件工程留给我的印象说比较枯燥无味的，那么一本关于软件工程的书即便写的再生动形象始终逃不开枯燥不是？可是书评却恰恰相反，这让我有一种想探究竟的冲动在无形中被勾起了。
看了，发现该书真如其他读者反馈的一样，该书是一本写的有血有肉的，具有强大的实用性及超级趣味性，生动形象的让人很容易读懂的书。
该书的内容主要以设置情景，采用一问一答的形式为软件开发测试等各领域的一些常见问题用最简单的文字回答，对于一些比较难懂的概念性较强的专业名词也会以故事或情景及我们生活中的小例子来解释，让我们可以在轻松简单的文字或例子中明白其深意。
如在书中第11章的软件设计与实现中提到的11.5.2每日构建，一开始我看到这小标题，脑袋会想是什么东西每天都要构建？而且是需要每天构建？甚至在看到书中引用《软件业的成功奥秘》的话，“在我们的全球调查中，我们发现成功公司中有94%每天或至少每周完成构建，而不成功公司绝大多数每月甚至更少去做构建……”感觉这句有点大夸张了，甚至可以说太过抽象，无法理解每日构建的重要性。但是在这句话的下面却给出了形象生动的对话，并将建楼房的例子穿插在对话的情境中，这贴切生活实际的例子，让我们能很客观的，很容易将它与建楼房联系起来，它如建楼房时需要搭建的脚手架，因为所有的工人材料都得运上运下的，所以需要建脚手架搭建的特别的结实，因为这关乎人命。同样的道理，每日构建就是和脚手架一样，需要每天立着，倒下来就麻烦了。不会搞构建的程序员就像不会搭脚手架的小工，运球不熟悉的球员……
该书除了以这种情景设置对内容的解释分析外还设一问一答的形式，在每章里都有。如第6章敏捷流程115页~121页的6.5敏捷的问答，（如其中问：敏捷的方法论有哪些？答：比较有名的是：爱抚弟弟（FDD-Feature Driven Design ）;史克郎姆（SCRUM）;极限编程（XP）。）。这样的方式不仅对改章的内容进行了总结和扩充，还为我们读者解决了一下疑惑，同时让读者在一定程度上又对改章知识做了回顾，加深对内容的印象。
《构建之法》这本书可以说是我看过的关于软件工程有关书籍最有趣的一本，也算是我目前唯一一本可以津津有味看完的该类书籍。该书文理思路分析清晰，简单生动易懂，很适合我们这些初学者。
读完《构建之法》之后我还是有以下这些问题不是很清楚：
（1）、在书第4章两人合作75页中提到的极限编程（即结对编程），是指一对程序员互补开发工作，但是在书的78页中提到这一队的工作可以定期交换角色，可是如果这对成员中的一个编写了软件的代码，突然间装换角色，另一人要接他的代码往下写，毕竟不是自己的代码，多少都得浏览代码需要熟悉代码的过程，那么这过程不就浪费了时间吗？
（2）、在书第5章团队和流程中，介绍了很多团队模式和开发流程模式，面对这么多的团队模式和开发流程，我们面对自己的项目应如何选择？团队的模式和开发流程两者的选择有什么必然联系吗？一般情况下是先选择团队模式还是开发流程？
（3）、在书第6章敏捷流程中的敏捷的问答的第117页里提到的有名敏捷方法论：爱抚弟弟（FDD-Feature Driven Design ）和史克郎姆（SCRUM），具体是什么方法？应该怎么理解？
（4）、在书第9章项目经理中，一直都是围绕着PM展开的，其中PM分为Project Manager和Program Manager（微软），那么在其他公司会设立Program Manager吗，或者说一家公司会同时设立Project Manager和Program Manager吗？
（5）、在书第13章用户体验中，提到的用户体验的软件产品是不是开发这先根据用户需求而开发出的软件快速原型（书第6章164中提到的）？再根据用户的体验的满意度进行完善软件的产品？
（6）、在书第15章稳定和发布阶段中第307页的15.1.2会诊小组，书中提到是由软件团队的各组成员组成队软件的bug等问题进行开会诊断讨论解决，那么该组的工作会和软件测试人员的工作起冲突吗？该组诊断讨论解决的问题是对软件测试后遗留下来的问题吗？