北京考试学院网站首页,北京网站开发外包公司,临沂百度网站,wordpress钩子函数DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集 第1章 建模和UML 牵着你走进傍晚的风里#xff0c;看见万家灯火下面平凡的秘密。
《情歌唱晚》#xff1b;词#xff1a;黄群#xff0c;曲#xff1a;黄群#xff0c;唱#…DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集 第1章 建模和UML 牵着你走进傍晚的风里看见万家灯火下面平凡的秘密。
《情歌唱晚》词黄群曲黄群唱曹崴1994
1.1 利润需求设计
1.1.1 利润需求设计
利润收入成本。不管出售什么要获得利润需要两个条件
1售价要高
2成本要低。
妙就妙在价格和成本之间没有固定的计算公式这正是创新的动力之源。
放到软件业上我也炮制了一个式子
利润需求设计
在软件开发中需求工作致力于解决“提升销售”的问题设计工作致力于解决“降低成本”的问题二者不能相互取代。能低成本开发和维护某个系统不一定能保证它好卖。系统好卖如果开发和维护成本太高最终利润还是高不了。
以上说的“利润”、“销售”、“成本”是广义的可以是金钱也可以是名声、权力、人力等。
即使你做的是没有在市场上公开出售的单位内部系统甚至是自己为自己的方便做一个系统也适用上面的式子。
更为关键的是需求和设计之间不存在也不应该存在刻板的一对一映射——也幸亏如此否则人工智能现在就可以轻易学习其中的映射套路取代软件开发人员完成所有的工作。目前软件开发人员存在的价值之一就是根据自己掌握的领域知识和软件开发知识努力在很多可能的映射方案中挑选出最合适的映射方案以及创造出更好的映射方案。
我们先来看自古以来就有的一个系统人即“人肉系统”。
人肉系统的功能需求是人能够走路、跑步、跳跃、举重、投掷、游泳……但是设计人肉系统的结构时并不是从功能需求直接映射到设计得到“走路器官”、“跑步器官”、“跳跃器官”……人肉系统的器官是眼、耳、心、肺、肝、胃、骨架、皮肤……这些器官和人肉系统的功能不是一一对应的在互相协作以完成系统的功能时它们和功能之间的关系是多对多的。
图1-1表达了某个人肉系统的需求和设计。可以看到需求和设计的映射是多对多的。各个器官被各个功能共享不能说“心脏是老板的”、“肺是老婆的”。 图1-1 人肉系统的需求和设计
图1-1的映射只是造物主——用《异形Alien》的说法就是工程师Engineer——当初挑选的映射方案。
今天人类也成为造物主开始“造人”。同样是造能跑能跳能扛的“人”我们挑选的映射方案可能和人类的造物主如果存在当初“造人”的映射方案不一样如图1-2。当然目前人类的科学技术水平连细胞都造不出来更不用说做到一模一样的方案了。 图1-2 人类和“新人类”
“人”的使用者并不关心这个“造人”的方案。
老板要雇民工扛煤气罐他只要求这个民工能跑能扛管他体内构造是心肝脾肺肾如图1-2上部还是电路板如图1-2下部——如果电路板民工更便宜他会毫不犹豫地 淘汰掉心肝脾肺肾民工。
民工找工作也要从市场的需要来找——“老板你要雇人扛煤气罐吗我可以”而不是从自己的内部器官出发来找——“老板我每天都管理我的心脏你请我吧”
以上所说的这些总体意思就是要学会把需求和设计分开这也是贯彻全书的核心思想后面还会反复强调。当然用词可能会有变化可能有的时候会说“卖和做分开”有的时候会说“外和内分开”等等。
软件开发中如果从需求直接映射设计会得到大量的重复代码成本增加如果从设计出发定义需求会得到一堆假的“需求”销量下降。不管是哪一种情况利润都会下降。
而这一点很多软件开发人员并没有意识到。
1.1.2 常见错误
1.1.2.1 “子系统”其实是需求包
我们经常听到这样的说法“本系统分为八大子系统包括销售子系统、财务子系统、库存子系统……”这就是需求和设计不分的一个例子。其实说话人可能应该这样表达自己的意思“本系统的功能需求分为八大需求包……”。
需求包是基于涉众视角对系统功能分包而得到的子系统用UML的说法是组件是基于内部视角根据系统部件的耦合和内聚情况切割而得到的这两者不是一一对应的。所谓的“财务子系统”其实可能是“把财务人员使用的功能放在一个包里”如图1-3。 图1-3 “子系统”其实是需求的分包
1.1.2.2 “功能模块”是错误用语
另一个常见的需求和设计不分的说法是“功能模块”。
功能Function这个词如果应用于信息系统描述的是系统作为一个整体接收到外部请求时应该产生的效果。
模块Module这个词如果应用于信息系统描述的是表示系统分解后得到的各个组成部分。
“功能模块”意味着在意识里认为“功能”和“模块”有直接的映射关系甚至认为“模块”是属于某个“功能”的模块是为了完成某个“功能”而存在的。
用前面的“人肉系统”来举例“功能模块”就是“走路器官”、“走路子系统”……这是错误的。
******
不但“功能模块”不应该连起来说而且“功能”和“模块”这两个词的含义也是模糊的。
例如以自助柜员机ATM为目标系统“取现金”是“功能”“登录”也是功能“计算手续费”也是“功能”到底“功能”有多大“模块”是一个控件还是一个类还是若干个类形成的组件
因此本书后文中会尽量使用更精确的术语。例如以ATM为目标系统“取现金”是一个用例“登录”是用例中的一个回合“计算手续费”是一个步骤系统里面可能会有一个“账户”类……。
1.1.2.3 微服务的遮羞布
最近几年鼓吹的新词“微服务”造成一定的误导。有的人误以为“微服务”就是“需求设计一一对应”。
假设考虑到开发团队的结构把系统分成多个“微服务”分由各个小团队应用各自的技术栈独立完成。例如图1-1中的男士可能会被分割为“996微服务”、“交作业微服务”、“扛煤气罐微服务”。
且不说这样划分是否合理即使这样划分了“微服务”内部也要通过自己的各个部件可能是残缺的协作完成例如“做作业微服务”要完成“做作业”用例也需要眼睛、耳朵、手、脚、心脏、**等可能是残缺的协作完成并非映射一个“做作业模块”然后就搞定。更何况有的用例需要若干个“微服务”协作才能完成。
另外“微服务”是妥协的不良结构。如果这样的划分风格所得到的软件结构真的是良好的结构我们几十年前就可以这样做。即使一个人做的项目也不妨引入一个假设“由各个小团队应用各自的技术栈独立完成”来改善软件的结构不必等到今天才大兴“微服务”之风。
“微服务”所要解决的问题在某些系统中确实是存在的但我在这里要提醒读者提防把“微服务”或类似手段当成遮羞布。
一个人没有能力解决主要问题时他可能会采取一些措施来掩盖自己能力不足的事实其中之一就是引入次要问题。
这也是人之常情了。例如我们在工作中碰到头痛的问题有时会逃避着不去碰它而去做一些整理文件回复邮件等琐碎的事情来获得成就感。
我用盖大楼作类比
两座大楼耸立在那里要判断地震来了哪座大楼不容易塌要考虑的是大楼的结构、所用的材料、所在位置的地质环境等和这座楼是哪家公司建造的要了多少钱建造大楼的公司内部是怎样的组织结构一共有几支工程队当时怎么分工的甚至大楼是猫建造的、狗建造的、外星人建造的已经没有直接关系——因为大楼已经在那里了。
但要研究这些让大楼不容易塌的直接影响因素涉及到艰深的工程力学、流体力学、岩土力学等知识。架构师李三没把这些知识学扎实正在那里犯愁呢。
这时伪创新专家张四出现了。张四说时代变了现在盖楼要讲“新建筑学”要考虑到人际关系要搞好团结。
于是李三想着反正“老的”工程力学那些我也搞不懂还是搞“人”轻松一些。这样吧有几个包工队跟自己混就分几个包大家开干就是。
转换思想后李三每天累并快乐着灯红酒绿推杯换盏。
而且运气好的时候盖出来大楼确实也能住人。
如果李三说公司又不是我的想那么多干什么这可以理解
如果李三和张四说这么干盖楼快反正老板要的就是在某某大日子到来之前有个样子货交差这也可以理解
如果李三和张四说这么干有利于建筑团队的安定团结虽然坑顾客这也可以理解
但如果李三和张四说“新建筑学”盖出来的大楼更抗震甚至到清华大学建筑学院开课“划时代革命性的工程力学”取代原有的“工程力学”——这就是无耻了
1.1.3 总结
我简要归纳需求和设计的区别如图1-4在后面的章节中再慢慢进一步阐述这些区别。 图1-4 需求和设计的区别
★高焕堂在他的书《USE CASE入门与实例》[1]中说过用例是收益面对象是成本面。本书基于他的思想做了扩展。
1.1.4 自测题
本书不提供习题答案。
请扫码或访问http://www.umlchina.com/book/quiz1_1.html自测做到全对自然就知道答案了。 1[单选]
软件开发中需求工作的目的是____。
A) 让系统更加好卖
B) 更好地指导设计
C) 对系统做概要的描述
D) 满足软件工程需求规范
2[单选]
软件开发中设计工作的目的是____。
A) 对系统做详细的描述
B) 更好地指导编码
C) 降低开发维护成本
D) 满足软件工程设计规范
3[单选]
开发人员说“根据客户的需求我们的系统分为销售子系统、库存子系统、财务子系统……”这句话反映了开发人员可能有什么样的认识错误
A) 开发人员没有认识到面向对象设计的重要性
B) 开发人员直接从设计映射需求
C) 开发人员直接从需求映射设计
D) 开发人员没有用UML模型来描述子系统
4[单选]
打开开发人员写的需求规约发现用例的名字都是“学生管理”、“题库管理”、“课程管理”……这背后可能隐藏的最大问题是什么
A) 用例的名字不是动宾结构应改为“管理学生”……
B) 用例粒度太粗每一个应该拆解成四个用例“新增学生”、“修改学生”……
C) 开发人员直接从需求映射设计
D) 开发人员直接从设计映射需求
5[单选]
以下这些经常在开发团队里使用的词汇都是不严谨的。其中_______混淆了需求和设计的区别。
A) 功能模块
B) 详细设计
C) 用户需求
D) 业务架构
6[单选]
关于需求和设计以下说法正确的是____。
A) 需求关注概要、设计关注详细
B) 需求的目的是更好地指导设计
C) 设计的目的是把系统分解成可以编码的模块
D) 需求和设计不是一一对应的
7[多选]
有的开发人员没有能力剖析复杂领域逻辑于是引入性能、开发时间、开发团队组成等遮羞布来转移问题的焦点。以下的哪些做法和这样的做法类似
A) 医生在给癌症患者看病时偷偷借助人工智能来帮忙。
B) 医生在看病时对癌症患者说“你经济条件不好目前只能吃得起这个药所以这个药最合适”。
C) 医生在看病时对癌症患者说“我们医院目前只有这个药所以这个药最合适”。
D) 医生看到癌症患者经济条件不好于是80000元一盒的药只收800元。 1.2 建模工作流 1.2.1 建模工作流ABCD
要能做好需求和设计以达到“低成本制造好卖的系统”并非喊喊口号就可以需要静下心来学习和实践一些必要的建模技能。
软件开发是增量、迭代进行的每一个迭代周期都需要依次思考这么几个事情
A-业务建模business modeling——定位需要改进的目标组织以及该组织接下来最需要改进的问题。
B-需求requirements——描述为了改进组织的问题所引入的信息系统必须具有的整体表现。
C-分析analysis——提炼为了满足功能需求所引入的信息系统需要封装的核心域机制。
D-设计design——考虑质量需求和设计约束将核心域机制映射到选定非核心域上实现。
本书将以上ABCD称为软件开发的4个建模工作流。
如果采用本书的方法学以及UML表示法其ABCD大致如图1-5。读者先看一眼即可后文再详细解说图中内容。 图1-5 四个建模工作流本书方法学UML
软件江湖中各种花里胡哨的用语不管是真创新还是伪创新基本上都可以用上面的ABCD来归纳例如
产品经理、需求工程师、需求分析师AB部分C。
业务架构师可能是A此时“业务”的含义是“组织”也可能是C此时“业务”的含义是“核心域”。
系统架构师CD。常有团队说要改进系统架构其实他想改进的是B-需求。
领域驱动设计CD。也有团队声称要学习“领域驱动设计”其实想解决的却是A-业务建模。
中台CD
微服务CD
设计模式CD
……
欢迎读者随时补充更新。
1.2.2 关于用词
“工作流workflow”沿用自RUPRational Unified Process的早期版本后来的RUP版本改为“科目discipline”。
在我看来“工作流”和“科目”这两个词都不算太好但目前没有更合适的选择暂时先用“工作流”。
4个工作流的名称“业务建模”、“需求”、“分析”、“设计”沿用了以往各个方法学的用语这些用语也不严谨。
例如“业务建模”末尾有一个“建模”其他3个却没有难道其他3个不是建模如果把其他3个也加上尾巴“建模”就变成批量刷废话了如果把“业务建模”的“建模”去掉剩下“业务”意思已经不对。
甚至“业务”二字都是模糊用语这个后文再详述。
更贴切的名称可能是
A-组织价值
B-系统责任
C-核心域逻辑
D-实现
但再三权衡还是沿用之前的用语。
如果读者真正理解了ABCD的内容叫什么问题都不大改成A-阿猫、B-阿狗、C-阿鸡、D-阿鸭也无所谓。
阅读到此处读者可能会发现本书中的“需求”和“设计”两个术语有两种用途。
一种用于表达建模得到的结果例如“需求和设计不是一一对应的”另一种用于表达建模的工作流即“B-需求”工作流和“D-设计”工作流例如“我正在做需求”。
希望下面的话能帮助理解
为了得到需求需要做的建模工作流有“A-业务建模”和“B-需求”为了得到设计需要做的建模工作流有“C-分析”和 “D-设计”。
1.2.3 逃不掉的思考
在迭代周期中如果要追求好的结果按A→B→C→D的顺序来进行推理是必须的而且各个开发团队一直都在这样做。我们来看几个场景
开发团队甲所有成员都认真学习《软件方法》和认真做题引进了UML和建模工具EA并按照书中的改进指南改进最终得到很不错的结果。
开发团队甲的A→B→C→D很容易看出来。
开发团队乙没听说过《软件方法》也不用UML和EA用的是技术总监自己归纳的一套“软件工程方法学”和符号也还算行之有效。
开发团队乙的A→B→C→D也容易看出来但形式上和开发团队甲不同。
开发团队丙快乐拥抱挂着“敏捷”或“领域驱动设计”名头的伪创新。这些伪创新投资少见效快门槛低产量大仪式感十足。开发团队轻松愉快、热热闹闹地讨论和糊墙。
这里面有A→B→C→D吗也许有一点但很少这些热闹只是装模作样。真正起作用的A→B→C→D推理可能是在编码的时候在大脑里朦朦胧胧进行的推理的质量可想而知。
开发团队丁觉得既然ABC我都不会我也不想装模作样就一步到D直接编码。
这种情况下还有A→B→C→D吗有的和开发团队丙差不多真正起作用的A→B→C→D推理是在编码的时候在大脑里朦朦胧胧进行的同样推理的质量可想而知。幸好省去了伪创新装模作样的成本。
开发团队戊的故事纯杜撰勿对号入座看起来有点不一样。他们所在的公司赶上了风口成了某个领域例如预制菜的互联网巨头。在开发和维护预制菜相关的项目时开发团队戊的领导下觉得现在的前端框架Vue、React等还差点意思——更有可能是为了自己的简历积极主动地“觉得”Vue、React等还差点意思于是搞了个内部项目自研前端框架“闪电五连鞭”。过了几年也许是风潮过了也许是历史使命已经完成预制菜市场冷却反倒是“闪电五连鞭”框架误打误撞受到全世界开发人员热捧成为公司的生存支柱。
这里面有A→B→C→D吗看起来像是颠倒了
再看一个特别的程序员张三自己做一个东西给自己用。张三只会用编码工具也没学过UML或类似的知识。
张三这里面还有A→B→C→D的推理吗
最后这两个答案也是一样的并没有什么特别具体留到后文详述。
总之每一个软件项目只要不是故意摆烂开发团队都会有A→B→C→D的推理过程——也许无意识、隐式地做也许有意识、显式地做也许推理过程严谨合理也许推理过程漏洞百出也许分成很多人来做也许一个人做推理产物的形式也许是UML模型也许是其他……
就像一道复杂的数学填空题答案是97/2023如果考生能填对这个正确答案他必然在考试过程中的某个时间点做了正确的推理。只要不是故意摆烂即使是学渣也会尝试着去推理。只不过相对于学霸的一击必中学渣可能要反反复复“敏捷探索”多次才答对甚至直到考试结束还没答对。
本书希望教给读者一种严谨和高效的推理方法。当然要掌握它需要付出辛勤和汗水。
1.2.4 不了解ABCD的危害
1.2.4.1 思维颠倒
如果软件开发人员对以上的“A-业务建模”、“B-需求”、“C-分析”、“D-设计”工作流没有概念就会出现这样的现象
问一名开发人员“你在做什么”他可能回答“我在做设计”、“我在写文档”。
其实此时他的大脑可能正在思考组织的流程A-业务建模或者在思考系统有什么功能性能B-需求或者在思考系统要封装的领域概念之间的关系C-分析但他通通回答成“在做设计”、“在写文档”。
也就是说在他的大脑中软件开发工作被简单地分为“写代码”和“做设计写文档”两部分。如果他没有在“写代码”那么通通是在“做设计写文档”。
那么他是怎么区分自己在“写代码”还是“做设计写文档”呢可能是这样区分的在Visual Studio、Android Studio、Eclipse……中写出来的叫“代码”在Word、wiki、Visio、EA……中写或者画出来的叫“文档”。
这时候如果有人忽悠一句口号代码就是设计那就更妙了。因为本来我就认为“设计”是“代码以外的各种东西”现在又说“代码就是设计”一推导不就变成了“代码就是软件开发的一切”
即使没有“代码就是设计”这样的忽悠开发人员也会把“设计”注意此处的“设计”不是本书严格定义的D工作流而是“代码之外的所有东西”或“文档”看成“代码”的一种比较概要或比较形象的表现形式。不同的“设计”或“文档”代表着“代码”的不同视图可以让开发人员从不同的视角观察代码如图1-6所示。 图1-6 误解文档只是代码的视图
这样的误解不只“普通”的开发人员会有。Martin Fowler所著的UML畅销书《UML精粹》认为UML有三种用法草稿、蓝图和编程语言也是把UML模型看作是代码的视图——这是错误的。虽然Martin Fowler在某些社群的心目中如大神一般存在但是从Fowler写作的其他书籍《重构》、《企业应用架构模式》、《分析模式》等可以知道他的研究工作集中在“C-分析”和“D-设计”工作流在“A-业务建模”和“B-需求”方面研究不多他在这方面的言论应谨慎看待。
更危险的是把“文档”当作“代码”的视图还会带来思维颠倒先拍脑袋编码然后再从代码来反推其他工作流的内容导致其他工作流变成徒有形式的装模作样。
以下是几段我经历过的思维颠倒的对话
★对话一
我这个不应该是系统的用例如果读者不理解什么叫“用例”就先把它理解为“功能”好了。
开发人员是的我都写好了运行一下给你看这个系统确实提供了这个用例。
是否系统的用例应该从“A-业务建模”来推理通过愿景、业务序列图等步骤的推理后觉得应该有系统就有不该有就没有。不能说我写好了代码所以就应该有。
★对话二
我这两个类的关系不应该是泛化而是关联。
开发人员是泛化不信我打开代码给你看或逆向工程转出类图给你看。
是否泛化关系应该从领域逻辑来判断领域逻辑不是那就不是代码就不应该那样写。不能先写好代码“人是猪的一种”肯定编译通过再用写好的代码来证明“人是猪的一种”。
★对话三
我A聚合组合B这个不太对。
开发人员对的你看我代码A是聚合根其他对象调用时要先找A存取数据也是以它作为单元。
同对话二是否聚合组合关系应该从领域逻辑来判断领域逻辑不是那就不是代码就不应该那样写。
如果了解了ABCD工作流的概念以及不同工作流需要思考和表达的内容我们可能就不会再说“我在写文档”这种话了。“我在写文档”只是表达“我写的东西不是代码” 或者“我正在用文档编辑工具在工作”。
你在写什么“文档”“A-业务建模”“B-需求”“C-分析”我不写我画图难道不可以吗我不写不画我用语音清楚地表达组织的流程难道不可以吗我用Word编码即D-设计难道不可以吗我用C#写需求即B-需求难道不可以吗
更有意义的说法应该是“我在做业务建模”、“我在做需求”……如果说“文档”二字可以给你带来不可替代的快感可以说“我在写业务建模文档”。
1.2.4.2 胡乱应对
开发人员常说要“应对变化”甚至有的人还喊口号“拥抱变化”但是很多人并不清楚要应对的是什么样的变化也不知道应该怎样正确地应对变化。
当我们谈到“变化”的时候真相有可能是下列之一
真相1根本没有变化
系统的需求功能、性能和约束没有变化只是之前由于实现人员的能力问题导致实现不能满足需求或者能满足需求但自认为结构不合理。这样的修改不能叫“应对变化”只能叫“纠错”。
这种情况下需要抓的工作流是“C-分析”和“D-设计”。
真相2系统的功能没变性能和约束变了
例如响应时间缩短实现平台更换等。
应对这样的变化需要抓的工作流是“D-设计”实现的套路要调整。
真相3系统功能的合理变化
经过严谨的“A-业务建模”和“B-需求”的推理认为系统的功能用例、步骤、输入输出信息、业务规则……确实需要变化。
应对这样的变化需要抓的工作流是“C-分析”。
注意这里说的是经过严谨推理得出的“合理变化”。系统的功能之所以需要变化根源在于系统所处的大环境中的某些东西发生了变化而这样的变化往往是有其规律的。通过“C-分析”工作流调整系统的核心域模型使其更好地体现核心域的规律有助于应对这样的变化。
真相4系统功能的不合理变化
这就是平时常说的“假需求”。和1一样这其实不是“变化”是“错误”。
没有经过严谨的“A-业务建模”和“B-需求”的推理拍脑袋得到的所谓“系统功能”不能改进组织流程也不满足涉众利益。
这种情况下抓“C-分析”工作流意义并不大因为这种变化没有规律。
需要抓的工作流是“A-业务建模”和“B-需求”。先学会严谨推理出系统的功能才能知道有没有真相3。
我们用医生给患者看病类比
真相1
医生的诊断没问题开的处方也没问题护士执行医嘱时执行错了。
这不是“变化”这是“错误”。如果还把这个叫作“拥抱变化”就是无耻了。
真相2
输液时换了另外一种品牌的一次性输液器。
真相3
患者病情确实有变化。张三原来只是乙肝现在是肝癌。
这种变化是有规律的。张三得了乙肝却不注意保养依然酗酒和熬夜很快进展到肝硬化然后进展到肝癌。
如果充分了解肝脏的工作机制C-分析当张三被诊断出乙肝时就可以预测和应对后面可能会发生的变化。
真相4
医生诊断错了病情。
张三出现恶心、乏力、食欲减退。村里的道士九叔给他诊断认为他被鬼上身了需要搞一个驱魔仪式。九叔已经精研驱魔理论体系和实践多年一手辟邪剑法已经达到传奇王者。
实际上张三是得了乙肝九叔的传奇王者对此没有帮助。
当然如果是玩驱魔游戏或Cosplay又不一样了。
******
也许是不了解其中区别也许是为了掩盖自己的无能开发人员经常胡乱应对。
例如把真相4说成真相3营造出“需求变化剧烈”的假象从而掩盖自己缺少“A-业务建模”和“B-需求”能力的事实。
例如对真相3和真相4避而不谈只谈真相2或者想通过真相2的应对方案“D-设计”来应对真相3和真相4因为“D-设计”是他唯一熟悉的内容。
一些资料以“领域驱动设计”为名结果一看内容所举的例子就1-2个“领域”类然后就开始讨论Entity、Service、Repository、DTO、六边形架构……哪里有“领域”分明说的是“企业应用架构模式”、“互联网系统架构模式”。
在各种软件开发技术大会上也可以看到这样的场景某电子商务网站的架构师上台讲了一通接着某视频网站的架构师上台也讲了一通咦这两人是同事吗演讲内容如此相似原来他们讲的内容都是“D-设计”的内容。究其原因也许并非不为而是不能——架构师对自己所开发系统的核心域研究太浅。
1.2.4.3 伪创新泛滥
很多开发人员只有D的知识。当岗位发生变化需要他做A、B、C的工作时按道理应该去认真学习A、B、C的技能才对。
可惜很多人并不愿意走出自己的舒适区甚至还会有意无意地把其他人拉到自己的舒适区。
例如在和涉众讨论需求时频频蹦出一些“技术潮词”目的就是以自己的“所长”来碾压涉众从而掩盖自己业务建模A和需求B技能的不足。
例如在讨论核心域的类模型C时动不动就谈到如何实现D或者质疑“会不会有性能问题”D从而掩盖自己抽象能力的不足。
于是各种投其所好的伪创新就登场了。
有的伪创新极力贬低A、B、C的重要性通过“砸烂一切枷锁”来吸引热血青年。例如想那么多有啥用最后不是还得写代码张嘴就是Linus Torvalds的“Talk is cheap. Show me the code.”。
后来“发明家”及其追随者慢慢发现砸烂一切是不行的追随者的信念开始动摇。于是伪创新不再贬低A、B、C而是从D来臆想A、B、C得到的A、B、C“方法学”非常“简单易学”让只了解D的开发人员感觉“很受用”。
例如深入第一线调研各类涉众的利益很麻烦。有办法摆一个“现场客户”在旁边开发人员就可以心安理得坐在电脑前面编码有问题就推给“现场客户”。
例如认真学习领域知识的各种概念和术语很麻烦。有办法开发人员可以按照自己的理解创造一套“通用语言”。
伪创新往往不会直接宣传自己“简单易学”而是会说自己很高深。宣传中往往带有“艺术”、“禅”、“道”等字眼有意无意地朝宗教、艺术、玄学方向引导——比起枯燥的数学理论和逻辑推理这些东西可是太好下嘴了。还有一个很大的优势一些媒体人听到“艺术”、“禅”、“道”等字眼就亢奋自觉地加入到宣传伪创新的队伍中。
开发人员一开始以为很难很深奥上手一学发现其实不难可以说是投资少见效快产量大而且仪式感十足。最妙的是不用走出舒适区辛苦学习就得到了“方法学”这可太符合只了解D的开发人员的胃口了开发人员立刻有捡到了便宜的感觉心中豪气顿生——不愧是我别整三岁的有能耐你整四岁的
关于各个工作流的各种伪创新本书后面各章节还会进一步讨论。
1.2.5 没有测试工作流
“测试”可以看作建模的验证过程所以不能光说“做测试”要清楚认识“测试”所验证的内容。
如果“测试”验证的是组织流程中各个系统之间的协作那就是“A-业务建模”。
如果“测试”验证的是目标系统的整体表现那就是“B-需求”。
如果“测试”验证的是目标系统内部各个部件之间的协作那就是“C-分析”和“D-设计”。
无论是启发、定义还是验证如果你思考的内容是某一个工作流的内容你就是在做该工作流。在一个迭代周期中启发、定义和验证往往是交错进行的。
1.2.6 没有项目管理工作流
本书关注的范围限于方法学即A→B→C→D的正确推导方法至于推导是一个人做的很多人做的甚至是猫做的、狗做的、外星人做的没有直接关系。
还是用前面的大楼类比。两幢大楼耸立在那里地震来了一幢塌了另一幢没塌。
直接因素是大楼的结构、所用的材料、所在位置的地质环境等这些涉及到艰深的工程力学、流体力学、岩土力学等知识——类似于本书所研究和阐述的方法。即使大楼是外星人盖的也要讲这个基本法。
直接原因往往比较难理解此处要提防有的人为了掩盖自己的无能干脆找比较容易理解的其他原因来把水搅浑。例如一出事故就嚷嚷“有人吃回扣了”就算经过调查没人吃回扣他也会从工作服的颜色工人是否结对洗澡施工队开会时是否站立等更容易理解的方面来找原因。
当然要成功完成一个软件开发项目还有很多其他工作例如进度管理、人力资源管理等但这些都不属于本书讨论的范围。关于软件项目管理方面的内容读者可自行阅读专门的书籍。
1.2.7 自测题
本书不提供习题答案请扫码或访问http://www.umlchina.com/book/quiz1_2.html自测做到全对自然就知道答案了。 1[单选]
以下描述最可能对应于软件开发中的哪个工作流
每个项目由若干活动组成每项活动又由许多任务组成。一项任务消耗若干资源并产生若干工件。工件有代码、模型、文档等。
A) 业务建模
B) 需求
C) 分析
D) 项目管理
2[单选]
以下描述最可能对应于软件开发中的哪个工作流 A) 需求分析
B) 代码设计
C) 详细设计
D) 设计
3[单选]
以下描述最可能对应于软件开发中的哪个工作流
系统向会员反馈已购买商品的信息。
A) 功能规约
B) 需求分析
C) 需求
D) 需求规约
4[单选]
以下描述最可能对应于软件开发中的哪个工作流
在去给外婆拜年的路上李雪琴突然想起需要一些现金给外婆做现金红包。她先用高德地图查询了附近的ATM机网点并挑中了一处工行的网点开车过去一看好家伙路边这么多人排队取现金李雪琴只好又看高德地图挑了一家她觉得人应该会比较少的开车过去终于在ATM机取到了现金然后她又想了想哪里有卖红包的地方……
A) 业务建模
B) 用户故事
C) 需求
D) 流程分析
5[单选]
以下不属于建模工作流ABCD的是______。
A) 需求
B) 分析
C) 设计
D) 测试
6[单选]
本书中建模工作流的名称沿用了之前方法学中的名称这些名称其实都不太合适例如______工作流的名称改为“系统责任”更合适。
A) 业务建模
B) 需求
C) 业务需求
D) 分析
7[单选]
有方法学家发明了比“糊墙”还有仪式感的“美女建模法”。
例如某医卫领域软件公司招聘一批颜值较高的美女分别扮演患者、护士、医生、收费员、HIS系统、支付宝、微信等。和客户沟通时就让这些美女一起上场表演各种场景给客户看。
客户一致反映这样的方式生动、活泼、新颖、看得见、闻得着、有嚼头、有回昧、一举多得附加题这一串的出处是下次沟通还这样搞
请问。美女们向客户表演的最有可能是哪个工作流的内容
A) 业务建模
B) 总体设计
C) 需求
D) 分析
UMLChina公众号精选20231208更新按ABCD工作流分类
