刚拿到这本书的时候，说实话脑海里就是闪过一个字眼—“厚”！于是乎就立马把它归属于教学参考书这一类型，诸如大一时候的Java设计，结结实实的大几百页被老师宠幸的页数屈指可数，愣是给我们上了满满16周的PPT。所以，惯性思维的驱使下我们都认为学校发的越厚的书本就意味着废话也就越多。然而，在一次软件测试课程上，由于翠娟老师要求我们除了课本外还要必带《构建之法》，它才真真切切的“来到”我的面前。就是第一次的翻阅让我推翻了之前有关教学参考书这个“愚蠢”的归类。
惊艳！这两个字是最起先勾起我的兴趣的，能够被安排在目录前放置的读者反馈就一定要散发出它独特的魅力。宁波大学的刘慰说从微博上的反馈来看，许多对软件开发有兴趣的同学，也正是因为这本书，又燃起了更大的兴趣和热情。果不其然，相较于其他关于软件工程的书籍，《构建之法》它的目录就更为接地气了些许，并不是一行行的专有名词，第一章的概论目录就是这么的简简单单明明白白的呈现在读者眼前：软件=程序+软件工程，紧接着就告诉我们什么是软件工程。
着眼目录，前面六章起码从字面上我能明白是什么意思，到了第七章MSF，用这么一大章来描述就必定有它的重要性。翻看这一章后，令我最为触动的是书中关于MSF团队模型的描写，众所周知一个团队最关键的就是交流，发布管理、测试、产品管理、项目管理、开发、测试、用户体验，这每一个步骤都是围绕着交流作为中心轴！发现产品的问题，然后再解决问题，不过要注意的是，我们要保证这些问题都得到“处理”和得到“解决”是不一样的，有些问题目前不能得到完美的解决，但是可以有让用户满意的处理方案，作为项目团队的我们不能回避这些问题，每个人的想法终归是会出现分歧的，在讨论处理方案时，每个人都要保证一个最基本的要求—从自己产品的质量目标出发并且对其负责。书中用诙谐的一问一答方式为读者做出了最好的解决方法。有冲突怎么办？那就吵呗。在团队中有了矛盾很是正常，憋着不说你看不惯我，我不理睬你，如此缺少了交流团队还怎么继续下去？在对立中寻找共同利益，在冲突中达到平衡。正如我们孔老夫子所曰：“君子和而不同，小人同而不和”，只要我们都是真心实意的想要一起提高用户的最大需求，争吵又怕什么呢？
才仅仅是看了一小节，就如暖流从头顶注入启发，让我不得不再次审视这本书，又重新翻回前言反馈，的确此书之厉害在于其强大得到实用性和超级的趣味性，从未见过把软件工程写的这么有意思，用对话的描述来让读者仿佛是身临其境，用俏皮的问答语句该回答时回答，该出解疑时解疑。惭愧的是，除了翠娟老师提到的第二、四章和我先前翻阅的第七章其他章节还没有读完，之后一定克制懒虫！
《构建之法》一本值得你存留在脑海里的书。
提问：
1、什么样的软件才能称为是优秀的软件？只是达到用户的需求即可吗？
2、我们要达到什么要求才能算是一个合格的软件工程师？
3、成绩能够提高，但是代码的质量停滞不前是缺少实践吗？
4、不按照开发流程开发软件可行吗？
5、在软件测试时我们要着重考虑哪些方面？实验五