编程离软件工程有多远?

从编程到工程
服务器君一共花费了155.936 ms进行了4次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

文 / 周爱民

语言只是工具

我曾经是非常执著的开发人员。我有连续几天几夜 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 系列的灵魂就是在游戏引擎的开发和设计上。

如果用这样的模式去做项目,可能软件公司没死掉,工程需求方也被拖死掉了——你有看见客户因为你对技术的远景描述而憧憬吗?不,你只会看到他们因为项目的一再延迟而懊恼、沮丧,或……暴怒。

憧憬这种事情,只会发生在那些铁杆玩家的身上。

分不清玩家与客户的区别,对项目经理来说,是可怕的。这将意味着他不能清楚地知道哪个环节更加重要。

角色的确定,以及角色间的沟通问题,在项目过程中也同样重要。工程组织是否合理,相互的协作是否紧密,是这个项目能否成功的保障。

“合作无间”通常是流于书面报告中的措辞。真正的“无间”,应当是沟通的结果。然而 UML,则可能是你与客户,以及项目经理与开发人员被“离间”的第一因素。

本文地址:http://www.nowamagic.net/librarys/veda/detail/2295,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/2295

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《php和mysql web开发(原书第4版)》 Luke Welling (作者), Laura Thomson (作者), 武欣 (译者)

《php和mysql web开发(原书第4版)》将PHP开发与MySQL应用相结合,分别对PHP和MySQL做了深入浅出的分析,不仅介绍PHP和MySQL的一般概念,而且对PHP和MySQL的Web应用做了较全面的阐述,并包括几个经典且实用的例子。《php和mysql web开发(原书第4版)》是第4版,经过了全面的更新、重写和扩展,包括PHP 5.3最新改进的特性(例如,更好的错误和异常处理),MySQL的存储过程和存储引擎,Ajax技术与Web 2.0以及Web应用需要注意的安全问题。

更多计算机宝库...