大道至简——软件工程实践者的思想 第6章 从编程到工程

>>>  讀書—連接古今充實信仰  >>> 簡體     傳統

 
          第6章 从编程到工程
 
    “得其精而忘其粗,在其内而忘其外;见其所见,不见其所不见,视其所视,而遗其所不视。”
 
                                        ——《列子说符》
 
 
    1. 语言只是工具
 
    我曾经是非常执着的开发人员。我有连续几天几夜做Coding 的经历,也曾经为了一个技术问题耗上三、四个星期而导致项目一再延迟,还曾经为了一个实现细节与项目相关的人员逐一争论。
 
    我也曾经象大多数的开发人员一样热衷于争论语言之间孰优孰劣。我在“Delphi 大富翁论坛”上写过一个简介,其中个人特长是“长 TPascal、Delphi、TASM 系列语言,痛恨 C/C++。(凡见有价值之 C 代码,先读通,后写成 Pascal/Delphi,最后骂一句:C 写得真笨!)”。我至今保留这段文字,因为那的确是真实的经历。
 
    如今我已经不再专注于语言,正如我在第一章中写到的一样:成天讨论这门语言好,或者那门语言坏的人,甚至是可悲的。
 
   然 而 就 在 我 写 这 段 文 字 之 前 的 一 年 , 我 还 在 写《Delphi 源代码分析》,我还是无尽止地深入语言的细节,深入操作系统的细节,以及深入……开发的细节。
 
     就在 2004 年 3 月间,我接受一个朋友的邀请,去北
 
京做一个名为“Delphi & Delphi .NET 源码分析”的专题
 
培训。我用了近两周的时间,做了 50 页的幻灯,全面讲
 
述 Delphi 和 Delphi .NET。然而在临行前的一晚,我辗转
 
反彻,总是在思考一个问题:我究竟做了些什么?或者说,
 
我究竟想告诉学员些什么?
 
     凌晨 5 点,我在幻灯的末页后插入了一张幻灯,标题
 
是“语言只是工具”,而幻灯的内容是一张图:
 
 
 
 
     这是与培训完全无关的一张幻灯。然而,这是自从
 
1997 年我接触到管理,以及从 1998 年我接触到工程以来,
 
我第一次正视“软件工程”这四个字。我第一次看清楚代
 
码、方法、过程、工程与组织的关系!
 
    对于一个程序员,或者以程序员自命的人来说,看清
 
楚这一切的第一步,竟是一句“语言只是工具”!
 
 
    猿之于为人,“学会制作和使用工具”是最重要的标
 
志。因而我不知道“语言只是工具”这句话,究竟是对语
 
言的膜拜,还是漠视。
 
    然而从那一刻开始,我才真正地知道工程。
 
  2. 程序
 
 
    上面的这个图中,在最内层的环里,是“程序=算法
 
+结构”。这是编程的本源定义,也是原始的状态。与代
 
码相关的任何工作,最终仍旧会落足于这样的一条规则。
 
    编程的精义于此。从有开发行为开始,它就存在了。
 
愚公在数千年前就在用类同的行为做编程实践,而几十万
 
年前智人,也在循环与分支所构成的逻辑中打转。
 
  3. 方法
 
 
    推动这种逻辑向前发展的,是“方法”和“方法论”
 
的出现。长期的编程实践,自然的归演与总结,必须沉淀
 
为某种(软件开发)方法,于是“过程”出现了,于是“对
 
象”出现了,于是相关的方法论也就出现了。
 
    这是实践的成果。方法不是某个人或者某个组织创造
 
 
                                            -71- 
 
第 6 章 从编程到工程
 
的。瓜熟而蒂落,实践积累达到一定的程度,微软不提出
 
某个方法,IBM 也会提出这个方法。即便他们都不提出,
 
可能你自己已经在使用这个方法了。
 
     方法并不神秘,因为它就是你今天正在做的、从事的
 
和实现的。正如“模式”是一种方法,而模式就是你昨天
 
书写代码的那个行为。只不过,GoF 归纳、抽取、提升了
 
这些行为的内在规律。
 
     你看不到你做事的行为,也就不能理解“模式”作为
 
一种方法的价值。所以大师们众口一词:模式需要一定的
 
编程经验才能理解。
 
     同理,理解过程也需要编程经验,理解对象也需要编
 
程经验,理解 MDA 与 SOA 还是需要编程经验。
 
     ——这可能就发生在你去回顾你上一行代码编写的
 
经过,或者上一个项目失败的经历的那一瞬息。经验来源
 
于回顾、理解与分析,而不是你将要写的下一行代码。
 
 
     有人在寺院扫了一辈子的落叶而得道,也有人因为一
 
句话而得道。
 
     GoF 因为无数次的代码回顾而得道。
 
     4. 过程
 
 
     过程伴生工程而出现。过程解决的是工程中角色间的
 
关系问题。
 
     过程说的是很多的人(团队)如何组织在一起进行开发的问题。它首先把工程中的环节分解出来。这样,有了环节,就有了角色;有了角色,就有了沟通。
 
    因此过程中的问题,就是角色、沟通和环节的问题。
 
    哪些环节重要取决于具体的编程行为,也就是具体的项目。
 
    例如产品开发的周期可以一再拖延,因为对产品来
 
说,更重要的品质和技术壁垒。因此你可以看到暴雪公司
 
的游戏总是一再跳票,而它从来都是将大幅的玩家测试和
 
开发人员的个性特征放在第一位。相应的,DOOM 与
 
QUAKE 系列的灵魂就是在游戏引擎的开发和设计上。
 
    如果用这样的模式去做项目,可能软件公司没死掉,
 
工程需求方也被拖死掉了。——你有看见客户因为你对技
 
术的远景描述而憧憬吗?不,你只会看到他们因为项目的
 
一再延迟而懊恼,而沮丧,或……暴怒。
 
     憧憬这种事情,只会发生在那些个铁杆玩家的身上。
 
     分不清玩家与客户的区别,对项目经理来说,是可怕
 
的。这将意味着他不能清楚地知道哪个环节更加重要。
 
 
     角色的确定,以及角色间的沟通问题,在项目过程中
 
也同样重要。工程组织是否合理,相互的协作是否紧密,
 
是这个项目成功能的保障。
 
     “合作无间”通常是流于书面报告中的措辞。真正的
 
“无间”,应当是沟通的结果。然而 UML,则可能是你与
 
客户,以及项目经理与开发人员被“离间”的第一因素。
 
     5. 工程
 
 
     最狭义的工程,是描述“做什么”和“做到什么”。
 
     也就是说,是对目标的描述和成果的检测。至于这个
 
工程目标的实现,是“过程”和“方法”的事;而有效、
 
快速地实现“过程”和“方法”所需的,就是“工具”。
 
     这 种 软 件 工 程 体 系 层 次 (Software Engineering
 
Architectural Layers)被描述成一张图,我很有幸地在第一 
次画它的时候①,画成了一堆牛屎。因此我从此都把它叫
 
 
 
① 在 2001 年进行一次公司的内部培训时,我在幻灯片中画下这张 
图。半年后,我去北京读研时又看到了它,不过是画在《软件工 
程——实践者的研究方法》这本经典巨着中,第四层的“实现对 
象”是叫做“质量焦点”,名字则是“软件工程层次图”。其实所 
谓“经典”也是对既有知识的总结。大师们所知的,与你所思考 
的未必就有天壤之别。
 
“牛屎图”:
 
 
                        工具 
                        方法
 
                        过程
 
                      实现对象
 
 
                      软件工程
 
 
    过程伴随工程而出现,解决的是工程中“步调一致”
 
的协作问题。那么工程是因为什么而出现的呢?
 
    很显然,软件规模的不断增大是根本的原因。所以你
 
会看到在几年前的时候,开发一个小工具可以不讲工程;
 
或者现在在你的 WORD 中,为了将半角替换成全角字符
 
而写的那个宏,也不需要工程。
 
 
    接下来,即使软件规模增大,如果有一个牛人中的超
 
牛人,愿意用 20 年来写一个任意庞大和复杂的操作系统,
 
他也是能做到的。然而现实中不会有软件公司给他这样的
 
机会。
 
    项目的“复杂”可能要求不同的知识领域的角色参与,
 
而“庞大”则要求更多的(人力、技术与管理)资源。“团
 
队”作为开发行为的模式,是软件规模和复杂度渐次累积
 
的结果。
 
     团队必将越来越庞大,因为(与工程对应的)软件规模
 
必将越来越复杂。没有团队意识的软件公司将在高度过程
 
化、通晓方法理论①、拥有大量工具的集团军面前必将一
 
触即溃②。
 
 
 
     6. 组织
 
 
     工程理论其实是包含组织学的。然而我在上面的那张
 
图中,将组织与工程分离开来,并在二者之间画下了一道
 
纵向的线。
 
① 《三十六计》更多的时候是被当成方法论来读的。其根源在于 
“计谋”本身只是方法,而不是战略。
 
② 如今这样的战役正在国外软件与国内软件之间进行着。而战局,
 
并不是民族热情或者政府保护可以扭转的。
 
    如果说工程关心的是“需求”、“配置”和“文档”等
 
等这样一些要素,那么这样的工程还是停留在技术层面
 
的:关注的还是工程的实现细节,而非目标。从角色的角
 
度来看,这是项目经理和技术经理所共同关注的那一部
 
分。
 
    然而项目经理还必须关注于人力资源、项目资金以及
 
多个项目之间的协调等等。这些与工程本身并没有直接关
 
系,而是“组织”方面的内容。
 
    所以在工程环节中“文档管理”和“配置管理”等等
 
中的那个词汇“管理”,是管理的具体技术和方法;而在
 
“组织”这个环节中的这个“管理”,才是真正的管理学
 
上的用词。
 
    我在这张图上,试图从这个角度上来说明:作为项目
 
经理,你必须有一部分的工作是非技术性的。甚至,你可
 
能绝大部分的工作是非技术性的。——因为与技术相关的
 
管理技能(需求、配置、过程管理等)可以由开发经理来做,
 
或者公司对于这一方面有较统一且成熟的规范,因而无需
 
投入过多的精力。
 
    你必须更关注于对这个(或这些)工程的组织与计划。
 
站在“组织者”这个角色上,你现在要考虑的内容可能会
 
是:
 
        为项目的各个阶段建立计划,并逐渐地细化计划
 
        的内容,以及确立项目过程中每一个环节、每一
 
        个计划阶段的优先级和复杂度;
 
        确立项目或者产品阶段目标,成果的准确描述、
 
          定位,以及整个项目的质量目标及其评核办法;
 
          对团队中的不同角色展开培训,以指导并协调角
 
          色间的工作,从而消除因为工作习惯的差异带来
 
          的影响;
 
          为每一个人准备他所需要的资源,这不单单是把
 
          一套 shareware 变成正式版或者把 512M 内存变 
          成 2G,还包括准确地评估他的工作量,以及决 
          定是否为他增加一个(能协同工作的)副手; 
          决定在哪些环节上反复审核和回顾,而在哪些环
 
          节上采用较为宽松的方式以加快进度;
 
          习惯于开会、组织更短而有效的会议以及建立激
 
          励机制,当然也不要忘记让每一个成员意识到这
 
          一项目的风险;
 
          不要乐观。
 
     即使你做好这一切,可能项目的结果仍然不够理想。
 
但是你应该知道,好的项目经理并不是不犯错误的人,而
 
是以尽可能少的失败来获得成功的那个人。
 
     无论是你的团队成员,还是你的老板,对重复的错误
 
以及可预料的错误都是不会宽容的。——在一个团队中,
 
失去了组员的信任比失去老板的信任更为可怕。
 
     所以回顾每一个项目,或者项目中的每一个阶段,以
 
及与每一个团队成员交流的细节,是你的日常工作。
 
     7. BOSS
 
     很多人以为 BOSS 是给自己发钱的那个人,这其实是
 
错误的。发钱的决策通常是由三个角色来做出的:
 
        部门/团队经理。你的直接上司,他是雇佣你的
 
        人,是他用薪金的多少来衡量你的价值,或者反
 
        之。
 
        纪效经理。如果你的公司有这个角色的话,那么
 
        他总是盯着你的错误以决定从你的薪水里的扣 
        除比例①。
 
        财务经理。有钱?没钱?没钱?有钱?……
 
    BOSS 并不决定你的薪水。
 
 
    BOSS 在公司中解决的是“经营”问题。这其实是在
 
比“组织”更靠外侧的一层。——在前面的图例中并没有
 
给出,这也意味着“经营者”与“工程”基本没有关系。
 
    在一个更大规模的组织机构里,你可以会更直接地观
 
察到“经营者”与“组织者”之间的差异。例如公司的大
 
小股东是“经营者”,董事会通常是解决经营问题的地方;
 
而总经理、执行经理以及各个部门经理则是各级的“组织
 
者”,经理办公会则是解决组织问题的地方。
 
    你应该清楚,真正的BOSS是经营者②。
 
    这有助于你明确你被雇来的原因,你的工作是面向哪
 
一个层面的,以及你或者你的上司有没有权限来决定是一
 
个项目是否应该立项,或中止。
 
 
① 顺便告诉你一个秘密,给予你奖励的决定通常是你的上司,而 
不是纪效经理作出的。 
② 不过,可能你仅受雇于你的上司,你习惯于把他叫作BOOOOSS 
则是另外一回事。
 
     BOSS(经营者)决定了一个方向,组织者保证决策与
 
这个方向是同步的,而工程是在这样的一个方向、决策的
 
构架下的一个具体行为。
 
     工程中没有 BOSS。
 
 
     8. 上帝之手
 
 
     从最初的简单编程开始,到现在工程团队的组织开
 
发,实现(一个软件)都是最终的目的。所以可以这样说:
 
实现,是软件开发的本质需求。
 
 
     我们看到,正是出于实现的需要,我们才设计了一些
 
数据结构或逻辑结构来映射物理模型。因此类似于过程、
 
单元、记录(结构)、对象等的出现,其实都是出于编程实
 
现的需要:
 
 
                    程序 = 算法 + 结构
 
 
 
 
        过程与单元的出现           记录与对象的出现
 
 
 
     而后,基于某种数据结构的编程实践(的不断积累),
 
决定了软件开发方法理论的产生。
 
     从这一点可以看出:方法,是对既有行为的归纳总结。
 
     因而实现方法总是最先出现的,而后才有分析和设计
 
方法。
 
    可以看到面向对象分析(OOA)、设计(OOD)与编程
 
(OOP)的出现顺序,与它们在工程过程中的实作顺序正好
 
相反,而与编程实践行为的顺序则正好相同。
 
 
    为了实现更大规模的软件系统而有了团队组织模式,
 
而团队的协作决定了过程模型的产生,在过程环节中的沟
 
通问题导致了(模型化)语言的出现。
 
    如同编程工具中的编译器和集成开发环境(IDE)一
 
样,开发中的编程语言、过程中的模型语言都只是一种工
 
具。
 
 
           甲骨文     象棋      石头
 
 
  符号语言:文字
 
 最自然的沟通方式: 语言
 
  项目案其实是可以用甲骨文来写 
               的 
             图形也是一种符号文字
 
                          模型也是一种符号文字
 
    工具的产生仍旧是出于“(软件)实现”的需要。不可
 
能从软件开发实践中产生出轮子和指南针,因为那不是
 
“软件开发的本质需求”可以推动的。
 
 
    软件工程的体系中,“实现”作为软件开发的本质需
 
 
                                              -81- 
 
第 6 章 从编程到工程
 
求和基本动因,如同上帝之手在推动这几十年来的软件工
 
程理论体系的形成。
 
 
                    工具 
                    方法           基本
 
                    过程           动因
 
 
                  实现对象
 
 
                  软件工程

周爱民(Aimingoo) 2013-08-24 22:32:46

[新一篇] 大道至簡——軟件工程實踐者的思想 第5章 失敗的過程也是過程

[舊一篇] 大道至簡——軟件工程實踐者的思想 第7章 現實中的軟件工程
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表