《构建之法》给我最大的感受就是在介绍软件工程的时候常常举很多生动形象的例子来增进我们对于这个科目的理解，比如第一章的飞机，第二章阿超和小飞的对话等等，下面来说说第一二十六章节的一些问题和理解感悟。
第一章：概论
问题：第一章一直在强调
软件=程序+软件工程
那么本书讲的是软件工程，也就是说我们这本书不会提到程序？
理解感悟：软件工程是把系统的，有序的，可量化的方法应用到软件的开发，运营和维护上过程。“软件工程”主要侧重于对于软件的构架，虽然构架也是由代码程序实现的，但是“程序”主要是算法和数据结构等等，两者的侧重点不一样。
第二章：个人技术和流程
这一章的名称是个人技术和流程，排版是单元测试，效能分析工具，个人开发流程，实践和练习与讨论，但是为什么测试放在首位？
理解：应该是先有个软件或者是功能，然后才能对他进行测试，还有对于大型的工程测试在企业里面一般应该会有自己的软件测试工程师。效能分析工具应该在首位，首先我们得清楚最高效的工具，然后进行开发，这时候流程显得尤其重要，然后则少不了的则是实践然后练习讨论，相比之下，测试这方面显得要弱一点，除了专门去攻克这方面人士。
第十六章：IT行业的创新
本章的名称创新本身就是一个任何时代不会消沉的词汇，不管古代还是当今时代，没有了创新，就等于原地踏步，永远不会有好的发展，所以创新则是一个非常大的一个话题。But问题来了，我们当前的思想或者技术都都是学前人大佬发现整理出来的，就这样我们都学不是太懂太深，那么我们如何踩在巨人的肩膀上去创新？又或者，我们如何踩上巨人的肩膀？
理解：创新，并不仅仅是只有成为领域的专家才能创新，而且领域的专家也不一定就一定能创新，甚至可能还不如一些专业小白。因为很多领域专家对于自己的领域一直不放弃，一直紧紧抓住自己本领域的知识去钻研，看完本领域所有前辈们写的书，反正陷进了永远不会创新的谜团中。反而一些专业小白每天可能都在思考我们这个专业到底是干啥的，会更多的从旁观者来考虑，也就是在用户方面来考虑，则反而会更大几率给我们带来创新。所以我们不必爬到巨人的肩膀上才能去想着创新。我们每个人都应该不断想着去创新，与时俱进，世界方能不断进步！