读完《构建之法》之后最大感触莫过于程序员修炼一节，程序员在自己的领域就像武侠小说里面写的一样，每一个阶段都有难过的坎，只需要闭关冷静修炼一下子就过去了，但自己感觉不对的时候，就倒过去看看自己在那一段修炼有误，子曰：'学不可以已'的道理还是非常对的。数据结构和算法是比较重要的。大公司卖的是规范，小公司卖的产品，最小的公司卖的是服务。在大学里比较的不是学习成绩，而是个人的能力，虽然学习也是一种能力，但是其他能力不也得通过学习的来吧！通过大学里上课的确学不到啥东西，但是有些东西你知道一点也不什么都不知道强的多吧，所以我以前忽略学习是不对的。相对于读本书我得到了另外的一些感触：
一．背景差异
我是一个高职的学生，学习能力不怎么强，对我来说很多程序可能就是封装几个寄存器操作函数，然后开始写程序，写到 哪儿算哪儿。软件"腐烂"得很快，接手这种代码的第一感觉就是必须重构了它。于是，吃了很多亏，才开始琢磨是否可以"复用"一些代码，开始注意"功能"复 用，接着"框架"复用，"模型"复用。
这些意识上的转变对于学生来说，需要很长的时间，而且他们的代码量不够，没有吃过足够的亏。但是，这不能成为不重视软件思想的理由。任何涉及到软件开发的岗位，都必须有软件思想去指导实际工作。
二．"设计文档没可能写得那么细的"
这句话在很多小型的软件公司中，经常能听见。不少软件项目负责人并不重视项目初始阶段的软件详细设计文档，只是写个大概，更像是为了证明自己是"正规 军"，而走走过场。很多主导一款软件开发项目的负责人，其本人并不是一个优秀的程序员，无法真正把需求转换成相应的软件模型，无法很好地进行抽 象。
在一个项目的开发过程中，需求分析，把需求抽象成相应的软件模型，思考使用哪种设计模式，框架代码如何拥抱变化。软件工程师不能阻止需求的改变，只能最大 限度地拥抱它。软件应做到在只修改配置文件的基础上自由地扩展和裁剪功能。这些是需要在团队动手之前想好的，否则后期会很难受，尤其在项目进度压力大的情 况下，一个需求的扩展可能就搞得整个团队紧张兮兮。
三．在战争中学习战争
我最近在主导一个功率计的软件开发，时间非常紧。有点像书中关于"团队"模式中所提到的"主治医师模式"，我通过与非软件的同事反复确认需求说明书中的条 款，避免因表述不清而出现歧义，并转换成软件设计文档，文档中包括对需求的解读，如何用软件抽象该需求，软件模型是怎样的，框架设计细节。最终，使用C语 言写了个MVC模型（C语言也是面向对象的，好不好），采用"分而治之"的思路，并把繁琐的逻辑拆分成独立的"插件"，逐个击破，通过配置文件决定是否调 用某个"插件"的构造函数，实现"插件"的可插拔。
软件工程中的团队模式与足球中的战术体系，在本质上是一样的，谁动不动就强调他的个人能力，那么他一定不懂得配合队友，这是意识的问题。为了不断提高自己 的水平，突破自身的瓶颈，我采用"做中学"的态度，结合《构建之法》中的原理，指导自己的开发工作，效率提升得很快。《构建之法》之于现在的我，就像《论 持久战》之于抗战初期的中共，具有绝对的指导意义。
与之同在的，我还在我做一个Web项目的时候写的总结。