CTO也糊涂的常用术语:功能模块、业务架构、用户需求、文档、过度设计……

潘加宇 [初稿写于2018/5/30,最近更新2021/2/17]

功能模块、业务架构、需求分析、用户需求、系统分析、功能设计、详细设计、文档、业务、技术……很多被随口使用的名词,其实是含糊甚至错误的。

到底含糊在哪里,错误在哪里,不仅仅是新手软件开发人员糊涂,许多入行多年的老手也一样。虽然很多老手功成名就,挂着CTO、总架构师等研发线的最高头衔,但是心里对这些概念也是一团浆糊。

可能有的人会说,不会吧,这些牛人带团队做出了让公司赚钱的系统,怎么会不清楚呢,只不过表达出来和你的表达不同而已吧?我只能很诚恳地再说一遍:很多“牛人”真的不清楚。当然,搞不清楚不妨碍做出赚钱的系统,就像有的人不了解人体运行机制凭感觉也活到了一百岁。您也可以说“做出过赚钱的系统就行了呗,管他清楚不清楚呢!”,对对对,您说的都对,但不清楚也还是不清楚。

何况,有些系统的成功,研发团队并不是主因。参见《互联网公司的很多“建模体会”没有价值》

我先说一下我在《软件方法》一书中对软件开发工作流的划分:

软件开发的一个迭代周期中需要思考四个问题,即四个工作流:

A-业务建模——定位需要改进的目标组织(人群或机构)以及该组织接下来最需要改进的问题。

B-需求——描述为了改进组织的问题,所引入的信息系统必须具有的表现。

C-分析——提炼为了满足功能需求,所引入的信息系统需要封装的核心域机制。

D-设计——考虑质量需求和设计约束,将核心域机制映射到选定非核心域上实现。

如图1。

工作流

图1 四个工作流

以上四个工作流的名称使用了传统术语,也有一定的模糊性(特别是业务建模)。更贴切的名称是组织建模、需求建模、核心域建模、实现。如果您觉得业务建模、需求、分析、设计不好,直呼ABCD或改成阿猪、阿狗、阿鸡、阿鸭也无所谓。

针对这些工作流的思考,其实就是建模。任何一个软件项目,这些思考都是逃不掉的,也就是说,我们一直在建模,只不过很多人习惯于无意识地做,运气时好时坏,速度时快时慢,有的人能够有意识地做,让汗水不白流。

思考的结果,可以用口头表达,也可以用文本、其他表示法或自造符号来表达。用UML来表达,目前是一种不坏的做法。如果用UML表达,推荐的用法如图2。可以看到,工作流D可以不需要用UML表达。

工作流

图2 各工作流思考内容和推荐表达

再说一下核心域和非核心域的概念。一个软件系统封装了若干领域的知识,其中一个领域的知识代表了系统的核心竞争力,是系统和其他系统区分的关键所在。这个领域称为"核心域",其他领域称为"非核心域"。更通俗的说法是"业务"和"技术",但使用"核心域"和"非核心域"更严谨。核心域不一定是物流、医疗、金融等非计算机领域,也可以是计算机和软件领域。图3展示了不同系统的核心域和非核心域概念:

coredomainexample.png

图3 不同系统的核心域、非核心域概念

好,根据以上的知识,我们来逐一剖析这些术语,可能有好几十个。

术语01:功能模块

评价:“功能”属于模糊术语,“模块”属于模糊术语,“功能模块”属于错误术语。

功能(Function)。当我们说起这个词的时候,研究对象一般是系统。对于组织,一般说“组织的服务”,对于类,一般说“类的操作”。所以,“功能”属于“B-需求”的范畴(功能需求),描述系统作为一个整体为其他系统提供的服务,把其他系统给它的输入变成其他系统所需要的输出。

但是,“功能需求”仍然不够精确。例如,以自助柜员机(ATM)为研究对象,“取现金”是“功能”,“登录”也是功能,“计算手续费”也是“功能”,到底“功能”有多大?用例的术语要严谨得多。“取现金”是一个用例,“登录”是用例中的一个回合,“计算手续费”是一个步骤。

模块(Module)。当我们说起这个词的时候,研究对象一般是系统。模块表示系统的组成部分,属于“C-分析”和“D-设计”的范畴。这个词也是模糊的。这个模块是一个控件?一个类?若干个类形成的组件?

如果说“功能”和“模块”是模糊的,那么“功能模块”就是错误的,这个词混淆了系统外部和内部的区别,需求和设计的区别。

“功能”是系统作为一个整体所需要完成的行为,“模块”是系统的内部结构。连起来说“功能模块”,意味着在意识里认为“功能”和“模块”有直接的映射关系,甚至认为“模块”是属于某个“功能”的模块,是为了完成某个“功能”而存在的。

这样的认识是错误的。如图4所示,完成某个“功能”需要若干“模块”的协作,而某个“模块”也会参与完成若干“功能”,例如可以看出“模块6”被反复使用了很多次。如果将“功能”和“模块”直接映射,系统内部将出现大量冗余。

cto04.png

图4 “功能”和“模块”的映射是多对多的

人体就是一个系统,基本功能有走路、跳跃、吃饭等,但是设计人体结构时,不能从外部直接映射到内部,得到人体由“走路模块”、“跳跃模块”、“吃饭模块”组成。人体的“模块”是五官四肢和内脏,还有最关键的——“大脑”。不管是走路、跳跃还是吃饭或者将来发展出更多的“功能”,都由这些“模块”协作完成。

那么,那些经常被称为“功能模块”的东西,应该怎么称呼合适呢?图5是百度“功能模块”得到的排第一位的图片:

cto05.png

图5 百度“功能模块”得到的排第一位的图片,来自 http://www.think58.com/asp/9182.html ,非UML图

从图5得知,“商品销售管理系统”有很多功能,其中一部分是给用户使用的,另一部分是给管理员使用的,所以很多人会说“本系统分为两大功能模块——用户模块和管理员模块”,但是这样的说法在意识里不知不觉犯了从外直接映射内部的错误,如图6。

cto06.png

图6 错误!不知不觉从外部映射到内部

还是用人举例。人有很多功能,有些是为老板提供的,有些是为老婆提供的,还有些是为老爸老妈提供的。按照图5的意思,人可以划分成“老板模块”、“老婆模块”……,错!人体确实可以划分成不同层次的“模块”(细胞→组织→器官→子系统),但是是根据内部各部件的耦合和内聚情况划分,和外面的划分没有直接的映射关系。

不能说心脏是老板的,手是老婆的。其实,不管在公司996为老板服务,还是在家里为老婆服务,都需要强大的心脏和灵活的双手。模块是大家共享的。

软件之所以复杂,或者说世界之所以复杂,就是因为需求(外)和设计(内)不是一一对应,而是多对多的。不了解这一点的,再怎么说得天花乱坠,都是错的。

有的“领域驱动设计”的文章里说到如何划分组件(当然,改了新词“上下文”、“微服务”……)时,说自己发明了新方法。一看,就是类似于图6,直接从根据外面的用户和功能来划分。碰到这种内容,就不必再往下看了。

如果要描述若干功能的集合,更贴切的术语应该是“功能包”,如图7所示。

cto07.png

图7 用需求包来表达功能集合

当然,如果您硬要说,老子就喜欢叫“功能模块”,那也可以,关键是要了解我上面说的道理。

术语02:业务架构

评价:“业务”属于模糊术语,“架构”属于模糊术语,“业务架构”属于模糊术语。

业务(Business)。“业务”这个词在软件开发团队中使用得很频繁,例如“我是一名业务架构师”、“我们要了解业务”等等,但是往往说话的人未必真的理解话中的“业务”具体指什么。

有时候“业务”指的是内容上的划分,含义是“核心域”。

例如,一个餐馆系统,订单和菜品的关系属于“业务知识”,折扣的计算规则属于“业务规则”,如图8所示。

cto08.png

图8 餐馆系统需要封装的“业务”——核心域类图

此时,和“业务”相对应的就是“技术”了。开发人员假装谦虚“我是做技术的,业务不太懂唉”,就是这个意思。甚至有的开发人员在潜意识里是这样划分的:

我懂且我感兴趣的知识→技术;(我是一名Java程序员,Java编码是技术)

我懂但不感兴趣的知识→业务;(下单、收银、配送我懂一些,但不感兴趣,这些是业务)

我不懂但感兴趣的知识→高科技;(我不懂深度学习,但很感兴趣,哇塞,高科技)

我不懂且不感兴趣的东东→忽悠。(我不懂UML建模,也不感兴趣,妈的,忽悠)

有时候“业务”指的是范围上的划分,含义是“组织级别”。例如,“业务建模”说的是组织级别的建模、“业务用例”说的是组织为其他组织提供的服务,“业务流程”说的是组织内各个系统之间协作的流程。如图9,表达了餐馆的“业务流程”。

cto09.png

图9 餐馆组织的“业务”流程

此时,和“业务”相对应的就是“系统”了。

架构(Architecture)。“架构”这个词被滥用得厉害,已经达到一砖头砸死十个架构师的地步。Martin Fowler曾经在他的书“Patterns of Enterprise Application Architecture”中写道:

The software industry delights in taking words and stretching them into a myriad of subtly contradictory meanings. One of the biggest sufferers is "architecture."

软件业乐于做这样的事——找一些词汇,并引申出大量微妙而又互相矛盾的含义。一个最大的受害者就是“架构”。

维基百科中这样描述“架构”:

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。

我的归纳:架构是多个系统内部共有的抽象机制。

要点一:内部。系统提供的各种功能,不属于“架构”。要点二:共有。架构是一种复用机制。它独立于单个系统,围绕它可以组装成系统的家族。

图10是现在常提到的一些架构。可以断定,我们会在很多软件系统中发现这样的机制。图10表达的是不同领域(UI、Database、核心域……)之间交互的机制。不管系统的核心域是哪一个(保险、物流、医疗),这样的机制都可以存在。

cto10.png

图10 域之间的架构

图11也是架构,也可以在千万个软件系统中发现这样的机制。相对于图10,图11表达的是某个领域内部各种领域概念的关系。不管将核心域概念映射到哪些非核心域上(Android还是iOS,Vue还是React)得到系统,这样的机制都可以存在。

cto11.png
cto112.png

图11 域内部的架构

太多的开发人员把过多的精力花在“域之间的架构”上,以求得心里安慰,掩盖自己没有能力思考“域内部的架构”的事实。

你给我介绍说你们团队现在用了某高大上的**架构(**可以替换为分层、菱形、五边形、六边形、洋葱型、整洁型……),好啊,我知道了。还有呢?没了?

构思那些**架构是某些平台厂商或者方法学家的工作,我们挑一个适合自己项目的套路用上就行了。有什么问题,可以去请教用这个套路用得好的先行者。

但是,“域内部的架构”,那些核心领域的复杂逻辑,你要是没有办法理清楚,别人是帮不了你的。这才是你的大脑该用的地方!

“设计要应变”,应的什么变,多半是领域逻辑的问题吧?谁没事整天把“域之间的架构”换着玩?整天津津乐道这个干什么?

在一些软件开发大会常可以看到这样的场景:某电子商务网站的架构师上台讲了一通,接着某视频网站的架构师上台也讲了一通,咦,两个演讲内容如此相似?原来,他们讲的都是自己系统中各域之间的机制(类似图 10“域之间的架构”),而不是核心域内部的机制(类似图 11“域内部的架构”)。究其原因也许并非不为,而是不能——开发人员对自己所开发系统的核心域研究太浅。许多“网红程序员 ”在网上谈论的内容大多是某种语言或框架的新特性,少有探讨他当前所开发系统的复杂领域逻辑,也是同样的原因:并非不为,而是不能。

有的“领域驱动设计”文章和课程,所举例子就1-2个领域类,然后就开始讨论Entity、Service、Repository、DTO、六边形架构……不是说这个知识没用,问题是开发团队缺的是这个嘛?

业务架构。根据以上讲述,这个词有两种含义。

含义一:组织的内部机制。此时,“业务”作“组织”解。图9就描述了这样的机制。维基百科采用的就是这种含义,如图12。此时业务架构师应该负责的是“A-业务建模”的工作。

cto12.png

图12 维基百科上关于业务架构的描述

我们再来看一些公司招聘“业务架构师”(Business Architect)的描述,有的岗位要求还比较贴近“A-业务建模”,如图13。

cto13.png

图13 业务架构师岗位描述1,来自拉勾网

也有不知所云的岗位要求,如图14。

cto14.png

图14 业务架构师岗位描述2,来自拉勾网

含义二:系统内部的核心域机制。此时,“业务”作“核心域”解。图11就描述了这样的机制。此时业务架构师应该负责的是“C-分析”的工作。

遗憾的是,在招聘网站上搜不到符合这个含义的“业务架构师”岗位。搜“架构师”可发现其岗位要求覆盖了“C-分析”和“D-设计”。上文已经说过,绝大多数的“架构师”熟悉的是“D-设计”的工作(图10),不擅长“C-分析”的工作(图11)。

术语03:用户需求

评价:“用户”属于模糊术语,“需求”属于明确术语,“用户需求”属于错误术语。

用户(User)。首先,用户默认是人,没有称某个软件系统为用户的——“本系统的另一个用户是第三方支付系统”;其次用户是和所研究系统有交互的人。例如,我正在用Word写这篇文章,我是Word的用户。以上是最常见的理解。

有时“用户”也会用在根本没有人机交互的地方,如图15。一个定时收集信息的系统,根本不需要和人交互,但需求人员也会说“用户是怎么要求的?多长时间收集一次?速度要多快?源格式和目标格式是怎样的?”此时,“用户”不是指和所研究系统交互的人,而是系统所服务的目标组织的某个负责和开发团队接口的人。例如,假设这个系统为某市国税局服务的,需求人员刚才说的“用户”可能是国税局信息中心的副主任。怎样称呼这位副主任才正确,后文再说。

cto15.png

图15 无人参与交互的收集过程

“用户”一词存在的问题:

(1)很多时候我们口中的“用户”是随意推测的。

我们来看图9的餐馆的例子。我们把它搬到图16。假设图16是餐馆的现状,餐馆的老板希望在此现状之上进一步改进。需求人员很容易先入为主,认定上面的人就是新系统的“用户”,然后逐个找这些“用户”调研。

cto16.png

图16 餐馆的现状

这样的先入为主是不对的。也许餐馆老板希望看到的改进如图17所示。从图中可以看到,领位员这个岗位都不需要了,还找他调研个啥。如果连服务员都可以不要,老板可能觉得更爽。

cto17.png

图17 对餐馆的一种改进

(2)“用户”混淆了演员和观众。

我们先来看用例(Use Case)的一些概念。如图18所示,用例把软件系统看作一部电影,演员(Actor,执行者)在台上表演,观众(Stakeholder,涉众)在台下看,观众按照他们的地位排排坐。演员在台上表演什么是由观众的口味决定的,先照顾前排的观众,如果有余力,再照顾后排的观众。

cto18.png

图18 演员(执行者,Actor)在台上表演,观众(涉众,Stakeholder)在台下看

用例使用“执行者”(Actor)和“涉众”(Stakeholder)代替了原来的“用户”,这是一个非常大的突破。“用户”这个词混淆了演员和观众的区别。过去经常说“找用户调研需求”,这是错误的。所谓“用户”,就是上台表演的人类演员。找用户调研,相当于找演员问剧本应该是什么内容,岂不是很荒谬?剧本应该由编剧向观众调研编写出来,然后由各路演员在台上演绎。

演员如果是人类,那么在观众席上也会有一个位置,不过在第几排就不知道了。范冰冰这样的大咖,可能有能力影响剧本的内容,跑龙套的就算了吧。

在台上当“用户”当得越欢的涉众,往往在涉众排行榜上排位越靠后。您想想,整天操作电脑搞得手僵脖子硬的“用户”,有几个是职位高的呢?真正位高权重的涉众,虽然偶尔也会上台表演,但更多时候是坐在台下看戏。建模人员如果过多地关注“用户”,花在重要的前排涉众身上的时间可能就不够了。

像“用户故事”这样的方法在开发一些面向大众的互联网系统时还能应付,因为这类系统的执行者往往属于前排涉众,以上问题就被掩盖了。如果开发涉众较多、利益冲突微妙的系统,应该采用用例这样更严谨的需求技能。例如做一个手机游戏,重点调研玩家这个“用户”是可以的,做一个某单位的柜台系统,也重点调研窗口工作人员(希望干活越少越好),那背后的领导和其他同事就遭殃了。

另外,现在的系统做出来,越来越多的接口不是面向人类的,而是面向另一个软件系统,也就是说没有“用户”。两个电脑系统交互的需求,难道就不用做了,或者可以随便做?非也。那只是相当于上台表演的不是人,是功夫熊猫、变形金刚和喜羊羊灰太狼,但是台下对表演说好说坏的观众依然是人。建立“执行者和系统在台上表演,涉众在台下看表演”的概念,在执行者为非人系统时对捕获需求很有帮助。

(3)“用户”是拒绝深入思考的遮羞布。

即使是演员和前排观众重叠的系统,“用户”也是一个阻拦需求人员深入思考的词汇。许多产品经理把“用户”挂在嘴边,“要从用户的角度思考”,“用户满意的才是好产品”等等,甚至还有“乔布斯不在意用户的意见”等奇谈怪论。问题来了,谁是用户?

一个老头找到PS可乐公司,告诉他们的主管,“我可是你们的忠诚客户啊!我喝过的可乐罐排成线,可以从苹果园排到通州(北京从西到东)。现在我老了,我对你们的可乐下一个版本提出如下要求:第一,我有胃病,下一个版本不要有这么多气;第二,我有糖尿病,下一个版本里面不要有糖。”PS可乐公司的主管很感动,哇,这么棒的顾客,把要求提得那么具体,省下好多我们调研需求的时间,好,下个版本就这么办!

可惜,现实生活中不会有这样的场景。老头老太太可以买可乐喝,甚至可以买给自己的宠物喝,PS可乐公司不会拦着。问题在于,老头老太太提的要求,或者为他们的宠物提的要求(注意用词:是要求,不是需求),PS可乐公司不会放在重要的位置来考虑,因为PS可乐的目标人群是青少年。可惜,很多时候我问需求人员:“可乐卖给谁?”得到的回答大多是“卖给消费者”,“卖给想喝可乐的人”等对做出好卖的可乐没有帮助的、正确而无用的废话。

我在《软件方法》中,用“老大”取代了“用户”。“老大”是一个真实存在的具体的人。定位“老大”的具体方法参见《软件方法》第2章,和Persona方法类似。但是Persona是虚构一个“用户画像”,说白了也是鼓励需求人员逃避深入第一线调研的辛苦,安心闭门造车。例如,为女性做一个产品,建模人员深入第一线调研,面对的调研对象是一个个具体的女性。如果建模人员把调研的精力花在罗玉凤身上,留给林志玲的精力就不多了,所以必须思考罗玉凤更像老大还是林志玲更像老大的问题。相比起来,关在办公室随意捏造一个符合自己要求的“女性”省事多了。如果满足于Persona,归根结底还是在内心里没有认识到深入第一线调研的重要性。

“老大”的头脑是一块块的战场,所研发的系统是一支军队。研发团队的领导是军队指挥官,他负责找到自己的军队最值得投入的战场,指挥军队和敌人厮杀,占领战场,或者防守住敌人的进攻。战局是残酷的。您手上的三万红军下一步应该杀向哪里,可选项其实少之又少,您必须竭尽全力把这个战场找出来。可惜,许多人低估了现实的残酷,意淫自己手里有百万大军,爱杀往哪里就杀往哪里。

cto19.png

图19 和对手在老大的大脑里厮杀

需求(Requirements)。明确术语,不再单独阐述。

用户需求。错误术语。需求指系统对外提供的功能性能,如果要在“需求”前面加一个定语,这个定语是“系统”——“系统的需求”。

系统的需求就像电影的剧本,规定了电影拍出来必须满足的内容,它是平衡了各种观众的口味(先照顾第一排观众,再照顾第二排……)得到的结果。对所有观众、演员来说,剧本就在那里,不会因为某个观众不喜欢其中某个情节而变化,也不会因为暂时还没有找到演员来拍成电影而变化。所以,不存在什么“用户需求”、“设计需求”、“架构需求”、“开发需求”、“编码需求”等东西。需求不是你的、我的、他的,是系统的,是你我他最终达成的关于系统的一份契约。

那么,“用户”后面能跟什么呢?可以跟“要求”。更严谨的术语是“涉众利益”。需求像电影剧本,涉众像电影观众。剧本只有一份,观众却是多种多样,不同观众的欣赏角度和口味不同。鲁迅说过:一部红楼梦,经学家看见《易》,道学家看见淫,才子看见缠绵,革命家看见排满,流言家看见宫闱秘事。

软件系统也是如此。例如一个生产执行管理系统,老大制造部王部长关注的是“缩短从接到市场部订单到交付产品的时间周期”,车间工人更关心“我这个岗位的工作量会不会增加”,库管员可能担心“以后不好搞手脚”。系统的需求首先要照顾王部长的利益,在不损害王部长利益的前提下,还有余力的话再照顾车间工人和库管员。对于实在照顾不到的后排涉众,很多时候只好抱歉了,这个系统可能会损害你的利益。

软件的需求规约相当于电影剧本。电影剧本不是由观众直接提供,而是由编剧根据不同观众的口味编出来的。同样,软件需求不是由涉众直接提供的,而是由需求人员综合不同涉众的利益来决定的。涉众没有资格提供需求。

系统的需求是平衡各种涉众利益得到的,不由单一涉众决定。以ATM机为例,如果需求人员询问ATM机的执行者储户“取款机应该怎么做你觉得最好”,储户回答大实话“最好像我家抽屉一样拉开就拿,喏,把我家里的抽屉拿去做原型”,需求人员显然不能把这个“抽屉”当真,只需要把“抽屉”背后的涉众利益提炼出来——储户希望操作次数尽可能少一些。最终系统的需求有多少尊重了这个利益,就要看储户在涉众排行榜上的排位了。

拿患者和医生类比也可以帮助理解。患者到医院对医生说“我腿疼,可能得了腿癌,我要做放疗”,医生就给他做放疗?显然不是这样,医生只能把患者所说的一切当成素材,按照成熟的套路,该做什么检查就做什么检查,该如何治疗就如何治疗。

很多时候我们想涉众调研时,涉众直接给出解决方案——“我要一个像某某软件那样的!”如果你真的按照他说的做了,他用的时候又不满意了,而且他的其他同事更不满意。然后我们还委屈呢,都是按照当时开会时你说的做的,还有录音为证!

了解到“涉众无资格提供需求,和涉众交流的内容应该聚焦于涉众利益”,可以帮助我们少犯错误。

术语04:文档

评价:“文档”属于模糊术语。

先列出使用“文档”的一些话语:

你们怎么一上手就写代码,连个文档都没有!

你现在在做什么?我在写文档。

代码就是文档。

从以上话语可以看出以下问题:

(1)在许多软件开发人员的大脑里,“文档”的意思就是“代码之外的其他工件”。由于缺乏软件工程方面的基本知识,对之前提到的“A-业务建模”、“B-需求”、“C-分析”、“D-设计”等工作流没有概念,只好把软件开发工作分为“写代码”和“写文档”两部分。(其实,就连什么叫“代码”,很多人也是糊涂的,这一点后面再说。)

(2)软件开发人员一旦把工件简单分割为“代码”和“文档”,还会导致这样的误解:认为“文档”只不过是“代码”的一种比较概要或比较形象的表现形式,不同的“文档”代表着“代码”的不同视图,可以让开发人员从不同的视角观察代码,这样就便于人脑把握代码的复杂性。如图20所示。

cto20.png

图20 误解:文档只是代码的视图

这种误解不只“普通”的开发人员会有。Martin Fowler所著的UML畅销书《UML精粹》,认为UML有三种用法:草稿、蓝图和编程语言,也是仅从编码的角度来说的。从Fowler写作的其他书籍《重构》、《企业应用架构模式》、《分析模式》等可以知道,他的研究工作集中在分析设计工作流,在业务建模和需求方面研究不多。

这样的误解就会导致推论:只要“代码”写得自己“会说话”,那么“代码就是文档”,“文档”就不需要了。本来“文档”就是“代码以外的其他东西”,这么一推,就变成了“代码就是一切”。

(3)把“文档”当作“代码”的视图还会带来下面这种思维颠倒:先拍脑袋实现,然后再从实现反推其他工作流的内容。例如下面的对话:

张三:这个不应该是系统的用例(如果您不理解什么叫“用例”,就先把它理解为“功能”好了)。

李四:是的!我都写好了,运行一下给你看,这个系统确实提供了这个用例。

是否系统的用例应该以“好卖”来判断。权衡涉众利益之后觉得应该有,系统就有,不该有就没有,而不是我写好了代码,所以就应该有。

张三:这两个类关系不应该是泛化,而是关联。

李四:是泛化,不信我打开代码给你看,或者逆向工程转出类图给你看。

是否泛化关系应该以“符合领域内涵”来判断,而不是先写好代码“人是猪的一种”(肯定编译通过),再用写好的代码来证明“人是猪的一种”。

(4)“文档”还意味着它和“代码”使用的可能是不同的工具写出来的。在Visual Studio、Eclipse里面写出来的叫“代码”,在Word、wiki、Visio、EA等等里面写或者画出来的叫“文档”。

正确的理解是:

不同工作流产出的工件之间的区别不在于形式,而在于思考和表达的内容,如图21所示。

cto21.png

图21 建模工作流思考内容

如果清楚了解“区别在于内容”这一点,就知道“我在写文档”这样的话只是表达“我正在用文档编辑工具在工作”,没有其他意义。你在写什么文档?“业务建模”?“需求”?“分析”?“设计”?我不写,我画图难道不可以吗?我不写不画,我用语音清楚地表达出组织的流程,不可以吗?更有意义的说法应该是“我在做业务建模”。如果说“文档”二字可以给您带来不可替代的快感,可以说“我在写业务建模文档”。

内容和形式的组合是灵活的。很流行的“代码就是设计”这句话的意思就是,设计工作流目前推荐的做法是不需要画UML图或者写“设计文档”,直接用源代码来表达设计模型。编码本身就是一种建模工作。计算机运行的是二进制指令,源代码实际上也是“模型”。之所以被称为“源代码”,是因为它是人脑需要编辑的最低形式模型(编辑完这个就好,后面的事情就可以交给计算机了!)。这个最低形式模型随着时代的发展不断变化。

如图21所示,最初的源代码是机器语言。程序员在纸带或卡片上打孔来表达0和1。后来发现这样太累了,于是发明了一些助记符,这就是汇编语言。 今天会有开发人员故意装×,“这些我不太懂唉,我是做底层的,用C编码”,可是C语言却被归类为“高级语言”,因为类似C这样的语言出现的时候, 大多数程序员编辑的是汇编语言,C相对于汇编来说,当然很高级。今天的一名企业应用程序员,最终需要编辑的可能有 HTML、CSS、JavaScript、Java、配置脚本、SQL等,这些就是现在的“源代码”的形式。

cto22.png

图22 “源代码”的发展历程

从图22中的“历史进程”来看,大趋势是人脑要编辑的“源代码”离计算机原来越远,离领域越来越近。至于最终什么样的具体形式能成为下一形式的代表,只好看各种语言的“个人奋斗”了。

同理,如果人脑只需要编辑UML模型就可以实现系统,那么“模型就是源代码”。例如用带有设计级调试和强大代码生成能力的工具IBM Rational Rhapsody开发实时嵌入系统,在配置好和IDE的集成之后,人脑只需要编辑和调试UML模型(主要是类图和状态机图),就可以实现系统,不需要在IDE里敲字符。感兴趣的读者可以自己去看Rhapsody附带的例子。

“代码就是设计”可以,那么“代码就是需求”可以吗?当然也可以。例如,把整个系统看作一个类,那么这个类的操作就是系统的需求,因为它表达的是系统作为整体提供的服务。

我们在使用UML建模的时候,各种建模元素和建模内容也是灵活匹配的。例如,状态机图,可能一看到就想起分析设计,其实也可以用来表达需求。图23把“电视”作为整体来画状态机,表达的就是“电视”的需求。

cto23.png

图23 用状态机图表达电视的需求(读者可以自行思考图中?处应该写什么。看起来一目了然,其实写对不容易。)

当然,不同的内容有推荐的形式。各建模工作流可以选用的建模图形以及推荐用法如前文图2所示。

术语05:过度设计

"过度设计(overdesign)"属于模糊术语。

很多人说"过度设计"的时候,说的根本不是设计问题,而是“需求蔓延(requirements creep)”。

比如,搜索引擎搜“过度设计”,第一页出来的这个文章:

图24 网络上的“过度设计”(本图仅为示意,不代表同意/不同意观点。)

按照图2的软件开发工作流分工,很多平时所说的“过度设计”,说的是B-需求,说的是花精力去做很多【用】不上功能,而不是说C和D,即系统内部怎么构造的,分解成哪些类,还是没有类全是过程,它们之间怎么互相调用的,分了多少层……

类似于“架构”、“设计模式”,“过度设计(overdesign)”一词应该也是来源于建筑。在计算机行业最早是谁使用我就不知道了,但最有名的应该是1975年 Fred Brooks的《人月神话》里“自律—第二系统效应”一节提到的overdesign:

图25 《人月神话》中的“过度设计”

Brooks说的就是工作流B-系统的需求——“使用”,不是说该系统内部如何构造。

即使是看起来真的是说“内部”的设计的,其实有可能还是需求问题,比如,网络上摘的一篇名为《软件开发-什么是过度设计》的文章里举的例子:

图26 《软件开发-什么是过度设计》截图

以上文章以为所说问题是“设计”,其实问题是,考虑了不存在的需求,跟设计过度不过度没什么关系。更何况,要是“支持美元充值、港币充值”这个需求确实存在,图中这个数据库表把各种变化频率不同的概念搅在一个表里,连“设计”都没有,跟“过度设计”还差十万八千里呢。

至于真正的“过度设计”——系统的需求是正确的,但系统内部构造精妙到过分了,呵呵,似乎我见都没见过。

见到的基本上都是伪装成“过度设计”的“没有设计”。架构师没有掌握类图、状态机图等基本的建模手段,领域逻辑都没有能力理清楚,就知道用自己懂的一点粗浅知识来凑工作量,参见《废话迷》

更糟糕的是,“过度设计”还成为拒绝思考的遮羞布——我害怕自己“过度设计”,所以干脆就不学习设计了,这样就避免了陷入“过度设计”的陷阱。

图27 电影《武状元苏乞儿》截图


weixinpanjiayu2.jpg