协同软件工程语言

文：鼎捷ERP

作者：鼎捷数智 | 发布时间：2012-11-30 14:50:34

第一节语言只是工具
    我曾经是非常执着的开发人员。我有连续几天几夜Coding的经历，也曾经为了一个技术问题耗上三四个星期而导致项目一再延迟，还曾经为了一个实现细节与项目相关的人员逐一争论。
    我也曾经像大多数的开发人员一样热衷于争论语言之间孰优孰劣。我在‘‘Delphi大富翁论坛”上写过一个简介，其中个人特长是“擅长TurboPascal、Delphi、TASM系列语言，痛恨C／C++。 (凡见有价值之C代码，先读通，后写成Pascal／Delphi，较后骂一句：C写得真笨!)”。我至今保留这段文字，因为那的确是真实的经历。
    如今我已经不再专注于语言，正如我在第一章中写到的一样：成天讨论这门语言好，或者那门语言坏的人，甚至是可悲的。
    然而就在我写这段文字之前的一年，我还在写《Delphi源代码分析》，我还在无休止地深入语言的细节，深入操作系统的细节，以及深入……开发的细节。
    就在2004年3月间，我接受一个朋友的邀请，去北京做一个名为“Delphi&Delphi．NET源码分析”的专题培训。我用了近两周的时间，做了50页的幻灯，全面讲述Delphi和Delphi．NET。然而在临行前的一晚，我辗转反侧，一直在思考一个问题：我究竟做了些什么?或者说，我究竟想告诉学员些什么?
    凌晨5点，我在幻灯的末页后面插入了一张幻灯，标题是“语言只是工具”，而幻灯的内容是下页的那张图。
这是与培训完全无关的一张幻灯。然而，这是我自1997年接触到管理，以及1998年接触到工程以来，第一次正视“软件工程”这四个字。我第一次看清楚代码、方法、过程、工程与组织的关系!
对于一个程序员，或者以程序员自命的人来说，看清楚这一切的第一步，竟是一句“语言只是工具”!
猿之于为人，‘‘学会制作和使用工具”是较重要的标志。因而我不知道“语言只是工具”这句话，究竟是对语言的膜拜，还是漠视。
然而从那一刻开始，我才真正地知道工程。
第二节关注点
    在前面的模型图中，每一条纵向的细线用于定义一个关注点。我在另一次培训中为这些关注点加上了标注：
这被我命名为协同软件工程层状模型(EHM，Engineering Hierarchy Model)。EHM模型不描述工程元素间的关系，甚至在试图割裂这些元素，以使得工程角色定位及各自的视角更加清晰明确。从这个模型中可以看到，在‘‘程序”与“方法”层面，是关注于“(具体的)实现’’的；而在‘‘过程’’和“工程”层面，更首要考虑的是团队问题。从角色的角度上来说：开发经理思考项目的实施方案和管理具体的开发行为；而项目经理则保障团队的稳定性和一致性。
第三节程序
    EHM模型图中，在较内层的环里，是“程序：算法+结构”。这是编程的本源定义，也是原始的状态。与代码相关的任何工作流程，较终仍旧会落足于这样的一条规则。
    编程的精义在于此。从有开发行为开始，它就存在了。愚公在数千年前就在用类同的行为做编程实践，而几十万年前的智人，也在循环与分支所构成的逻辑中打转。
第四节方法
    推动这种逻辑向前发展的，是“方法”和“方法论”的出现。长期的编程实践，自然的归演与总结，必须沉淀为某种(软件开发)方法，于是“过程”出现了，于是“对象”出现了，于是相关的方法论也就出现了。
这是实践的成果。方法不是某个人或者某个组织创造的。瓜熟而蒂落，实践积累达到一定的程度，微软不提出某个方法，IBM也会提出这个方法。即便他们都不提出，可能你自己已经在使用这个方法了。
方法并不神秘，因为它就是你今天正在做的、从事的和实现的。正如“模式”是一种方法，而模式就是你昨天书写代码的那个行为。只不过，GoF归纳、抽取、提升了这些行为的内在规律。    、
你看不到你做事的行为，也就不能理解“模式”作为一种方法的价值。所以大师们众口一词：模式需要一定的编程经验才能理解。
同理，理解过程也需要编程经验，理解对象也需要编程经验，理解MDA(模型驱动架构)与SOA(面向服务的体系结构)还是需要编程经验。——这可能就发生在你去回顾你的上一行代码编写的经过，或者上一个项
目失败的经历的那一瞬息。经验来源于回顾、理解与分析，而不是你将§写的下一行代码。
有人在寺院扫了一辈子的落叶而得道，也有人因为一句话而得道。
GoF因为无数次的代码回顾而得道。
第五节过程
    过程伴生电子商务工程而出现。过程解决的是工程中角色间的关系问题。
    过程说的是很多的人(团队)如何组织在一起进行开发的问题。它首先把工程中的环节分解出来。这样，有了环节，就有了角色；有了角色，就有了沟通。
    因此过程中的问题，就是角色、沟通和环节的问题。
    哪些环节重要，取决于具体的编程行为，也就是具体的项目。
    例如产品开发的周期可以一再拖延，因为对产品来说，更重要的是品质和技术壁垒。因此你可以看到暴雪公司(Blizzard)的游戏总是一再跳票，而它从来都是将大幅的玩家测试和开发人员的个性特征放在第一位。与此相同，DOOM与QUAKE系列的灵魂就是在游戏引擎的开发和设计上。
    如果用这样的模式去做项目，可能OA软件公司没死掉，工程需求方也被拖死掉了——你有看见客户因为你对技术的远景描述而憧憬吗?不，你只会看到他们因为项目的一再延迟而懊恼、沮丧，或……暴怒。
    憧憬这种事情，只会发生在那些铁杆玩家的身上。
    分不清玩家与客户的区别，对项目经理来说，是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。
    角色的确定，以及角色间的沟通问题，在项目过程中也同样重要。工程组织是否合理，相互的协作是否紧密，是这个项目能否成功的保障。
    “合作无间”通常是流于书面报告中的措辞。真正的“无间”，应当是沟通的结果。然而UML；则可能是你与客户，以及项目经理与开发人员被“离间”的第一因素。