其他分享
首页 > 其他分享> > [新增:鸵鸟]软件开发团队的脓包:皇帝的新装、口号党、鸵鸟、废话迷

[新增:鸵鸟]软件开发团队的脓包:皇帝的新装、口号党、鸵鸟、废话迷

作者:互联网

在严谨建模思维的扫视之下,软件开发团队中很多有意无意遮掩的脓包会被强制露出。

接下来我会总结一些常见的脓包,供大家参考。

脓包(1)皇帝的新装

图片

图片来自Wikipedia

阿Q家徒四壁,连衣服都没得穿,觉得很丢脸。这时,有人和阿Q说,其实这是一种时髦,你穿的是“皇帝的新装”。像溺水的人抓住救命稻草一样,阿Q立刻被这个说法洗脑,以后都和别人说自己穿的是“皇帝的新装”,遮掩没有衣服穿的事实。

在我刚开始为软件组织提供服务时,常听到软件组织的负责人和我介绍他们的团队“我们现在用的不是面向对象和UML,用的是结构化方法”。我一开始信以为真,认为如果能做到用数据流等建模元素从组织级、系统级到模块级层层分解也不错啊,后来发现,绝大多数情况下负责人所说的“结构化方法”其实就是随意的分解,也就是没有方法。

后来,这个场景升级了。软件组织的负责人和我介绍他们的团队“我们现在采用的是敏捷开发方法”,我听到这里有时会忍不住咧开嘴笑看着对方,对方也意识到我表情的意思,连忙解释“我们自己以为是敏捷开发方法”。

你瞧,如果说团队“没有方法”,那很没面子,但抓住“敏捷”这根救命稻草,宣称我用的是“敏捷”,脸上就有了光彩。

*******

这还不是最关键的。

我们经常会自嘲。比如没有车走路来的,会自嘲说“我坐的是11路车”,没上过大学,会自嘲说“我上的是社会大学”。说这些话的时候,说话人很可能知道是在自嘲。

而有的软件开发团队说类似话语的时候,并不是在自嘲,是信以为真哪!


脓包(2)口号党

图片

如果评价三种做事情的方式:有口号有方法、有口号无方法、无口号无方法,哪一种最坏?

可能有的人会认为无口号无方法最坏,其实不然,无口号无方法地呆在原地,可能会慢慢衰落,但不是最坏的。历史上各种最坏的大悲剧往往和“有口号无方法”有关——最坏的事是“有口号无方法”的“好人”做的。

“坏人”知道自己做的是坏事,会暗自收敛,事后会内疚,甚至做一些善事来弥补以求心安。比如,强盗打家劫舍抢了一千万,可能会拿出五十万来“济贫”,剩下九百五十万自己爽。这样,他心里就觉得自己是“侠盗”。

而“好人”认为自己是做好事,既然做好事,那出手就不要有顾虑了,做得越绝越好,所以可能会做得很极端。如果有口号无方法,大悲剧就发生了。希特勒把那么多人送去做肥皂,他也没觉得有啥不好意思,因为这是为了建设更美好的社会嘛。

图片

我们切换到软件开发领域。

互联网公司的研发人员喊口号:我们只做最重要的需求,尽快把产品投放市场。

问题来了:怎么才能知道哪个需求最重要?拍脑袋?抓阄?"投放市场"就有人要?莫非你爸是李刚?怎样才能"尽快"呢?

没有掌握相应的技能,多半是一次又一次的惨烈碰壁(可以自我安慰为“试错”),所谓的"快"也只是手忙脚乱的表面的"快",给自己一个心理安慰"我努力了"而已。在训练有素的对手面前,根本就是一个莽夫在胡乱出招,到处都是漏洞,只要对手乐意,分分钟取你性命。

那么,就算没方法,喊喊口号总比不喊要好吧?很多情况下确实如此。口号先行,慢慢再改善方法。

但是,我们必须注意到“有口号无方法”状况的危险:

危险一:无意识的自我陶醉

有的人喊完“最重要的需求”、“砍掉80%功能只留20%”之后,就满足了,陶醉了,觉得自己太牛×了,这么厉害的道理都懂,足矣,其他都是小意思了,然后并不认真思考如何才能真正能够做到,连自己以前采用的一些虽然不是很好但还过得去的做法也懒得做了。

危险二、有意识的胡作非为

有心人会挑一些褒义词作为口号,例如“敏捷”,再辅以煽动性很强的词语,例如“无敌”、“硝烟”、“颠覆”。褒义词作为口号声明了一个美好的、不容否定的目标,而手段也声明为无需思考只需要冲冲冲,更是正中某些不喜欢思考或者没有能力思考的开发人员的下怀。

然后,在口号的遮掩下胡作非为。

这是最坏的情况。因为口号是正确的,这些胡作非为就很难阻挡,而且后果也不好追责,毕竟“初衷是好的嘛”。

我印象最深的是,一位女生天真无邪地问我,“老师,希望敏捷一些难道不好吗?”——我还能怎么说,我能说不好吗。这和“爱国难道不好吗”、“环保难道不好吗”一样的。(在此处提到“女生”,没有歧视的意思,只是说到这里,让我想个例子,我最容易想起来的就是这个。)


脓包(3)鸵鸟

鸵鸟遇到危险的时候,就把头埋到沙子里,以为这样别人就看不见自己了。

图片

假设有这么一道数学题:

妈妈买了苹果和梨共320千克,其中苹果的重量比梨的4倍多20千克,求妈妈买了苹果和梨各多少千克?

没学过未知数、方程等知识的小学生,可能会画线段图:

学习了二元一次方程组的初中生,可能用以下方法:

图片

但是,初中生马上就杯具了。因为他学会了更高级的方法,所以他作业和考试要面对的题目比小学生要复杂得多!

当方程组越来越复杂,初中学习的代入法、消元法已经很难应对。

图片

大学生学了线性代数,了解了,其实就是矩阵的运算Ax=b,x=b/A,而且还可以用计算机来帮忙算(例如MATLAB)。

但是,大学生马上就杯具了。因为他学会了更高级的方法,所以他作业和考试要面对的题目比中学生要复杂得多!

于是,有人就想:我要是不学习更高级的方法,我要面对的问题不就不复杂了吗?或者说,我面对复杂问题解不出来也就有了借口!

*********

对某些人来说,如果不用动脑子,一遍遍重复简单的工作,还能拿高薪,简直是人间天堂。

如果被迫做前所未有的复杂思考,探索之前没有探索过的复杂问题,那就如同坠入了地狱。

这时,潜意识就会找出各种理由和手段来逃避思考。

例如,故意选择比较粗糙的工具,不想用更专业的建模工具,张嘴就说“太重”,以此为由逃避艰难的思考。更乐意在白板上随便画画,在墙上贴纸。白板就这么大,所以客观上你总不好意思让我用白板剖析复杂的逻辑吧?

图片

我确信我发现一种美妙的证法,可惜这里的空白处太小,写不下。——费马

例如,不愿意学习严谨的思考方法,喜欢打哪指哪,思维一会飞到天际,一会飞到地底,更要命的是,他根本不知道自己的思维目前是在哪里,但没关系,这样自由。

例如,和其他人宣传“干就完了”,让其他人也不思考,以免发现自己的破绽。

例如,把自己懂得的叫做“实践”,把自己不懂的通通称为“理论”。

*******

不止一个开发人员和我说,现在流行微服务,建模就不需要了。因为很可能一个功能就是一个微服务嘛,一个一个做,需求也不用写,类图也不用画。

首先,“只做一个功能所以不用做需求也不用做分析”这个认识是错误的。

需求永远是只做一个——最值得马上做的那一个,需求的建模工作就是要把“那一个”找出来。

另外,内外不是一一映射的,一个功能涉及到的类就少吗?AlphaGo功能够单一的,内部逻辑多复杂。

其次,也是更要命的,“微服务”成为了借口。

以前的开发难道不是一个一个用例这样做过去的吗,如果“一个用例一个系统,不用做需求也不用做分析”这个方法真的好,为什么不早点这样做,何必等到“微服务”呢?

“微服务”之后,整个系统应该是比之前要更复杂吧?按道理,不应该需要更多的思考吗,怎么会思考反而减少了呢?难道开发人员吃了什么神药,或者工具突飞猛进了?

除了“微服务”之外,之前开发人员用过的各种各样的借口还有“我这是一个遗留系统”、“我这是一个移动互联网系统”、“我这是一个二次开发的系统”、“工期很紧”……反正强调自己的系统很特别,来不及思考或者不需要思考就对了。

例如这篇《“精打细算”不用UML的奇怪脑洞》

*******

鸵鸟心态也导致下一个脓包:废话迷。


脓包(4)废话迷

如果有人告诉你,有一件事情很容易做好,而且做好了还能赚不少钱。听到这样的话,你可能会嗤之以鼻:幼稚!如果有这种便宜事,前面的人早拿走了,还能留到现在?

到了软件开发上,却有很多人犯这样的幼稚病,以为不需要付出艰苦的思考就能解决自己手上的软件开发项目。

【场景一】

问:这个系统改善什么组织的工作?

答:医院。

问:那么多医院,你认为哪家医院最适合引进这个系统去改进呢,能不能举一家你能想到的最合适引进的医院?

答:全国的医院都可以,哪家合适就哪一家。

上面的问答中,第一个问题很容易回答,第二个问题就比较难了,回答者回避了这个难题,回答了一句“正确而无用的废话”。如果再沿着这个问题追问下去,回答者可能就抵触了:干嘛要想这个问题?谁爱用谁用呗!

【场景二】

问:这个系统有哪些用例?

答:有新增设备、编辑设备、删除设备、查询设备……

问:这些用例怎么得来的?

答:我觉得应该有这些用例。

怎么来的?很可能是这样来的:想到数据库里可能会有设备的信息,所以给它刷上4个CRUD用例。同理,数据库里可能会有人员的信息,也刷上4个CRUD用例。一下子就找到了好多用例,需求规约就多了几十页,代码也可以写好一阵了,而且不用做什么思考,就可以刷这么多工作量,真爽!

【场景三】

问:“计算运费”这个责任需要哪些类?

答:简单,我有“运费计算器”类。

问:“运费计算器”类为什么能计算运费?

答:因为里面封装了“计算运费”的算法。

问:“计算运费”的算法具体是什么逻辑?

答:……(一旦无可逃避,可能就卡住了)

很多“面向对象”、“领域驱动设计”就是这样干的,车轱辘话转来转去,真正的复杂性却没有能力或不敢触碰。期望这样的做法能解决复杂问题,那真是见了鬼了。


有同学给我发了一个网络上的“领域驱动设计”课程让我评点一二,看完只能说一声叹息。

 

图片

图1 某“领域驱动设计”课程愿景截图

图1的“愿景”还真是“得来全不费工夫”,几句车轱辘话就搞出了一大段文字。

图1的文字类似于:

为了满足病人吃奥美拉唑和阿莫西林的需求,医生给病人开了奥美拉唑和阿莫西林,为什么呢?因为奥美拉唑有奥美拉唑的药效,阿莫西林有阿莫西林的药效。

这样的“思考”有什么价值呢?有价值的思考应该类似于:

为了解决病人胃酸返流的问题,医生给病人开了奥美拉唑和阿莫西林,奥美拉唑可以阻碍胃壁细胞上的离子通道,减少胃酸的分泌……

针对图1,不容易的思考是:

(1)哪家组织最适合引进该系统?

有价值的回答类似于:BJ市MTM公司。理由:MTM公司一年前创立,目前处于业务上升期,人员从**人增加到***人。

(2)该系统解决组织当前存在的什么问题?

有价值的回答类似于:

问题一、批假周期过长。经统计,过去一年,MTM公司从员工提出申请到最终审批结束平均需要***时间。

问题二、不合规的批假较多。经统计,过去一年,MTM公司的批假不符合公司规定的比例占*%。

图1中可能有价值的内容是淹没在车轱辘话中的“无差异管理”,不过光说“无差异管理”还远远不够。既然要追求“无差异管理”,那就说明目前的管理是“有差异”的,那请问是根据什么指标来判断目前“有差异”?达到什么样的指标才算是“无差异”?还有,“管理”到底指什么,是顺口带出来的还是有特定的意思?

(3)MTM公司当前是怎么请假和批假的,造成以上两个问题的原因是什么呢?

有价值的回答类似于:通过序列图或活动图画出MTM公司请假和批假的流程,找出其中的改进点。因为只是示意,我就不画图了,给出一张其他领域的图:

图片

图2 业务序列图示例

而网络上这个“领域驱动设计”课程是怎么做的呢?

图片

图3 某“领域驱动设计”课程战略设计截图

(1)拉“一群专家”来风暴?闭门造车?难道不应该是深入第一线去调研目标组织当前存在的问题吗?

(2)注意到那一堆创建、修改、查询了吗,刷工作量的嫌疑。

再看下面这个:

图片

图4 某“领域驱动设计”课程的分层

(1)同样的文字批量刷了三遍。

(2)最需要思考的困难部分:审批规则,却是一笔带过。看下图列出的源代码文件确实是如此,应该是变成了一个长长的“算法”放在了LeaveApprovalRule里面。

图片

图5 某“领域驱动设计”课程的源代码文件

(3)还可以看出一个问题,Leader就是Person,只不过在和另一个Person的关系中扮演Leader的角色,单独一个类不合适。

真正有价值的思考的结果,要能够把复杂的领域逻辑显式表达出来,类似图6。

图6 显式表达请假审批规则

图6中灰色部分显式表达了“请假审批规则”。

现在把“领域驱动设计”挂在嘴边的人里面,有多少人能给出这样的图呢?

“微服务”更是为不动脑子刷工作量提供了绝佳的借口,几十年前的“功能分解”借尸还魂了。例如要做一个“人”,思路特别简单。走路功能→走路服务→走路器官,游泳功能→游泳服务→游泳器官,什么人体解剖学不用管就可以刷出好多工作量,爽死。


没有免费的午餐,如果你觉得不用经过复杂的思考,就能解决一个能带来利润的问题,别高兴太早了,很可能你的答案是错的,甚至很可能你以为的问题根本不是真正的问题。

就像高考一样,前面几道题扫一眼就搞定可以理解,往后面做,如果觉得题目还是扫一眼就搞定,甚至觉得压轴题挺简单,那得好好想想了,是谁的问题。更何况,在市场上搏杀,做的何止是高考题,简直是竞赛题,哪有那么简单的!

所以,当我们得到某些答案的时候,要尽量想一想:这样的答案轻易想得到吗?如果轻易想得到,说明也许思考得还不够,还要继续思考。我们写的每一个字,画的每一张图,都应该是思考的结晶。

但这并不容易,不是所有的团队和人员都乐意和胜任这样的思考。人性使然,想那么多干什么,浑水摸鱼就好了,而且严密的思考需要一定的逻辑思维能力,许多人并不具备。

只有少数有“冠军的心”的团队和人员,希望自己的产品成为领域的冠军,才会有质量的诉求,从而带来提升建模技能的渴望。

退一步说,即使环境不允许你有“冠军的心”,如果你了解了这些用废话刷工作量的套路,当你需要应付了事刷工作量的时候,有意识地说废话也要比无意识说废话要“高效”——拿去哄人没问题,至少没有哄自己就行。


接下来是

脓包(5)发明家

不学习,不思考,动不动就说“我发现***”,弄出各种伪创新。

[2020.01加一套题]UMLChina建模竞赛题大全-题目全文+分卷自测(11套110题)


[新增EA023粮食拍卖系统]全程字幕-23套UML+Enterprise Architect建模示范视频


[幻灯]剔除“伪创新”和“无领域”的领域驱动设计-2月25日


北京3月13-14日剔除“伪创新”和“无领域”的领域驱动设计公开课


猴子掰玉米?比较不同版《领域驱动设计》说“不变式”和“聚合”


《软件方法》书中自测题-题目全文+分卷自测(1-8章)16套111题


《非程序员》电子杂志下载(39-51期)


《非程序员》电子杂志下载(1-38期)


中文书籍中对《人月神话》的引用(完结,共110本):软件工程通史1930-2019、实用Common Lisp编程……


CTO也糊涂的常用术语:功能模块、业务架构、用户需求……[20210217更新]


UMLChina服务介绍


图片

标签:鸵鸟,口号,建模,领域,思考,新装,方法,脓包
来源: https://blog.csdn.net/rolt/article/details/114066429