《软件方法》二十多年的坚持和AI暗合(1)设计而不是实现

《软件方法》定义的四个工作流：

A-业务建模（business modeling）——定位需要改进的目标组织以及该组织接下来最需要改进的问题。

B-需求（requirements）——描述为了改进组织的问题，待引入的信息系统必须具有的整体表现。

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

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

我已经用了二十多年，早在写书之前就开始用这个ABCD了。四个术语沿自RUP，但读者可以对比RUP和《软件方法》，看定义上有哪些不同。

经常会有人提议，能不能把“D-设计”改成“D-实现”？

也改过的。

曾经有一段时间使用“业务建模、需求、分析、实现”，后来又改回来了。

因为我还是认为，人应该做的是设计，而不是实现。

所以，在AI降临之前，从“C-分析”到“D-设计”，二十多年来，我推荐的实践是这样的：

（1）做好分析模型；

（2）定制分析模型到实现技术栈各个部分的映射套路，并针对典型用例提供实现案例；

（3）用套路和案例培训程序员无脑搬砖，直到能举一反三，按照所给分析模型写出同样套路的实现。

上面的步骤（2）相当于今天的提示词（或skill），归纳套路和给案例，让AI搬砖。

AI降临后，（3）被干掉了，但前面的（1）和（2），AI并没有能够覆盖。

所以我们一直坚持叫“设计”，强调的是（2）而不是（3），这暗合了AI的趋势。把无脑搬砖干掉，人做好人的事情。

说到这里，又要说警惕伪创新了。

正如《软件方法》第8章所说，上面的做法把原来a×b×c的工作量变成了a+b+c：

有些开发人员并不喜欢这样。建模分析模型、归纳套路，这些显式的做法是在强迫他认真思考，这可让他太难受了。

他宁可拉回到以前的a×b×c，各种事情混在一起，朦朦胧胧坐在电脑前面，一会想这里，一会想那里，一会敲一下代码，靠大脑里面一点点朦朦胧胧的经验在那里敲。一切都是隐式的，尽在不言中。遇到质疑时，有很多闪躲的空间。

（DDD圈子名言：DDD的终极大招是by experience。）

更妙的是，他们故意把这种“在大脑里朦朦胧胧过一下”和“熟练掌握方法的人在大脑里完成思考”混为一谈，因为两者看起来都很“敏捷”。

就像一道数学难题，学渣用不着草稿纸（因为他根本不知道怎么推导），拿起笔就往答卷上写，而且还振振有词，你看那边那个王虹同学，不也是不打草稿直接就写嘛！

作者微信：umlchina