从编程到工程
得其精而忘其粗，在其内而忘其外；见其所见，不见其所不见，视其所视，而遗其所不视。
----《列子·说符》
在我们编程中不应该执着于分变语言的好坏，正如第一章中所说的，语言对于编程人员来说仅仅是一种用来实现程序功能的工具而已。进一言本身来说，是没有好坏之分的。他们之间的区别仅在于更适合编写什么类型的数据而已。因为程序=算法+结构；在这个经典的公式中生没有程序的存在的。
编程归结到根本只有一条定义，就是“程序 = 算法 + 结构”，无论多么复杂的程序，最终的落脚点都是这个。而且不仅是编程，任何一项工程，都可以归结于此。长期的编程实践，自然的归演与总结，必须沉淀为某种方法。方法不是某个人或者某个组织创造的。水到渠成，量变引发质变，实践积累达到一定的程度，微软不提出某个方法，IBM 也会提出这个方法。即便他们都不提出，可能你自己已经在使用这个方法了。方法其实很好理解，它就是你今天正在做的、从事的和实现的。正如“模式”是一种方法，而模式就是你昨天书写代码的那个行为。只不过，GoF 归纳、抽取、提升了这些行为的内在规律，也就形成了方法。你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。模式是需要积累一定的编程经验才能理解的。同样的，理解过程也需要编程经验，理解对象也需要编程经验，理解 MDA 与 SOA 还是需要编程经验。总之就是你需要积累一定的编程经验，只有经验多了，才能在总结分析中更好地理解——这可能就发生在你去回顾你上一行代码编写的经过，或者上一个项目失败的经历的那一瞬息。经验来源于实践、回顾、分析与总结，而不是你将要写的下一行代码。有人在寺院扫了一辈子的落叶而得道，也有人因为一句话而得道。GoF 因为无数次的代码回顾而得。
过程解决的是工程中角色间的关系问题，而工程是对目标的描述和成果的检测，工程的实现，是“过程”“方法”的事，而有效快速地实现“过程”和“方法”，所需要的就是“工具”。过程强调角色，沟通和环节问题。角色的合适分配，沟通的“无间”结果以及环节的轻重都是项目经理需要着重考虑的，而工程理论中较为重要的应是组织学，作为管理者你可以不去理会与技术相关的管理技能，但你必须关注于对工程的组织和计划。如果你不能制定合适的规划，组织你的团队协作完成任务，否则你的团队将会一击即溃。