关于《构建之法》读后感

关于《构建之法》读后感

翻开《构建之法》，第一眼看到的是其余读者对该书的读后感觉评语，看了这些评语便引发了个人好奇心，这本书真有他们说的那么好？软件工程留给个人印象说比较枯燥无味的，那么一本关于软件工程的书即使写的再生动形象始终逃不开枯燥不是？但是书评却偏偏相反，这让我有一种想探究竟的冲动在无形中被勾起了。

看了，发现该书真如其余读者反馈的同样，该书是一本写的有血有肉的，具备强大的实用性及超级趣味性，生动形象的让人很容易读懂的书。

该书的内容主要以设置情景，采用一问一答的形式为软件开发测试等各领域的一些常见问题用最简单的文字回答，对于一些比较难懂的概念性较强的专业名词也会以故事或情景及咱们生活中的小例子来解释，让咱们能够在轻松简单的文字或例子中明白其深意。

如在书中第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等问题进行开会诊断讨论解决，那么该组的工做会和软件测试人员的工做起冲突吗？该组诊断讨论解决的问题是对软件测试后遗留下来的问题吗？