第6章 从编程到工程
第一节：语言只是工具
要认清代码、方法、过程与组织的关系。看清这一切的第一步即是”语言只是工具“。而猿之于为人”学会制作和使用工具“是最重要的标志。
第二节：程序
”程序=数据+算法“是编程的本源定义，也是原始的状态。与代码相关的任何工作，最终仍旧会落足于这样的一条规则。而编程的精义也在于此。并且从有开发行为开始，它就已经存在了，并且愚公以及十几万年前的智人，也在循环与分支所构成的逻辑中打转。
第三节：方法
推动这种逻辑向前发展的是“方法”和“方法论”的出现。随着长期的编程实践。自然的归演与总结，出现了“过程”、“对象”以及相关的方法论。这些都是实践的成果，并不是某个人或者某个组织创造的。
方法并不神秘，就是你现在正在做的、从事的和实现的。例如“模式”就是一种方法，模式就是你昨天书写代码的那个行为。只是Gog归纳、抽取、提升了这些行为的内在规律。模式需要一定的编程经验才能理解。而理解过程也需要编程经验，理解对象也需要编程经验，理解MDA与SOA同样需要编程经验。经验则来源于回顾、理解与分析，而不是你将要写的下一行代码。
第四节：过程
过程伴生工程而出现。过程解决的是工程中角色间的关系问题。过程说的是很多人（团队）如何组织一起进行开发的问题。它首先把工程的环节分解出来。从而有了环节，有了角色，有了沟通。具体的编程行为即具体的项目决定了环节的重要性。
角色的确定，以及角色间的沟通问题，在项目过程中也同样重要，工程组织是否合理，相互协作是否紧密，是项目成功的保障。
“合作无间”通常是流于书面报告中的措辞。真正的“无间”，应当是沟通的结果。UML则可能是你与客户，以及项目经理与开发人员被“离间”的第一因素。
第五节：工程
狭义的工程，是，描述“做什么”和“做到什么”。即是对目标的描述和成果的检测。工程目标的实现，是“过程”和“方法”的事；有效、快速地实现“”过程”和“方法”所需的是“工具”。
项目的“复杂”可能要求不同的知识领域的角色参与，而“庞大”则要求更多的（人力、技术与管理）资源。“团队”作为开发行为的模式，是软件规模与复杂度渐次累积的结果。
第六节：组织
工程理论包含组织学。作为项目经理必须更关注对工程的组织与计划。
需要为项目的各个阶段建立计划，并逐渐地细化计划的内容，以及确立项目过程中每一个环节、每一个计划阶段的优先级和复杂度； 确立项目或者产品阶段目标，成果的准确描述、定位，以及整个项目的质量目标及其评核办法；对团队中的不同角色展开培训，以指导并协调角色间的工作，从而消除因为工作习惯的差异带来的影响；为每一个人准备他所需要的资源，这不单单是把一套shareware变成正式版或者把512M内存变成2G，还包括准确地评估他的工作量，以及决定是否为他增加一个(能协同工作的)副手；决定在哪些环节上反复审核和回顾，而在哪些环节上采用较为宽松的方式以加快进度；习惯于开会、组织更短而有效的会议以及建立激励机制，当然也不要忘记让每一个成员意识到这一项目的风险； 不要乐观。
第七节：BOSS
BOSS在公司中解决的使“经营”问题。是在比“组织”更靠外侧的一层。他与“工程”并没有什么关系。BOSS决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策的构架下的一个具体行为。
第八节：上帝之手
实现是软件开发的本质需求。方法是对既有行为的归纳总结，所以实现方法是最先出现的，然后才有分析和设计方法。而面向对象分析、设计与编程的出现顺序，与其在工程过程中的实现顺序正好相反，与编程实践行为的顺序则正好相同。
为了实现更大规模的软件系统而有了团队组织模式，而团队的协作决定了过程模型的产生，在过程环节中的沟通问题导致了(模型化)语言的出现。
工具的产生仍旧是出于“（软件)实现”的需要。软件工程的体系中，“实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。