1.
对于一个程序员，或者以程序员自命的人来说，看清 楚这一切的第一步，竟是一句“语言只是工具” ！
猿之于为人，“学会制作和使用工具”是最重要的标 志。因而我不知道“语言只是工具”这句话，究竟是对语 言的膜拜，还是漠视。 然而从那一刻开始，我才真正地知道工程。
方法并不神秘，因为它就是你今天正在做的、从事的 和实现的。正如“模式”是一种方法，而模式就是你昨天 书写代码的那个行为。
“合作无间”通常是流于书面报告中的措辞。真正的 “无间”，应当是沟通的结果。
于这个 工程目标的实现，是“过程”和“方法”的事；而有效、 快速地实现“过程”和“方法”所需的，就是“工具” 。
即使你做好这一切，可能项目的结果仍然不够理想。 但是你应该知道，好的项目经理并不是不犯错误的人，而 是以尽可能少的失败来获得成功的那个人。 无论是你的团队成员，还是你的老板，对重复的错误 以及可预料的错误都是不会宽容的。——在一个团队中， 失去了组员的信任比失去老板的信任更为可怕。 所以回顾每一个项目，或者项目中的每一个阶段，以 及与每一个团队成员交流的细节，是你的日常工作。
BOSS(经营者)决定了一个方向，组织者保证决策与 这个方向是同步的，而工程是在这样的一个方向、决策的 构架下的一个具体行为。 工程中没有 BOSS。
2.
大公司们在标准、理论、语言上的争来夺去，未必全 然出于“软件实现”的考虑。对统一理论、统一工具、统 一过程的企图，其最终目的是在整个软件工程体系中的全 面胜出。 算盘上的绝大多数人，只是用于计算胜负的一枚算 子。
在“程序”与“方法”层面， 是关注于“(具体的)实现”的；而在“过程”和“工程” 层面，更首要考虑的是团队问题。从角色的角度上来说： 开发经理思考项目的实施方案和管理具体的开发行为；而 项目经理则保障团队的稳定性和一致性。 然而这只是基本模式，或者说，是理想模式。
不计成本的项目计划不会得到经营者的支持； 毫无目的地消耗成本是项目中的慢性毒药； 最致命的风险是成本的枯竭。
3.
工具、方法与过程也被称为软件 工程的三个要素。而实质上，你应 该回归到软件工程的本体上来思考问题，而不是仅关注于 每一个局部的要素。
在工程中使用 UML 图，应该有相应的文字来描 述它。而且这种描述与图之间的对应关系要持续地维护下 去。如果这种关系松散了、断裂了，那么下一个阅读 UML 图的人所面对的，将是无异于甲骨文出土时的困境。
经营者离开发者很远，反之亦然 ，项目经理这个中间角色就有了一种使命：协调 经营者与开发者之间的沟通。
如果原定的目标(的整体)本身就过大，那么无论如何 平衡这三者之间的关系，其结果仍旧是保障不了质量。
只好用最笨的方法提示管理者：别管它是细节 还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点 回头。 用脚趾去感觉，有时比用头脑去思维来得有效。
“知律而变”中的“律”字，若解释作“规律”，那 么便是可以用于软件工程中的了。“道”是规律，如果明 “道”，而可以变化无穷，这样做软件工程才是活的。就 如同今人难于填词一样，不明道，则不明智，不明智则无 所以为，因而在软件工程实施中不可避免的盲目与停滞。
死读一本《软件工程》的人不会做真正的软件工 程。
个人感受：
（1）过去总把编程语言想的太过重要，团队的协调也有一定的问题
（2）容易造成团队的崩溃，通过阅读这几章提到的我意识到团队沟通的重要性
（3）在今后的的与团队的交流中，更注重与队员的沟通，语言是工具，并不是工程的全部