第1章 概论
（1） 高校本科的“软件工程”需求明确，方法成熟；高校研究生的“软件工程”需求不明确，方法不成熟；工业界的软件工程需求不明确，方法成熟。
（2） 书中提到公式1.1、1.2、1.3，感觉高校教学处于1.1~1.2，较少涉及1.2。想起去年在北京的一个经历，和朋友在北航附近的口福居吃火锅，旁边一桌应该是几位软件企业的负责人，他们聊的时候就说到：跟公司的技术人员沟通存在一定的困难，技术人员往往得意于解决某个问题、实现新的功能，而他们关心的则是软件中不一定复杂的盈利功能。我想这可能跟高校教学的方法存在一定的联系。
| 程序 = 数据结构 + 算法 | 1.1 |
| 软件 = 程序 + 软件工程 | 1.2 |
| 软件企业 = 软件 + 商业模式 | 1.3 |
第2章 个人技术和流程
（1） 本章开始指导读者动手实践，但出发点却是软件测试（包括单元测试和回归测试，效能分析应该也算吧）。印象中，测试作为编码的后续工作，应当置于后半部分。但是读后感觉，本书的设置还是十分合理的。个人理解为：软件正确运行是必要的，软件高效运行是重要的，而软件测试和效能分析是保证软件正确运行、高效运行的主要手段，因此首先强调软件测试和效能分析是有重要意义的。如果将软件测试相关内容置于后半部分，则容易给人感觉软件测试仅仅是软件开发的辅助流程，而使读者关注编码、忽略测试。特别是在软件工程教学中，学生不太容易清晰理解测试的重要性。将软件测试相关内容置于开始部分可以起到强调的作用。
（2） 本章2.3节表2-4对比大四学生与硕士开发人员（3年工作经验）的个人项目耗时对比。可以发现，“需求分析”和“测试”比重越来越大。个人在做软件时也有这个体会，敲代码具有成就感，由此会上瘾。但是，敲出来的代码具有什么样的功能？符不符合预定的需求？往往才是重要的问题。因此，现在更注重写代码的前后，更加考虑软件的正确性和可扩展性。
第3章 软件工程师的成长
（1） 计算机科学是一门相对较新的学科，然而，即便是类似于哲学、语言、数学、物理、建筑等历史悠久的学科，对于一个刚踏入大学校门的新生来讲，也仅仅只能从其字面上粗浅了解其含义、预见其未来。对于像我这样未进入社会、职场、公司的学生来讲，对于计算机这个行业有一定的认识，但落实到具体上可能还有很大的差距。本章对软件工程的具体执行者——软件工程师的个人能力评判方法和职业发展道路进行了一个明白的讲述，给人以自我审视、自我批评的空间。
（2） 本章3.4节第9部分有一张图，如上：刚踏入某个领域时，自己时刻在学习、进步，了解到该领域的基本思想后便感觉自己已经融汇贯通，可以解决所有问题；等到真正实施时，却发现纸上谈兵易、道路实践难；然后踏踏实实、按部就班，以解决问题为主、纸上谈兵为辅。
第4章 两人合作
（1） 本章题目为两人合作，但实际上，我感觉可以把本章前半部分拆分出来单独成章——代码规范。虽然代码规范是两人合作的重要组成部分，但是代码规范同样是团队合作的重要组成部分，并不专属于两人合作。
（2） 在高校里，我感觉较少有实际意义上的两人合作或团队合作，一个项目通常由团队的1~2人来完成。即便如此，我觉得作者如此强调代码规范的重要性（置于书中前半部分）也是很有必要的。即便是自己完成的小项目，符合统一、合理的规范也是很有必要的。书中提到了多个规范，我在平时也是尽量遵循的。其中有两点：不用tab用4个空格，不用中文用ASC2码注释。我在平时没有遵循，也因而受到了一些影响。例如，我在windows环境下编写的注释到了linux环境下变成了乱码等等。
（3） 作者在书中用两人跳舞的例子形象化的描述了两人编程，通俗易懂。我感觉两人编程最重要的还是人与人之间交流，能不能齐心协力共同做一件事情。在这个过程中，我觉得团队的负责人也应当具有相当大的责任，如何选择具有默契潜力的两人也是很不容易的。
第5章 团队和流程
（1） 团队是向量，非团队是集合。向量中的每一个位置代表一个职位，都需要一个确定的元素；集合中没有固定的位置，其中元素的数目和顺序也是不确定的。一般情况下，集合可以满足我们的需求，但是某些环境下必须使用向量完成。
（2） 团队模式像是一个图结构，团队中的人员是节点，团队人员间的关系是边。如何选择不同的节点，并为这些节点赋予不同含义、不同权重、不同方向的边是一个很有意思的研究问题。本书介绍了10中团队模式，我对其中的明星模式比较感兴趣，想想德云社，几百位相声演员，其实主要靠郭德纲来挣钱吃饭。但是，这种模式对于“明星”来说风光无限，但对于团队来说不一定是有益的。团队的成败寄托于“明星”身上，使得“明星”被赋予无限大的责任和权力。
（3） 关于流程，本人也是有一些体会的。比如，本科时组织班级同学到公园游玩，交通、游览、餐饮是都要悉心安排的。考虑到每个人有自己的爱好，如何在一天的安排中照顾到大家的爱好，同时激发对集体的热爱是需要花费心思的。这个里面，就有一些类似软件流程的问题：
如果采用“写了再改模式”，则是先带着大家去，爱玩什么玩什么，爱怎么吃怎么吃，爱怎么回来怎么回来；
如果采用“瀑布模型”，则是一起集合，一起出发，一起参观，一起就餐，一起游戏，一起回来；
如果采用“统一流程”，则是我们去那儿玩一会儿，你们去那儿玩一会儿，大家一起玩一会儿，一起吃饭；
如果采用“老板驱动的流程”，则是，班长：在这儿，坐那个，看那个，吃那个，玩那个...；
如果采用“渐进交付的流程”，则是我们先看这个，先吃这个，先玩这个，还有时间？我们再看这个，再吃这个...。
第6章 敏捷流程
（1） 看了一遍，没能理解它与传统方法的区别
第7章 MSF
（1） 每个人都想在某个方面具有话语权，在工作中也是如此。对工作内容进行划分的同时，也要赋予工人相应的权利，让工人自信、负责，提高自身的稳定性。但是也存在一个问题，如果让某个人始终具有某项权利（测试就是我的地盘儿，网页内容设计必须听我的...），会容易产生自负的心理，也会排斥新的人员。我觉得可以适当的调整赋予每个人的权利，使得每个人可以得到权利，而不会形成固定的势力。
（2） 软件开发、程序调试的时间是不确定的。因此，在软件开发过程中，我觉得首先需要完成一个可用的版本，保证随时可以交付。在此基础上，不断进行改进。如果一开始就追求完美，可能难度过高。与写文章相似，首先要有一份初稿，然后不断地检查修改。