语言只是工具，就像在第一章中提到的那句话“成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的。”语言是用来实现我们想法的工具，仅此而已。

   万变不离其宗，程序=算法+语言，是编程的本源定义，是从事代码相关的任何工作，最终仍旧会落足于这样的一条规则。

   方法是实践积累到一定程度提出的，模式是一种方法，模式需要一定的编程经验 才能理解，理解过程也需要编程经验，理解对象也需要编程经验。方法 推动程序向前发展的，是“方法”和“方法论”的出现。长期的编程实践，自然的归演与总结，必须沉淀为某种(软件开发)方法，于是“过程”出现了，于是“对象”出现了，于是相关的方法论也就出现了。你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验才能理解。 理解过程也需要编程经验，理解对象也需要编程经验，所以要掌握方法还是需要编程经验，这就是我们经常挂在嘴边的“熟能生巧”。所以学代码还是要多动手。

  做什么事都要先有个规划，先做什么，再做什么，你做什么，我做什么。这一切都需要通过角色间的沟通来解决，不仅开发团队间需要沟通，公司与客户之间也要有沟通，你要知道客户的最终期限，客户要知道你为啥跳票。（这段说的和过程有很大关系么？(我认为用规划这个词会更好一些）     

   软件规模的不断增大是工程出现的根本原因。项目的“复杂”可能要求不同的知识领域的角色参与，而“庞大”则要求更多的 (人力、技术与管理 )资源。 “团队”作为开发行为的模式，是软件规模和复杂度渐次累积的结果。从之前一个人编一个杀毒软件，而现在微软、谷歌几万人的开发团队，都证明一个事实：团队必将越来越庞大，因为软件规模必将越来越复杂。没有团队意识的软件公司将在高度过程化、通晓方法理论、拥有大量工具的集团军面前必将一触即发吧。

   过程伴生工程而出现。过程解决的是工程中角色间的关系问题。过程说的是很多的人(团队)如何组织在一起进行开发的问题。它首先把工程中的环节分解出来。这样，有了环节，就有了角色；有了角色，就有了沟通。因此过程中的问题，就是角色、沟通和环节的问题。 工程狭义上来说是描述做什么和做到什么，而这个目标的实现需要的是过程好方法，如何有效快速的实现需要的是工具，这就是简单化的软件工程体系层次图。这个层次的出现是一种必然，伴随着项目的不断复杂化可能需要更多不同知识领域的角色参与，也需要更多的人力资源，如果一个软件公司没有团队意识，在面对一个真正复杂的工程将一触即溃。项目的“复杂”可能要求不同的知识领域的角色参与，而“庞大”则要求更多的（人力、技术与管理）资源。“团队”作为开发行为的模式，是软件规模与复杂度渐次累积的结果。

BOSS(经营者)决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策的构架下的一个具体行为。工程中没有BOSS。

       实现，是软件开发的本质需求。有了这层需求，才会有人去创造模型，总结方法，开发语言。

       最后引用文中的一句话来结束：软件工程的体系中，“实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。