在本次阅读中主要是以下部分：
作为一名大二学生，也总是不能理智的去完成学习任务在寒假放假之前，在主任给我们开寒假指导会的时候，作为过来人的他说:"具备良好的阅读能力并能够清晰的表达出来是作为一个软件工程师最基本的素质和要求。因为只有这样，我们才可以更好的读懂客户的软件需求，并按着需求更好的做好我们自己的产品。“正是这句话使我认识到了作为软件人的阅读能力的重要性。
作者邹欣总结的自己做过的项目的各自特点：
• Build To Learn：开发软件，构建系统的目的是做进一步的试验，试图发现客观规律或某个试验方法的优点与缺点。这些项目经常是科研论文的基础工作。
• Build To Show：为了突出地展现某个技术的作用，开发一些演示为目的的软件，这些项目很吸引眼球，经常获得新闻报道，但是功能未必全面。
• Build To Serve：为了服务一定范围的目标用户而构建的工具等，有时以公开的SDK形式发布。
• Build To Win：以在市场上赢得用户为目标而构建的软件。这也是种种科学发现，技术突破最好的试金石。这是我在研究院之外的十余年中做的最多的项目类型，也是这本书的英文名字。
其实非常简单的一件小事，可能就比让别人费时间。因为每个人都有惰性，而我们要做的是用理性去操控自己的惰性。只有你自己亲自去实践了，才会发现问题；只有你自己亲自动手解决了，才叫真的解决问题。
一个产品的问世以及发展状况，就如书中所说的飞机的产生类似：经历了纸飞机/飞机模型——爱好者的尝试和探索——飞机的产生与流行——带动了飞机航天航空业的发展——飞机的完善，根据实际问题进行功能的完善和安全机能的提升。但与此同时它却确又有着自己的特性：复杂性，不可见性，易变性，服从性和非连续性。除此之外，不仅讲述了软件产品和实际产品的差别，还从不同程度上介绍了软件工程和计算机科学的不同特点，以及各自的发展前景和相互之间的联系。从某种程度上说明了不同的产品在不同的领域的客户的眼里的实地可利用价值是不同的，就如此书中所说的每一辆车在出场的时候都会经过严格的功能检测，应该都是好车，不会有类似于软件中的”Bug"的存在，但是你问路人哪些车好，他们总会给出你明确的答案。有实际用处的同时又是完美的软件，在世界上是不存在的，只有顾客眼中对软件产品的满意。
第二章的内容先对第一章来说更偏向于技术性，在团队合作中，如何保证自己所负责模块的质量的稳定，这就对自身的技术和一些良好的代码书写习惯有一定的要求。这里除了之前接触的代码的整齐（段落划分），变量值和文件的命名，还有注释的要求之外，这里重新提到了一个新的名词，即单元测试。而这个单元测试必须有一定的独立性，它不依赖于别的测试，可以人为构造数据，以保证单元测试的独立性。有了个人的技术还不行，还得需要团队的合作。但是软件思想以及团队的合作并不是如此，并不是简单的叠加，应该进行系统的回合，成为“思想结晶”。一个人是可以写代码，但是写出来的都是一些比较简单的，含有很多bug的代码，团队不仅有一致的目标，而且分工还比较明确，互相依赖合作共同完成任务，这样就可以大大的提高软件的生产效率。而在第五章，此书就介绍了几种软件团队模式，不同的团队模式有不同的优势，应该根据自己的实际情况选择合适的团队模式，最大化的发挥自己的价值。
个人感受：
早在之前，大一专业分流的时候，选择软件工程就是心之所向，当时并不是跟风和一时冲动，真正想要学习一种东西，不是畏畏缩缩的去逃避。而在选择软件工程之后，作业量大也是真的，但是也真真学到了很多东西，相比于其他专业的同学来说，自己真的感受良多。
看完第一章，对软件工程有了更深的理解：软件工程是把系统化、规范化、可度量的途径应用于软件开发、运行和维护的过程。
代码的贯穿从简单到复杂会一步步的提升，就如书中所说的阿超的经历：从开始的老师以及各位家长作为客户的需求从一个简单的程序，扩展到一个满足各种功能的应用软件，再扩展到一个能保证维修的软件服务。正是说明了：做软件要从需求分析开始，一个软件或者服务要有人买，就得找到顾客，再根据顾客需求分析合理地设计、实现、测试、发布软件。这也是这个学期老师多次对我们提到的问题，要走进用户，明白他的需求，才能更好地设计、实现更好的产品。