本文主要是介绍《软件方法》第1章2023版连载（05）伪创新泛滥，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集
1.2 建模工作流
1.2.4 不了解ABCD的危害
1.2.4.2 伪创新泛滥
很多开发人员只有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-设计”。
无论是启发、定义还是验证，如果你思考的内容是某一个工作流的内容，你就是在做该工作流。在一个迭代周期中，启发、定义和验证往往是交错进行的。
要成功完成一个软件开发项目，还有很多其他工作，例如过程管理、人员管理等，这些都不属于本书讨论的范围。
本书只关注方法学，即A→B→C→D的正确推导方法，至于推导是一个人做的，很多人做的，甚至是猫做的、狗做的、外星人做的，没有直接关系。
还是用前面的大楼类比。两幢大楼耸立在那里，地震来了，一幢塌了，另一幢没塌。
直接因素是大楼的结构、所用的材料、所在位置的地质环境等，这些涉及到艰深的工程力学、流体力学、岩土力学等知识——类似于本书所研究和阐述的方法。即使大楼是外星人盖的，也要讲这个基本法。
有的人思考不了难理解的直接原因，干脆找比较容易理解的其他原因，例如，嚷嚷“有人吃回扣了”，就算经过调查没人吃回扣，他也会从工作服的颜色，工人是否结对洗澡，施工队开会时是否站立等容易理解的方面来找原因——本书不关注这个。
这篇关于《软件方法》第1章2023版连载（05）伪创新泛滥的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
