这是我读《构建之法》这本书以来写的第一篇阅读笔记，先说一下自己对于阅读方面的感想吧，在读这本书之前，我在老师的要求下读过《大道至简》和《程序员修炼之道——从小工到专家》，从内心而谈，前两本书我都没有用心去读，简单的说是自我感觉那两本书与我们现在的软件工程联系不大，也许是因为我读的比较浅，还没有用到里面所说的阅读思想。
但是这本书我有用心的去看，可能进度不是很快，理解上也会很浅。因为在寒假放假之前，在主任给我们开寒假指导会的时候，作为过来人的他说:"具备良好的阅读能力并能够清晰的表达出来是作为一个软件工程师最基本的素质和要求。因为只有这样，我们才可以更好的读懂客户的软件需求，并按着需求更好的做好我们自己的产品。“正是这句话使我认识到了作为软件人的阅读能力的重要性。
怎么说呢，我在大学选专业的时候才开始接触电脑，所以在一般的电脑用处方面还比较薄弱，就像这次我开始在豆瓣上面自己找书看来说，非常简单的一件小事，我可能就比让别人费时间。这真的是验证了一句话：”只有你自己亲自去实践了，才会发现问题；只有你自己亲自动手解决了，才叫真的解决问题。“
上面说了一些无关这本书的内容，就当给自己提一个醒，日后看了可以记录记录自己的思想提升过程。说完上面那些所谓的心灵鸡汤的话，接下来就谈谈这本《构建之法》里面的重点内容。
时间安排：我习惯于晚上睡前安静的时候读一读这本书，毕竟白天的时候心乱，又在过年期间，事情繁杂。
收获和感想：
在我看这本书的推荐序的时候真的是，感觉和我们老师的教学方式有很大的相似，我们主任的观点和里面的编书者邹欣老师的观点更是不谋而合，正所谓书中所说的“风物长宜放眼量”。我们的主任更注重的是自我的独立学习能力，我们的软件工程老师也像书中邹老师所提到的那样，平时的作业量大，压力大，还按时的写博客记录自己的学习进度，还不间断的进行极限测试，但是在课程结束，我们大部分给了这门java课最高的评价，因为这门课程实践性高，效率大，我们更是受益匪浅。
看完第一章，对软件工程有了更深的理解：软件工程是把系统化、规范化、可度量的途径应用于软件开发、运行和维护的过程。
专业名词：源程序，软件架构，软件设计与实现，软件构建，源代码管理（配置管理），质量保证，软件测试，软件维护（服务运营），软件的用户体验等。
代码的贯穿从简单到复杂会一步步的提升，就如书中所说的阿超的经历：从开始的老师以及各位家长作为客户的需求从一个简单的程序，扩展到一个满足各种功能的应用软件，再扩展到一个能保证维修的软件服务。正是说明了：做软件要从需求分析开始，一个软件或者服务要有人买，就得找到顾客，再根据顾客需求分析合理地设计、实现、测试、发布软件。
一个产品的问世以及发展状况，就如书中所说的飞机的产生类似：经历了纸飞机/飞机模型——爱好者的尝试和探索——飞机的产生与流行——带动了飞机航天航空业的发展——飞机的完善，根据实际问题进行功能的完善和安全机能的提升。但与此同时它却确又有着自己的特性：复杂性，不可见性，易变性，服从性和非连续性。除此之外，不仅讲述了软件产品和实际产品的差别，还从不同程度上介绍了软件工程和计算机科学的不同特点，以及各自的发展前景和相互之间的联系。从某种程度上说明了不同的产品在不同的领域的客户的眼里的实地可利用价值是不同的，就如此书中所说的每一辆车在出场的时候都会经过严格的功能检测，应该都是好车，不会有类似于软件中的”Bug"的存在，但是你问路人哪些车好，他们总会给出你明确的答案。有实际用处的同时又是完美的软件，在世界上是不存在的，只有顾客眼中对软件产品的满意。
而第二章的内容先对第一张来说更偏向于技术性，在团队合作中，如何保证自己所负责模块的质量的稳定，这就对自身的技术和一些良好的代码书写习惯有一定的要求。这里除了之前接触的代码的整齐（段落划分），变量值和文件的命名，还有注释的要求之外，这里重新提到了一个新的名词，即单元测试。而这个单元测试必须有一定的独立性，它不依赖于别的测试，可以人为构造数据，以保证单元测试的独立性。有了个人的技术还不行，还得需要团队的合作。俗语说：“你有一个苹果，我有一个苹果，两个人在一起就会有两个苹果。”但是软件思想以及团队的合作并不是如此，并不是简单的叠加，应该进行系统的回合，成为“思想结晶”。一个人是可以写代码，但是写出来的都是一些比较简单的，含有很多bug的代码，团队不仅有一致的目标，而且分工还比较明确，互相依赖合作共同完成任务，这样就可以大大的提高软件的生产效率。而在第五章，此书就介绍了几种软件团队模式，不同的团队模式有不同的优势，应该根据自己的实际情况选择合适的团队模式，最大化的发挥自己的价值。