第1章 利润＝需求－设计 #

← 返回《软件方法》

1.1 利润＝需求－设计 #

1.1.1 利润＝需求－设计 #

利润＝收入－成本。不管出售什么，要获得利润，需要两个条件：

（1）售价要高；

（2）成本要低。

妙就妙在，价格和成本之间没有固定的计算公式，这正是创新的动 力之源。

放到软件业上，我也炮制了一个式子：

利润＝需求－设计 在软件开发中，需求工作致力于解决“提升销售”的问题，设计工 作致力于解决“降低成本”的问题，二者不能相互取代。能低成本开发 和维护某个系统，不一定能保证它好卖。系统好卖，如果开发和维护成 本太高，最终利润还是高不了。 以上说的“利润”、“销售”、“成本”是广义的，可以是金钱，也可 以是名声、权力、人力等。 即使你做的是没有在市场上公开出售的单位内部系统，甚至是自己 为自己的方便做一个系统，也适用上面的式子。

更为关键的是：需求和设计之间不存在，也不应该存在刻板的一对 一映射——也幸亏如此，否则人工智能现在就可以轻易学习其中的映 射套路，取代软件开发人员完成所有的工作。目前，软件开发人员存在 的价值之一就是根据自己掌握的领域知识和软件开发知识，努力在很多 可能的映射方案中挑选出最合适的映射方案，以及创造出更好的映射方 案。

我们先来看自古以来就有的一个系统，人，即“人肉系统”。

人肉系统的功能（需求）是（人能够）走路、跑步、跳跃、举重、 投掷、游泳……但是设计人肉系统的结构时，并不是从功能（需求）直 接映射到设计，得到“走路器官”、“跑步器官”、“跳跃器官”……人肉 系统的器官是眼、耳、心、肺、肝、胃、骨架、皮肤……这些器官和人 肉系统的功能不是一一对应的，在互相协作以完成系统的功能时，它们 和功能之间的关系是多对多的。

以上所说的这些，总体意思就是：要学会把需求和设计分开，这也 是贯彻全书的核心思想，后面还会反复强调。当然，用词可能会有变化， 可能有的时候会说“卖和做分开”，有的时候会说“外和内分开”等等。

软件开发中，如果从需求直接映射设计，会得到大量的重复代码， 成本增加；如果从设计出发定义需求，会得到一堆假的“需求” ，销量 下降。不管是哪一种情况，利润都会下降。 而这一点，很多软件开发人员并没有意识到。

1.1.2 需求-设计混淆的常见错误 #

1.1.2.1 “子系统”其实是需求包 #

我们经常听到这样的说法，“本系统分为八大子系统，包括销售子 系统、财务子系统、库存子系统……”，这就是需求和设计不分的一个 例子。其实，说话人可能应该这样表达自己的意思：“本系统的功能需 求分为八大需求包……”。

需求包是基于涉众视角对系统功能分包而得到的，子系统（用 UML 的说法是组件）是基于内部视角根据系统部件的耦合和内聚情况切割而 得到的，这两者不是一一对应的。所谓的“财务子系统”，其实可能是 “把财务人员使用的功能放在一个包里”

1.1.2.2 “功能模块”是错误用语 #

另一个常见的需求和设计不分的说法是“功能模块”。

功能（Function）这个词，如果应用于信息系统，描述的是：系 统作为一个整体，接收到外部请求时应该产生的效果。

模块（Module）这个词，如果应用于信息系统，描述的是表示系 统分解后得到的各个组成部分。

“功能模块”意味着在意识里认为“功能”和“模块”有直接的映 射关系，甚至认为“模块”是属于某个“功能”的模块，是为了完成某 个“功能”而存在的。

用前面的“人肉系统”来举例，“功能模块”就是“走路器官”、“走 路子系统”……，这是错误的。

不但“功能模块”不应该连起来说，而且“功能”和“模块”这两 个词的含义也是模糊的。

例如，以自助柜员机（ATM）为目标系统，“取现金”是“功能”， “登录”也是功能“计算手续费”也是“功能”，到底“功能”有多大？ “模块”是一个控件？还是一个类？还是若干个类形成的组件？

因此，本书后文中，会尽量使用更精确的术语。例如，以 ATM 为 目标系统，“取现金”是一个用例，“登录”是用例中的一个回合，“计 算手续费”是一个步骤，系统里面可能会有一个“账户”类……。

1.1.2.3 微服务的遮羞布 #

最近几年鼓吹的新词“微服务”造成一定的误导。有的人误以为“微 服务”就是“需求设计一一对应”。

假设考虑到开发团队的结构，把系统分成多个“微服务”，分由各 个小团队应用各自的技术栈独立完成。例如男士，可能会 被分割为“996 微服务”、“交作业微服务”、“扛煤气罐微服务”。

且不说这样划分是否合理，即使这样划分了，“微服务”内部也要 通过自己的各个部件（可能是残缺的）协作完成，例如“交作业微服务” 要完成“交作业”用例，也需要眼睛、耳朵、手、脚、心脏、等（可 能是残缺的）协作完成，并非映射一个“交作业模块”然后就搞定。更 何况，有的用例需要若干个“微服务”协作才能完成。

另外，“微服务”是妥协的不良结构。如果这样的划分风格所得到 的软件结构真的是良好的结构，我们几十年前就可以这样做，难道之前 的复杂系统没有分解吗？不需要分解吗？如果这真的是好的结构，放在 什么时候都是大杀器，根本不用等到现在，拿“微服务”（这也是一个 造词）之类的作为理由。即使是一个人完成的项目，也不妨引入一个假 设“由各个小团队应用各自的技术栈独立完成”来改善软件的结构嘛。

“微服务”所要解决的问题，在某些系统中确实是存在的，但我在 这里要提醒读者，提防把“微服务”（或类似手段）当成遮羞布。

一个人没有能力解决主要问题时，他可能会采取一些措施来掩盖自 己能力不足的事实，其中之一就是引入次要问题。

这也是人之常情了。例如，我们在工作中碰到头痛的问题，有时会 逃避着不去碰它，而去做一些整理文件，回复邮件等琐碎的事情来获得 成就感。

我用盖大楼作类比： 两座大楼耸立在那里，要判断地震来了哪座大楼不容易塌，要考虑 的是大楼的结构、所用的材料、所在位置的地质环境等，和这座楼是哪 家公司建造的，要了多少钱，建造大楼的公司内部是怎样的组织结构， 一共有几支工程队，当时怎么分工的，甚至大楼是猫建造的、狗建造的、 外星人建造的，已经没有直接关系——因为大楼已经在那里了。 但要研究这些让大楼不容易塌的直接影响因素，涉及到艰深的工程 力学、流体力学、岩土力学等知识。架构师李三没把这些知识学扎实， 正在那里犯愁呢。

这时，伪创新专家张四出现了。张四说，时代变了，现在盖楼要讲 “新建筑学” ，要考虑到人际关系，要搞好团结。

于是，李三想着反正“老的”工程力学那些我也搞不懂，还是搞“人” 轻松一些。这样吧，有几个包工队跟自己混，就分几个包，大家开干就 是。

转换思想后，李三每天累并快乐着，灯红酒绿，推杯换盏。 而且，运气好的时候，盖出来大楼确实也能住人。 如果李三说，公司又不是我的，想那么多干什么，这可以理解；

如果李三说，这么干盖楼快，反正老板要的就是在某某大日子到来 之前有个样子货交差，这也可以理解；

如果李三说，这么干有利于建筑团队的安定团结（虽然坑顾客） 这也可以理解；

就怕张四以李三为案例，搞出一个“新工程力学”，说这样盖出来 的大楼更抗震，甚至到清华大学建筑学院开课“划时代革命性的工程力 学”，取代原有的“工程力学”——这就是无耻了！

1.1.3 总结 #

我简要归纳需求和设计的区别如下，在后面的章节中再慢慢进 一步阐述这些区别。

★高焕堂在他的书《USE CASE 入门与实例》[高 2008]中说过： 用例是收益面，对象是成本面。本书基于他的思想做了扩展。