构建之法这本书我是从第一页开始一张一张看的，一页也没有跳过，想要从前言和读者反馈中大致了解下这本书的内容。给我的感受非常的好，所有读者反馈都给予这本书很高的评价，作者自己写的前言也很谦虚但是也体现出了他对自己作品很是满意。同时他也强调了一点，这本书不可能完全适合全部的场合和背景，所以还需要读者自己体会来领悟出自己的软件工程来才可以。
其中给我留下很多印象深刻的段子，比如对软件工程这门课应该如何来上的说明让我有很大的体会。需求分析：我们都不知道需求是什么东西，什么叫业务活动正因为这样怎么会有学习的目标？没有目标更谈不上动力了。再就拿上一个学期的UML来说，虽然这是一个很重要的科目，但是其对用户需求的建模等等都需要我们具有一定的工作阅历和代码经历才会体会，凭空的让我们画一些UML图，确实我们可以通过上网和看书画出来一些东西，并且不错，但是在我们看来也就是一些图形而已，更谈不上对其中的含义的理解。然后还有稳定阶段的敲代码过程，我应该就是属于那十分之九不知道在干什么的人，漫无目的，虽然不想混，但是确实不了解自己应该干什么。这样的课程安排看上去符合流程，但是在学生的角度能学到的东西确实是很少的。这种一泻而下的瀑布流程对学生对知识的理解和掌握帮助并不大，相反我认为还不利于学生的提高。
看到后面的“大马哈鱼洄游流程”的时候我便有一种似曾相识的感觉，就好像师傅带徒弟，打怪升级。徒弟在被师傅领进门之后便掌握了刚开始耳濡目染的一些小技能，可以干一些力所能及的事情。随着小技能的积累和拓展徒弟的技能越来越成熟，以至于他可以处理一些更加复杂的问题，骨骼惊奇的徒弟便可以成长为想曾经的师傅一样优秀甚至超过师傅，并且也可以担当起曾经师傅的角色，带领新的徒弟。这样实践出来的学问确实比书本上的知识来的更加的扎实更加的有成就感。
还有就是对老师和学生关系的理解让我很是佩服，作者把老师和学生的关系类比成教练和学员。教练在学员学习的过程中只起到指引和批评的作用，他不应该考虑学员是否能及格，以及不及格所需要承担的相应后果，这些都是学员自己应该考虑和担心的事情。如果想要进步，教练会告诉学员如何更快的提高和变强、如果想要混日子，教练也会告诉学员如何才能达到他的最低指标。这些话好像我的系主任曾经都给我们讲过，并且不止一次，可能这本书他也看的不止一次吧~他的领悟肯定更深刻！
最后看到软件工程概论就感觉有些吃力了，虽然其中的一些术语理解的不是很好，但是类比的道理也方便了我的联想。软件=程序+软件工程。由此可见软件工程不是一个个体，它需要程序作为基础的同时还需要程序遵循其中的一些道理。既然被称作软件工程，说明它指导的是一幢大厦的建成，而不是一个小厕所，所以在构建这所大厦之前我们就应该有各个步骤的构思，只有这样才不会一次次的返工重修，推倒重盖。这时我遇到了一个似曾相识的问题，阿超为儿子编写四则运算的问题，这是一个逐渐上升成了一个软件工程的问题。当时我也遇到了像阿超一样的问题，一开始怎么会想到这么一个小问题会上升成为这么大的工程呢，所以一开始分分钟敲出来的代码反而成为了之后的绊脚石，这就体现出来前期工作的重要性咯！
联想到自己实在是和具有这些思想的架构师有一段很长很长很长很长的路要走，下学期的软件工程就是这段路上的一块砖，这本书就是这段路上的路牌之一！
