语言只是工具

从编程到工程——软件工程实践者的思想（《从编程到工程》第六章）

“得其精而忘其粗，在其内而忘其外；见其所见，不见其所不见，视其所视，而遗其所不视”
——《列子 说符》

 

1. 语言只是工具
        我曾经是非常执着的开发人员。我有连续几天几夜做Coding的经历，也曾经为了一个技术问题耗上三、四个星期而导致项目一再延迟，还曾经为了一个实现细节与项目相关的人员逐一争论。
         我也曾经像大多数开发人员一样热衷于争论语言之间孰优孰劣。我在“Delphi大富翁论坛”上写过一个简介，其中个人特长是“擅长TPascal、Delphi、TASM系列语言，痛恨C/C++”。我至今保留这段文字，因为那的确是真实的经历。
         如今我已经不再专注于语言，正如我在第一章中写到的一样：成天讨论这门语言好，或者那门语言不好的人，是可悲的。
         然而就在我写这段文字之前的一年，我还在写《Delphi源代码分析》，我还是无止尽地深入语言细节，深入操作系统细节，以及深入……开发的细节。
         就在2004年3月间，我接受一个朋友的邀请，去北京做一个名为“Delphi & Delphi .NET源码分析”的专题培训。我用了近两周的时间，做了50页的幻灯，全面讲述Delphi和Delphi .NET。然而在临行前的一晚，我辗转反侧，思考着一个问题：我究竟做了些什么？或者说，我究竟想告诉学员些什么？
         凌晨5点，我在幻灯的末页后插入了一张幻灯，标题是“语言只是工具”，而幻灯的内容是一张图：

         这是与培训完全无关的一张幻灯。然而，这是自1997年我接触到管理，以及从1998年我接触到工程以来，第一次正视“软件工程”这四个字。我第一次看清楚代码、方法、过程、工程与组织的关系！
         对于一个程序员，或者以程序员自命的人来说，看清楚这一切的第一步，竟是一句“语言只是工具”！
         猿之于为人，“学会制作和使用工具”是最重要的标志。因而我不知道“语言只是工具”这句话，究竟是对语言的膜拜，还是漠视。
         然而从那一刻开始，我才真正地知道工程。

 

2. 程序
      上面的这个图中，在最内层的环里，是“程序＝算法＋结构”。这是编程的本源定义，也是原始的状态。与代码相关的任何工作，最终仍旧会落足于这样的一条规则。
编程的精义于此。从有开发行为开始，它就存在。挖山不止的愚公在数千年前就在用类似的行为做编程实践，而几十万年前的智人，也在循环与分支所构成的逻辑中打转。

 

3. 方法
         推动这种逻辑向前发展的是“方法”和“方法论”。长期编程实践，自然的推演与总结，必须沉淀为某种（软件开发）方法，于是“过程”出现了， “对象”出现了，相关的方法论也就出现了。
         这是实践的成果。方法不是某个人或者某个组织创造的。瓜熟而蒂落，实践积累达到一定的程度，就算微软不提出某个方法，IBM也会提出这个方法。即便他们都不提出，可能你自己已经在使用这个方法了。
         方法并不神秘，因为它就是你今天正在做的、从事的和实现的。正如“模式”是一种方法，而模式就是你昨天书写代码的那个行为。只不过，GoF归纳、抽取、提升了这些行为的内在规律。
你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验才能理解。
         同理，理解过程也需要编程经验，理解对象也需要编程经验，理解MDA与SOA还是需要编程经验。
         这可能就发生在你回顾上一行精彩的代码，或者上一个失败的项目的一瞬息。经验来源于回顾、理解与分析，而不是你将要写的下一行代码。
         有人在寺院扫了一辈子的落叶而得道，也有人因为一句话而得道。
         GoF因为无数次的代码回顾而得道。

 

4. 过程
         过程随生工程出现。过程解决的是工程中角色间的关系问题。
过程说的是很多人（团队）如何组织在一起进行开发。它首先把工程中的各个环节分解出来。这样，有了环节，就有了角色；有了角色，就有了沟通。
         因此过程中的问题，就是角色、沟通和环节的问题。
         哪些环节更重要取决于具体的编程行为，也就是具体的项目。
         例如产品开发的周期可以一再拖延，因为对产品来说，更重要的是其品质和技术壁垒。因此你可以看到暴雪公司的游戏总是一再跳票，而它从来都是将大量玩家测试和开发人员的个性特征放在第一位。相类同的，DOOM与QUAKE系列的灵魂就是在游戏引擎的开发和设计上。
如果用这样的模式去做项目，可能软件公司没死掉，工程需求方也被拖死。试问你有看见客户因为你对技术的远景描述而憧憬吗？不，你只会看到他们因为项目的一再延迟而懊恼，而沮丧，或……暴怒。
         憧憬这种事情，只会发生在那些铁杆玩家身上。
         分不清玩家与客户的区别，对项目经理来说，是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。
         角色的确定，以及角色间的沟通问题，在项目过程中同样重要。工程组织是否合理，相互协作是否紧密，是这个项目成功的保障。
        “合作无间”通常是流于书面报告中的措辞。真正的“无间”，应当是沟通的结果。然而UML，则可能是你与客户，以及项目经理与开发人员被“离间”的第一因素 。

 

5. 工程
         最狭义的工程，是描述“做什么”和“做到什么”。
         也就是说，是对目标的描述和成果的检测。至于这个工程目标的实现，是“过程”和“方法”的事；而有效、快速地实现“过程”和“方法”所需的，就是“工具”。
         这种软件工程体系层次（Software Engineering Architectural Layers）被描述成一张图(见下图)：

         过程伴随工程而出现，解决的是工程中“步调一致”的协作问题。那么工程是因为什么而出现的？
         很显然，软件规模的不断增大是导致软件工程出现的根本原因。所以你会看到在几年前，开发一个小工具可以不讲工程；或者现在在你的Word中，为了将半角替换成全角字符而写的那个宏，也不需要工程。
         接下来，即使软件规模增大，如果有一个牛人中的超牛人，愿意用20年来写一个任意庞大和复杂的操作系统，他也是能做到的。然而现实中不会有软件公司给他这样的机会。
项目的“复杂”可能要求不同知识领域的角色参与，而“庞大”则要求更多（人力、技术与管理）资源。“团队”作为开发行为的模式，是软件规模和复杂度渐次累积的结果。
         团队必将越来越庞大，因为（与工程对应的）软件规模必将越来越复杂。没有团队意识的软件公司将在高度过程化、通晓方法理论 、拥有大量工具的集团军面前一触即溃 。

 

6. 组织
         工程理论其实是包含组织学的。然而我在上面的那张图中，将组织与工程分离开来，并在二者之间画下了一道纵向的线。

         如果说工程关心的是“需求”、“配置”和“文档”等等这些要素，那么这样的工程还是停留在技术层面：关注的仍是工程实现细节，而非目标。从角色角度来看，这是项目经理和技术经理共同关注的那一部分。
         然而项目经理还必须关注于人力资源、项目资金以及多个项目之间的协调等问题。这些问题与工程本身并没有直接关系，而是“组织”方面的内容。
         所以在工程环节里，“文档管理”和“配置管理”等词汇中的那个“管理”，是管理的具体技术和方法；而在“组织”这个环节中的 “管理”，才是真正的管理学上的用词。
在这张图上，我试图从这个角度上来说明：作为项目经理，你必须有一部分的工作是非技术性的。甚至，你可能绝大部分的工作是非技术性的。因为与技术相关的管理技能（需求、配置、过程管理等）可以由开发经理来做，或者公司对于这一方面有较统一且成熟的规范，因而无需投入过多的精力。
         你必须更关注于对这个(或这些)工程的组织与计划。站在“组织者”这个角色上，你现在要考虑的内容可能会是：

• 为项目的各个阶段建立计划，并逐渐地细化计划内容，以及确立项目过程中每一个环节、每一个计划阶段的优先级和复杂度；
• 确立项目或者产品阶段目标，成果的准确描述、定位，以及整个项目的质量目标及其考核办法；
• 对团队中的不同角色展开培训，以指导并协调角色间的工作，从而消除因为工作习惯的差异带来的影响；
• 为每一个人准备他所需要的资源，这不单单是把一套shareware变成正式版或者把512M内存变成2G，还包括准确地评估他的工作量，以及决定是否为他增加一个（能协同工作的）副手；
• 决定在哪些环节上反复审核和回顾，而在哪些环节上采用较为宽松的方式以加快进度；
• 习惯于开会、组织更短而有效的会议以及建立激励机制，当然也不要忘记让每一个成员意识到这一项目的风险；
• 不要乐观。

         即使你做好这一切，可能项目的结果仍然不够理想。但是你应该知道，好的项目经理并不是不犯错误的人，而是以尽可能少的失败来获得成功的那个人。
         无论是你的团队成员，还是你的老板，对重复的错误以及可预料的错误都是不会宽容的。在一个团队中，失去了组员的信任比失去老板的信任更为可怕。
         所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。

 

7.BOSS
      很多人以为BOSS是给自己发钱的那个人，这其实是错误的。发钱的决策通常是由三个角色来做出的：

• 部门／团队经理。你的直接上司，他是雇佣你的人，是他用薪金的多少来衡量你的价值，或者反之。
• 绩效经理。如果你的公司有这个角色的话，那么他总是盯着你的错误以决定从你的薪水里的扣除比例 。
• 财务经理。有钱？没钱？没钱？有钱……

         BOSS并不决定你的薪水。
         BOSS在公司中解决的是“经营”问题。这其实是在比“组织”更靠外侧的一层。在前面的图例中并没有给出，这也意味着“经营者”与“工程”基本没有关系。
         在一个更大规模的组织机构里，你可以会更直接地观察到“经营者”与“组织者”之间的差异。例如公司的大小股东是“经营者”，董事会通常是解决经营问题的地方；而总经理、执行经理以及各个部门经理则是各级的“组织者”，经理办公会则是解决组织问题的地方。
你应该清楚，真正的BOSS是经营者。
         这有助于你明确你被雇来的原因，你的工作是面向哪个层面的，以及你或者你的上司有没有权限来决定一个项目是否应该立项或中止。
         BOSS（经营者）决定了一个方向，组织者保证决策与这个方向是同步的，而工程是在这样的一个方向、决策的构架下的一个具体行为。
         工程中没有BOSS。

8. 上帝之手
         从最初的简单编程开始，到现在工程团队的组织开发，实现（一个软件）都是最终的目的。所以可以这样说：实现，是软件开发的本质需求。
         我们看到，正是出于实现需要，我们才设计了一些数据结构或逻辑结构来映射物理模型。因此类似于过程、单元、记录（结构）、对象等的出现，其实都是源于编程实现的需要。

         而后，基于某种数据结构的编程实践（的不断积累），决定了软件开发方法理论的产生。
从这一点可以看出：方法，是对既有行为的归纳总结。因而实现方法总是最先出现的，而后才有分析和设计方法。例如面向对象分析（OOA）、设计（OOD）与编程（OOP）的出现顺序，与它们在工程过程中的实作顺序正好相反，而与编程实践行为的顺序则正好相同。
         为了实现更大规模的软件系统，逐渐产生了团队组织模式，而团队的协作决定了过程模型的产生，在过程环节中的沟通问题导致了（模型化）语言的出现。
         如同编程工具中的编译器和集成开发环境(IDE)一样，开发中的编程语言、过程中的模型语言都只是一种工具。

         工具的产生仍旧是出于“（软件）实现”的需要。不可能从软件开发实践中产生出轮子和指南针，因为那不是“软件开发的本质需求”可以推动的。
         软件工程体系中，“实现”作为软件开发的本质需求和基本动因，如同上帝之手在推动这几十年来的软件工程理论体系的形成。