有人在寺院扫了一辈子的落叶而得道，也有人因为一句话而得道。
GoF因为无数次的代码回顾而得道。
4. 过程
过程随生工程出现。过程解决的是工程中角色间的关系问题。
过程说的是很多人(团队)如何组织在一起进行开发。它首先把工程中的各个环节分解出来。这样，有了环节，就有了角色;有了角色，就有了沟通。因此过程中的问题，就是角色、沟通和环节的问题。
哪些环节更重要取决于具体的编程行为，也就是具体的项目。
例如产品开发的周期可以一再拖延，因为对产品来说，更重要的是其品质和技术壁垒。因此你可以看到暴雪公司的游戏总是一再跳票，而它从来都是将大量玩家测试和开发人员的个性特征放在第一位。相类同的，DOOM与QUAKE系列的灵魂就是在游戏引擎的开发和设计上。
如果用这样的模式去做项目，可能软件公司没死掉，工程需求方也被拖死。试问你有看见客户因为你对技术的远景描述而憧憬吗?不，你只会看到他们因为项目的一再延迟而懊恼，而沮丧，或……暴怒。
憧憬这种事情，只会发生在那些铁杆玩家身上。
分不清玩家与客户的区别，对项目经理来说，是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。
角色的确定，以及角色间的沟通问题，在项目过程中同样重要。工程组织是否合理，相互协作是否紧密，是这个项目成功的保障。
“合作无间”通常是流于书面报告中的措辞。真正的“无间”，应当是沟通的结果。然而UML，则可能是你与客户，以及项目经理与开发人员被“离间”的第一因素 。
5. 工程
最狭义的工程，是描述“做什么”和“做到什么”。
也就是说，是对目标的描述和成果的检测。至于这个工程目标的实现，是“过程”和“方法”的事;而有效、快速地实现“过程”和“方法”所需的，就是“工具”。
这种软件工程体系层次(Software Engineering Architectural Layers)被描述成一张图。
过程伴随工程而出现，解决的是工程中“步调一致”的协作问题。那么工程是因为什么而出现的?
很显然，软件规模的不断增大是导致软件工程出现的根本原因。所以你会看到在几年前，开发一个小工具可以不讲工程;或者现在在你的Word中，为了将半角替换成全角字符而写的那个宏，也不需要工程。
接下来，即使软件规模增大，如果有一个牛人中的超牛人，愿意用20年来写一个任意庞大和复杂的操作系统，他也是能做到的。然而现实中不会有软件公司给他这样的机会。
项目的“复杂”可能要求不同知识领域的角色参与，而“庞大”则要求更多(人力、技术与管理)资源。“团队”作为开发行为的模式，是软件规模和复杂度渐次累积的结果。
团队必将越来越庞大，因为(与工程对应的)软件规模必将越来越复杂。没有团队意识的软件公司将在高度过程化、通晓方法理论 、拥有大量工具的集团军面前一触即溃 。
文章来源于领测软件测试网 https://www.ltesting.net/
