导致企业应用软件难于治理的根源分析 一.? 独狼程序

开门见山、单刀直入，面对企业应用软件之挑战和困局，我们来剖析它的根源，研究它的治理之道。首先从一首沁园春开始：

沁园春·新纪元

软件工程，乱象丛生，风雨飘摇。

看国内国外，疲于奔命；

理论实践，为证达标。

独狼程序，单体应用，软件世界竞魔妖。

何如故，究根源深处，问遍群豪。

请了专家元老，

用原型敏捷亦折腰。

惜企业架构，纸上侃侃；

治理体系，空中飘飘。

捉贼擒王，治病寻根，管控一体效率高。

莫急怨！待双剑合璧，诸乱皆消。

企业应用领域问题很多，顽疾难治。我们在过程管控、IT治理、各种标准认证各个方面，做了很多努力，尝试各种方法，但效果都不明显，这说明我们没找到病根，那么“独狼程序”、“单体应用”就是根源吗业架构和IT治理到位了就可以解决问题吗/p>

这些问题我们可能会有不同意见，大家观察角度不同，观点不同，无所谓对措。我们都是努力在各自的角度探索症结、寻求良策。

捉贼擒王，治病寻根，正确的过程未必得到正确的结果，但不正确的方向，却一定无法达到目的。

下面我们就进入寻根求本之旅。

独狼横行

自1946年计算机诞生至今，软件就相伴而生，已经快有80个年头（我是说它该成熟了），为提升软件开发效率和软件质量的努力在持续进行。我们发现计算机硬件以摩尔定律的速度不断发展，计算能力、存储能力不断增长，完全是超越需求的态势，操作系统、数据库、中间件、高级语言、OO技术也在快速的发展，可是应用软件领域的发展却困难重重！好的前面说的只是自下而上的努力，事实上我们自上而下的努力也在不断的深入，从IT治理到软件工程、需求理论、设计方法、编码工具层出不穷。反观应用软件领域自身，未见有明显起色，倒显危机深重，大有越治越乱之趋势，我们真像美国软件大师——Frederick.Brooks（以下称布鲁克斯先生）在《人月神话》中描述的场景：史前巨兽在焦泥坑中挣扎——越陷越深。

几十年来应用软件已经遇到多次危机，现在仍然在黑暗中徘徊，如何走出黑暗迎接光明/span>

高效的工业化生产方式和管理理念成为我们首先想到的学习榜样，于是工程学、管理学的理论和方法被引入到软件工程中，大量的平台和工具被开发运用，但效果甚微，究其根源，工业的生产过程是简单再生产，软件生产是一个创造性劳动过程，不存在简单再生产，简单再生产对软件而言就是复制（Copy）,软件可以瞬间复制出你想要的若干复制品（一模一样、丝毫不差，工业生产过程努力追求的结果，软件领域按一个键就可完成），这样的工作在软件过程中是不需要管理和控制的，软件工程是创造性活动，简单再生产的管理体系不适合于软件工程。

但在工业体系中的设计过程也是创造性工作，因此工业体系中的设计平台乃至设计即制造的体系的确十分值得软件工程学习和借鉴。

复杂如大飞机和拥有几十亿晶体管单元的CPU，都有专业的设计软件，更可以直接与生产设备对接，实现设计即生产！可见软件在现代工业和生产中发挥着关键的核心作用，甚至可以说没有现代工业设计和生产软件，就没有现代工业。

但反观软件工程领域，我们却几乎没有设计平台，更谈不上设计即生产了，“泥瓦匠住草房”，我们为工业开发了如此专业、强大的设计和生产平台，但自己却无屋跻身，没有软件设计和生产平台可用，生产方式基本停留在手工作坊状态。（可能会有不同的声音：我们有许多令人炫目的工具呀，可视化编程环境、原型设计工具、需求平台、建模工具、ER图、UML……好多好多啊。没错，我们是有，但它们只是简单的个人工具，类似于“刀、钻、斧、刨”，亦或是高级电钻。）

这是软件生产效率低下、成本高昂的原因之一，但亦非本质。生产工具决定生产力，应用领域急需现代化的软件设计生产平台。

我们再换一个角度思考，手工就手工，我们可以不计成本开发出一个企业应用系统，如果它能够持续发展，不断适应业务的发展变化，能够满足企业长期发展的诉求，开发过程的艰辛和成本的高昂是可以接受的，但情况不是这样，我们发现软件“不软”，非常僵硬，修改、拓展都非常困难，而业务是必须发展变化的，企业的内部、外包环境总在变化，IT技术也在不断推陈出新，即使有高效的软件生产平台，做出如此僵硬的系统，也难以满足企业的发展要求，总不能每月重做一个系统吧。

因此我们不仅需要软件生产平台，更需要能生产出来“可发展的应用系统”的平台。

这要求就有点高了，我们知道软件生产平台也只是一个工具。一个没有艺术素养和职业训练的人，用世界上最好的画笔也不可能画出传世之作，这就是工具的局限性。

我们需要这个软件平台内置方法论、企业模型、最佳实践……，引导开发者做出“可发展的应用系统”，嗯，这要求的确越来越高了，但这还不够，后面我们还会对它提出更高的要求。

没有这样的平台我们能做出好的应用系统吗答是肯定的，能！如果不能，靠平台也不能。但这不是否定我们对平台的渴望，平台可以大大提高生产效率和质量，能引导一般的团队做出杰出的系统。

为什么说没有平台也能做出可发展的应用系统呢为软件设计领域的最高要求就是“开闭”原则，满足该原则的系统就可以不断适应变化、持续进化和发展了。但是咱们的分析师、设计师、工程师们在开发过程中将这个原则还给老师了。当然这不完全怪他们，就像不能完全怪“独狼程序”一样，还有其他原因。

我们先看看导致软件做的如此之硬的核心问题：独狼程序

目前应用系统的设计开发基本上是面向功能的，功能通常是易变的，面向功能的设计往往无法得到一个良好可发展的应用系统，那么应该面向什么呢，我们后面在谈。

面向功能还不是最严重的，它只是一个起因，关键问题出现在我们实现这个功能时，程序试图“独自”完成全部业务处理逻辑，这听起来似乎没错，但问题出在“独自”上，而且这个问题非常严重，称之为万恶之源亦不过分。

下面举一个实际例子，会做许多简化，只为说明问题，不妥当之处，大家补充细化，深入研究一定会有收获。

一个勤奋、责任心极强的程序员小秦，开始编写“订单支付”的功能，他从订单读取、支付接口调用（幸好支付接口是封装好的，否则他也要亲自实现了）、记账、库存更新，直到更新订单状态，都认真的用代码进行严格的逻辑表达，更重要的是他都是对相关的数据库进行的直接操作，这些工作看起来都是必要的、必须的、应该的，不然怎样呢！这是一个很能干的程序员，他了解那么多细节和逻辑，程序写的非常好棒，没有一个BUG！获得了五颗小红花。

但是问题来了，几天后，订单系统要求记录出库时的时间戳（原来没这个需求），这时“订单支付”要修改，需要增加一个字段，取一下系统的时间戳，更新库存时把当前的时间戳也写进去，这好像并不困难（但我要说的是这本与“订单支付”这个功能无关）。又过几天，记账方式要调整，原来采用的是收/付记账法，这次要改成借/贷记账法，麻烦有点大了，小秦很聪明，他用了两天时间掌握了借/贷记账法的业务知识、基本逻辑和规则，用了一天时间研究清楚了两种记账法的根本差别，于是他给出了解决方案，又熬了一夜，改完了代码，第二天顺利的通过了测试，他的确很能干！

如此下去这个“订单支付”功能要永无宁日了，其实这些本该与此功能无关！

事情还不止于此，我们再来看看复杂度，按某过程复杂度计算模型：

过程复杂度 = F（输入/输出数据种类数，主要输入输出变量个数，用到的数据库数量，使用方式）。

具体计算方法从略，这里只是用它来说明问题。

我们把整个过程拆解开，分别获得各自的复杂度如下：

    按同样算法计算，“订单支付”的复杂度 = 36.5

我们看到“订单支付”的过程复杂度是5个独立过程复杂度之和的3倍还多！

应用系统为什么难为它复杂，为什么复杂，就是这样制造出来的！

        软件何其难！“独狼”里边站，

        复杂又僵硬，人造虚空幻。

注意，这种系统的复杂度是人为制造出来的，不是客观的。

人类的智慧是努力将复杂的问题简单化，分而治之。“独狼”反其道而行之，制造了比问题域更复杂的代码。

事实上，如果每个部分有独立的模块或服务处理自身内部逻辑，“订单支付”仅通过调用相关服务实现订单支付逻辑，这时它的复杂多可以降低到2.0，进一步，这个过程可以通过可视化过程组合定义，复杂度可以降到过程配置级的1.5，还可以再进一步，“订单支付”这个过程就是业务系统定义的关于订单支付的具体制度，软需阶段就可以明确定义，将制度对象参数化，配合运行平台的制度执行器，可以跨越设计和编码，零开发实现，这就是所需即所得，我们可以认为这时复杂度降到了0.0，至少它的复杂度降到了参数管理级；如此分析我们是有能力将问题域的复杂度降低的，甚至低于其本身。

可见“独狼程序”的复杂度是远远超越了问题本身，您可能会说“独狼”这种低级的错误我们是不会犯的，但实际情况不是这样，我们随意打开代码审查，“独狼”无处不在，而且种类繁多（上面的例子只是其中一种—显示的，还有隐式的、半显半隐的），软件工程师们总是那样的勤勉，试图处理功能的全部逻辑，他们特别关注各系统中的数据库结构，了解细节、相互关系和底层逻辑。我遇到一个最极致的实际应用系统，它们的每一个交易，都在独立、全面地处理着所有逻辑，从接受 文、拆包、业务处理、记账、组包、发送 文，没一个交易几乎就是一个独立的系统，每个功能就是一根烟囱，没有夸张的确如此。我们千万别觉得这很可笑，认真审视自己做过的系统，我们会发现不过是五十步笑百步。

有人可能会争辩道：我们都是在一个做好的程序基础上，“拷贝粘贴”过来，按需修改，很方便的。是的，这很好，“拷贝粘贴”真方便，比做一个螺丝钉都简单，这是我们软件的优势啊！我要说“拷贝粘贴”是仅次于“独狼”的恶习，我不是反对拷贝粘贴技术本身，我们每天都在使用它，我是反对“拷贝粘贴”的编程方法，在应用系统中一段逻辑或者数据，如果它是一致的，就要直接引用或调用，而不要“拷贝粘贴”，一粘贴就变成两个东西了，就增加了治理的难度。功能的集约化和数据的一致化都是IT治理的重要因素。

这么任劳任怨的“独狼程序”它错在哪里了呢/p>

首先，从技术角度它违背了“信息隐藏”的设计原则；

其次，从业务角度它破坏了职责分工（然后它就破坏了人工系统具备的灵活可发展能力，这一点需要慢慢理解思考，后面还会谈及）。

真正的业务领域不存在类似“独狼”这样的“超级业务员”，它什么都能干，什么都可以干。事实上，即便你是CEO，也不能到库房直接拿东西，到会计室亲自记账。这不符合业务制度和岗位分工（CEO通常也不知道会计如何分录，如何记账，术业有专攻），业务系统是一个合理分工、易于发展变化的系统，它是业务领域长期发展的智慧结晶。

“信息隐藏”原则是说不要暴露实现细节，“独狼”直接实现了细节，这情况就更加严重了，后面我们会总结“独狼”的几宗罪，以引起我们对它的足够重视。

布鲁克斯先生1986年发表了《没有银弹：软件工程的本质与次要工作》论文，他论述了软件工程的困难，也试图从各个方面探寻解决思路和方案，但最后的结论是：没有银弹！——未来十年不会有一种理论、方法或工具的进步，能够本质上改变软件工程的现状。

事实上，如果没有“独狼”，或许就不需要“银弹”了！这才是IT治理的根本之道。不是消灭“独狼”，而是不产生“独狼”才抓到了问题的本质。

让软件系统的复杂度不要超越业务本身！

当然，没有“独狼”还会有“巨石狼”、“架构狼”、“管理狼”、“治理狼”等等，这里我们是先把“独狼”拿出来狠批一番而已。

“独狼”的问题不在程序员，而在于有它的生存环境和土壤，在于我们的方法体系出了问题，在于我们没有对应用软件过程进行深刻的反省，甚至鼓励、诱导“独狼”的编程方式。

避免“独狼”首先要从规范入手，再通过科学的架构约束，重要的是我们要从业务需求入手（参见https://mp.csdn.net/console/editor/html/107580621），最根本的方式是各个独立域不对外暴露数据库结构，让“独狼”无处下口。

回到前面说的没有软件生产平台能否做出好系统，我们说能，当然是有前提的，我们必须努力构建不产生“独狼”的土壤，注意这很重要，为此经过认真思量，合理划分出业务域、业务组，像人工业务领域学习，合理分工，就会形成合理的业务层次、业务域，科学的服务粒度等等，良好的架构就形成了，如果再充分做到三个分离和一个整合，就可以构建出优雅的系统了。

• 变与不变分离

• 数据与逻辑分离

• 应用与技术分离

• 业务知识（业务参数、制度、流程、法律法规等）整合

前三项这里不展开叙述，后面涉及到时会详细介绍。

业务知识整合是一个大题目，其实在业务域中，主要就六大项，行为主体、服务或产品、业务数据、业务知识和客户，其中业务知识（业务参数、制度、流程、法律法规等）作为一个非常重要的业务对象，往往没有被我们完整的认知，被我们零散的、碎片化的分散在系统各处，或参数、或代码、或流程、或规则……，失去了整体视角，很难一体化维护。没有作为一个完整的对象进行整体考量和设计。为什么人工业务领域能够快速适应需求发展变化，因为有完整的业务知识体系，为什么应用系统僵硬难于变化，其中另一个重要的原因就是系统内没有数字化的业务知识体系。

治理了“独狼”，做到了三分离，数字化知识体系和执行机制没建立，离“可发展的应用系统”还有一步之遥。

“独狼”的几宗罪：

1. 无谓的增加了系统的复杂度，导致开发、测试、运维、发展之困难。

2. 将不同的业务逻辑、业务数据粘合到一起，导致系统沉重、僵硬。

3. 未能抽象出可独立共享的业务逻辑，造成系统功能集约度低下，大量对水平重复开发。

4. 严重背离设计准则和业务场景，制造大量“洪水猛兽”，使系统难于治理。

尽管“独狼程序”危害巨大，但根不在它，我们要深入研究导致独狼的根本原因，才能找到治理企业应用系统的根本之道。

文章知识点与官方知识档案匹配，可进一步学习相关知识Git技能树首页概览2930 人正在系统学习中