按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
你到底是选择架子？还是骨子？
6。 工程不是做的，是组织的
我们总是在说“做工程”，好象工程就是面包馒头一
样，有个模子，拿来照着一堆面按上一按，放在笼屉上蒸
上一蒸，就可以“做”出来了。
经历过工程的人都知道，我们没有那个模子，而工程
中的人员也不是那一堆面。
所以我们当然不能“做”工程，而是要“组织”工程。
项目经理的工作，就是要去组织这个工程中的各个角色，
使得分工明确，步调一致，共同地完成这个项目。
…68
…………………………………………………………Page 73……………………………………………………………
第6章 从编程到工程
“得其精而忘其粗，在其内而忘其外；见其所见，不
见其所不见，视其所视，而遗其所不视。”
——《列子·说符》
1。 语言只是工具
我曾经是非常执着的开发人员。我有连续几天几夜做
Coding 的经历，也曾经为了一个技术问题耗上三、四个
星期而导致项目一再延迟，还曾经为了一个实现细节与项
目相关的人员逐一争论。
我也曾经象大多数的开发人员一样热衷于争论语言
之间孰优孰劣。我在“Delphi 大富翁论坛”上写过一个简
介，其中个人特长是“长 TPascal 、Delphi 、TASM 系列语
言，痛恨 C/C＋＋ 。（凡见有价值之 C 代码，先读通，后写
成 Pascal/Delphi ，最后骂一句：C 写得真笨！） ”。我至今
保留这段文字，因为那的确是真实的经历。
如今我已经不再专注于语言，正如我在第一章中写到
的一样：成天讨论这门语言好，或者那门语言坏的人，甚
至是可悲的。
然而就 在 我写这 段 文字之 前 的一年 ， 我还在 写
…69
…………………………………………………………Page 74……………………………………………………………
第 6 章 从编程到工程
《Delphi 源代码分析》，我还是无尽止地深入语言的细节，
深入操作系统的细节，以及深入……开发的细节。
就在 2004 年 3 月间，我接受一个朋友的邀请，去北
京做一个名为“Delphi & Delphi 源码分析”的专题
培训。我用了近两周的时间，做了 50 页的幻灯，全面讲
述 Delphi 和 Delphi 。然而在临行前的一晚，我辗转
反彻，总是在思考一个问题：我究竟做了些什么？或者说，
我究竟想告诉学员些什么？
凌晨 5 点，我在幻灯的末页后插入了一张幻灯，标题
是“语言只是工具”，而幻灯的内容是一张图：
这是与培训完全无关的一张幻灯。然而，这是自从
1997 年我接触到管理，以及从 1998 年我接触到工程以来，
我第一次正视“软件工程”这四个字。我第一次看清楚代
…70
…………………………………………………………Page 75……………………………………………………………
『大道至简』
码、方法、过程、工程与组织的关系！
对于一个程序员，或者以程序员自命的人来说，看清
楚这一切的第一步，竟是一句“语言只是工具”！
猿之于为人，“学会制作和使用工具”是最重要的标
志。因而我不知道“语言只是工具”这句话，究竟是对语
言的膜拜，还是漠视。
然而从那一刻开始，我才真正地知道工程。
2。 程序
上面的这个图中，在最内层的环里，是“程序＝算法
＋结构”。这是编程的本源定义，也是原始的状态。与代
码相关的任何工作，最终仍旧会落足于这样的一条规则。
编程的精义于此。从有开发行为开始，它就存在了。
愚公在数千年前就在用类同的行为做编程实践，而几十万
年前智人，也在循环与分支所构成的逻辑中打转。
3。 方法
推动这种逻辑向前发展的，是“方法”和“方法论”
的出现。长期的编程实践，自然的归演与总结，必须沉淀
为某种（软件开发）方法，于是“过程”出现了，于是“对
象”出现了，于是相关的方法论也就出现了。
这是实践的成果。方法不是某个人或者某个组织创造
…71
…………………………………………………………Page 76……………………………………………………………
第 6 章 从编程到工程
的。瓜熟而蒂落，实践积累达到一定的程度，微软不提出
某个方法，IBM 也会提出这个方法。即便他们都不提出，
可能你自己已经在使用这个方法了。
方法并不神秘，因为它就是你今天正在做的、从事的
和实现的。正如“模式”是一种方法，而模式就是你昨天
书写代码的那个行为。只不过，GoF 归纳、抽取、提升了
这些行为的内在规律。
你看不到你做事的行为，也就不能理解“模式”作为
一种方法的价值。所以大师们众口一词：模式需要一定的
编程经验才能理解。
同理，理解过程也需要编程经验，理解对象也需要编
程经验，理解 MDA 与 SOA 还是需要编程经验。
——这可能就发生在你去回顾你上一行代码编写的
经过，或者上一个项目失败的经历的那一瞬息。经验来源
于回顾、理解与分析，而不是你将要写的下一行代码。
有人在寺院扫了一辈子的落叶而得道，也有人因为一
句话而得道。
GoF 因为无数次的代码回顾而得道。
4。 过程
过程伴生工程而出现。过程解决的是工程中角色间的
关系问题。
过程说的是很多的人（ 团队） 如何组织在一起进行开
…72
…………………………………………………………Page 77……………………………………………………………
『大道至简』
发的问题。它首先把工程中的环节分解出来。这样，有了
环节，就有了角色；有了角色，就有了沟通。
因此过程中的问题，就是角色、沟通和环节的问题。
哪些环节重要取决于具体的编程行为，也就是具体的
项目。
例如产品开发的周期可以一再拖延，因为对产品来
说，更重要的品质和技术壁垒。因此你可以看到暴雪公司
的游戏总是一再跳票，而它从来都是将大幅的玩家测试和
开发人员的个性特征放在第一位。相应的，DOOM 与
QUAKE 系列的灵魂就是在游戏引擎的开发和设计上。
如果用这样的模式去做项目，可能软件公司没死掉，
工程需求方也被拖死掉了。——你有看见客户因为你对技
术的远景描述而憧憬吗？不，你只会看到他们因为项目的
一再延迟而懊恼，而沮丧，或……暴怒。
…73
…………………………………………………………Page 78……………………………………………………………
第 6 章 从编程到工程
憧憬这种事情，只会发生在那些个铁杆玩家的身上。
分不清玩家与客户的区别，对项目经理来说，是可怕
的。这将意味着他不能清楚地知道哪个环节更加重要。
角色的确定，以及角色间的沟通问题，在项目过程中
也同样重要。工程组织是否合理，相互的协作是否紧密，
是这个项目成功能的保障。
“合作无间”通常是流于书面报告中的措辞。真正的
“无间”，应当是沟通的结果。然而UML ，则可能是你与
客户，以及项目经理与开发人员被“离间”的第一因素。
5。 工程
最狭义的工程，是描述“做什么”和“做到什么”。
也就是说，是对目标的描述和成果的检测。至于这个
工程目标的实现，是“过程”和“方法”的事；而有效、
快速地实现“过程”和“方法”所需的，就是“工具”。
这 种 软 件 工 程 体 系 层 次 （Software Engineering
Architectural Layers）被描述成一张图，我很有幸地在第一
次画它的时候① ，画成了一堆牛屎。因此我从此都把它叫
① 在 2001 年进行一次公司的内部培训时，我在幻灯片中画下这张
图。半年后，我去北京读研时又看到了它，不过是画在《软件工
程——实践者的研究方法》这本经典巨著中，第四层的“实现对
象”是叫做“质量焦点”，名字则是“软件工程层次图”。其实所
谓“经典”也是对既有知识的总结。大师们所知的，与你所思考
的未必就有天壤之别。
…74
…………………………………………………………Page 79……………………………………………………………
『大道至简』
“牛屎图”：
工具
方法
过程
实现对象
软件工程
过程伴随工程而出现，解决的是工程中“步调一致”
的协作问题。那么工程是因为什么而出现的呢？
很显然，软件规模的不断增大是根本的原因。所以你
会看到在�