编程离软件工程有多远？

　语言只是工具
　　我曾经是非常执著的开发人员。我有连续几天几夜 Coding 的经历，也曾经为了一个技术问题耗上三四个星期而导致项目一再延迟，还曾经为了一个实现细节与项目相关的人员逐一争论。
　　我也曾经像大多数的开发人员一样热衷于争论语言之间孰优孰劣。我在“Delphi大富翁论坛”上写过一个简介，其中个人特长是“擅长 Turbo Pascal、Delphi、TASM 系列语言，痛恨 C/C++。（凡见有价值之 C 代码，先读通，后写成Pascal/Delphi，最后骂一句：C 写得真笨！）”。我至今保留这段文字，因为那的确是真实的经历。
　　如今我已经不再专注于语言，正如我在第一章中写到的一样：成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的。
　　然而就在我写这段文字之前的一年，我还在写《Delphi 源代码分析》，我还在无休止地深入语言的细节，深入操作系统的细节，以及深入……开发的细节。
　　就在 2004 年 3 月间，我接受一个朋友的邀请，去北京做一个名为“Delphi &Delphi .NET 源码分析”的专题培训。我用了近两周的时间，做了 50 页的幻灯，全面讲述 Delphi 和 Delphi .NET。然而在临行前的一晚，我辗转反侧，一直在思考一个问题：我究竟做了些什么？或者说，我究竟想告诉学员些什么？
凌晨 5 点，我在幻灯的末页后面插入了一张幻灯，标题是“语言只是工具”，而幻灯的内容是下面这样一张图。
　　这是与培训完全无关的一张幻灯。然而，这是我自 1997 年接触到管理，以及 1998年接触到工程以来，第一次正视“软件工程”这四个字。我第一次看清楚代码、方法、过程、工程与组织的关系！　对于一个程序员，或者以程序员自命的人来说，看清楚这一切的第一步，竟是一句“语言只是工具”！猿之于为人，“学会制作和使用工具”是最重要的标志。因而我不知道“语言只是工具”这句话，究竟是对语言的膜拜，还是漠视。
　　然而从那一刻开始，我才真正地知道工程。过程
　　过程伴随工程而出现。过程解决的是工程中角色间的关系问题。
　　过程说的是很多的人（团队）如何组织在一起进行开发的问题。它首先把工程中的环节分解出来。这样，有了环节，就有了角色；有了角色，就有了沟通。
　　因此过程中的问题，就是角色、沟通和环节的问题。哪些环节重要，取决于具体的编程行为，也就是具体的项目。
　　例如产品开发的周期可以一再拖延，因为对产品来说，更重要的是品质和技术壁垒。因此你可以看到暴雪公司（Blizzard）的游戏总是一再跳票，而它从来都是将大幅的玩家测试和开发人员的个性特征放在第一位。与此相同，DOOM 与 QUAKE 系列的灵魂就是在游戏引擎的开发和设计上。
　　如果用这样的模式去做项目，可能软件公司没死掉，工程需求方也被拖死掉了——你有看见客户因为你对技术的远景描述而憧憬吗？不，你只会看到他们因为项目的一再延迟而懊恼、沮丧，或……暴怒。
　　憧憬这种事情，只会发生在那些铁杆玩家的身上。
　　分不清玩家与客户的区别，对项目经理来说，是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。
　　角色的确定，以及角色间的沟通问题，在项目过程中也同样重要。工程组织是否合理，相互的协作是否紧密，是这个项目能否成功的保障。
　　“合作无间”通常是流于书面报告中的措辞。真正的“无间”，应当是沟通的结果。然而 UML，则可能是你与客户，以及项目经理与开发人员被“离间”的第一因素。