软件工程实践者的思想(PDF格式)-第10部分
按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
京做一个名为“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……………………………………………………………
『大道至简』
“牛屎图”：
工具
方法
过程
实现对象
软件工程
过程伴随工程而出现，解决的是工程中“步调一致”
的协作问题。那么工程是因为什么而出现的呢？
很显然，软件规模的不断增大是根本的原因。所以你
会看到在几年前的时候，开发一个小工具可以不讲工程；
或者现在在你的 WORD 中，为了将半角替换成全角字符
而写的那个宏，也不需要工程。
接下来，即使软件规模增大，如果有一个牛人中的超
牛人，愿意用 20 年来写一个任意庞大和复杂的操作系统，
他也是能做到的。然而现实中不会有软件公司给他这样的
机会。
项目的“复杂”可能要求不同的知识领域的角色参与，
而“庞大”则要求更多的（人力、技术与管理） 资源。“团
队”作为开发行为的模式，是软件规模和复杂度渐次累积
的结果。
…75
…………………………………………………………Page 80……………………………………………………………
第 6 章 从编程到工程
团队必将越来越庞大，因为（与工程对应的）软件规模
必将越来越复杂。没有团队意识的软件公司将在高度过程
化、通晓方法理论① 、拥有大量工具的集团军面前必将一
②
触即溃 。
6。 组织
工程理论其实是包含组织学的。然而我在上面的那张
图中，将组织与工程分离开来，并在二者之间画下了一道
纵向的线。
① 《三十六计》更多的时候是被当成方法论来读的。其根源在于
“计谋”本身只是方法，而不是战略。
② 如今这样的战役正在国外软件与国内软件之间进行着。而战局，
并不是民族热情或者政府保护可以扭转的。
…76
…………………………………………………………Page 81……………………………………………………………
『大道至简』
如果说工程关心的是“需求”、“配置”和“文档”等
等这样一些要素，那么这样的工程还是停留在技术层面
的：关注的还是工程的实现细节，而非目标。从角色的角
度来看，这是项目经理和技术经理所共同关注的那一部
分。
然而项目经理还必须关注于人力资源、项目资金以及
多个项目之间的协调等等。这些与工程本身并没有直接关
系，而是“组织”方面的内容。
所以在工程环节中“文档管理”和“配置管理”等等
中的那个词汇“管理”，是管理的具体技术和方法；而在
“组织”这个环节中的这个“管理”，才是真正的管理学
上的用词。
我在这张图上，试图从这个角度上来说明：作为项目
经理，你必须有一部分的工作是非技术性的。甚至，你可
能绝大部分的工作是非技术性的。——因为与技术相关的
管理技能（ 需求、配置、过程管理等）可以由开发经理来做，
或者公司对于这一方面有较统一且成熟的规范，因而无需
投入过多的精力。
你必须更关注于对这个（或这些）工程的组织与计划。
站在“组织者”这个角色上，你现在要考虑的内容可能会
是：
） 为项目的各个阶段建立计划，并逐渐地细化计划
的内容，以及确立项目过程中每一个环节、每一
个计划阶段的优先级和复杂度；
） 确立项目或者产品阶段目标，成果的准确描述、
…77
…………………………………………………………Page 82……………………………………………………………
第 6 章 从编程到工程
定位，以及整个项目的质量目标及其评核办法；
） 对团队中的不同角色展开培训，以指导并协调角
色间的工作，从而消除因为工作习惯的差异带来
的影响；
） 为每一个人准备他所需要的资源，这不单单是把
一套 shareware 变成正式版或者把 512M 内存变
成 2G ，还包括准确地评估他的工作量，以及决
定是否为他增加一个（ 能协同工作的） 副手；
） 决定在哪些环节上反复审核和回顾，而在哪些环
节上采用较为宽松的方式以加快进度；
） 习惯于开会、组织更短而有效的会议以及建立激
励机制，当然也不要忘记让每一个成员意识到这
一项目的风险；
） 不要乐观。
即使你做好这一切，可能项目的结果仍然不够理想。
但是你应该知道，好的项目经理并不是不犯错误的人，而
是以尽可能少的失败来获得成功的那个人。
无论是你的团队成员，还是你的老板，对重复的错误
以及可预料的错误都是不会宽容的。——在一个团队中，
失去了组员的信任比失去老板的信任更为可怕。
所以回顾每一个项目，或者项目中的每一个阶段，以
及与每一个团队成员交流
