业务中台探索和实践：软件的根本问题.docxVIP

业务大陆与台湾探究和实践：软件的根本问题 众所周知，软件行业一直受人月定律的困扰，简约陷入到“史前巨兽的焦油坑挣扎”之中。一些进展快速的软件公司往往数年之内从几个人的小作坊快速膨胀为几千几万甚至十几万人的大型工厂化组织。越是浩大的动物越是笨重。这些浩大的公司，往往组织效能低下，大公司病严峻，甚至最终无法应对任何变化。即便不那么浩大的公司，也会受困于软件焦油坑的各种症状。业务需求频繁，技术却响应不及、质量堪忧；新功能上线，老功能出问题；老功能修复，新功能出问题；系统三天两头宕机。 开发人员埋怨代码简单到看不懂，不敢动；埋怨产品和市场乱提需求不专业。要产品走需求审核流程；产品找管理层和市场部门来一起施加压力。测试团队埋怨开发代码 bug 频出，按起葫芦起了瓢；bug 分布的规律性和随机度难以猜测，假如全量测试会导致测试资源不足压力过大，不全量测试这个锅我没法背你们找别人想方法。开发让产品和市场证明：时间紧任务急，来不及设计……，否则以后就让产品提需求写邮件按手印。产品表示这些听起来都是技术问题，技术问题我不懂，反正都是你们技术内部的事，你们本人去打算怎样处理。架构师表示你们产品和技术往往直接对接，不经过我，我无法介入；我给的架构建议也没有看到多少落地。技术经理表示，架构设计的周期过长，大部分需求比较小和零碎，时间周期较短，项目周期上不合适嵌入架构工作。挑出时间进行架构优化呢，最终效果往往不能令人满足。 群众吐槽，架构成天争辩些高并发分布式微服务容器化……，对我们并没有什么挂念；我们不是阿里不是腾讯，没这些挑战；我们真正关怀的快速响应业务、机警性的市场运营、测试的平安牢靠你们没给多少支持；大数据挺新潮，但是连个日常报表的需求实现不了了；微服务宣扬的是挺好，但是你们把系统从几个拆成了几千个，做起事情光找人和协调都累吐血……。技术包装和名词是越来越绚了，但做事情的速度是越来越慢了（当然现实中这一段话不行能公开发生，这是私下的频繁吐槽）。 软件研发陷入了这样的情况，工作越做越多，问题越做越多，考勤时间从 996 渐渐滑向 997 乃至……；团队内部相互埋怨，压力巨大，协作效能下降，工作氛围恶化，离职率提升，工作产出更低，负反馈循环。 不幸的是，这是很普遍的情况。并且愈演愈烈，不行忽视。唯快不破的互联网公司们发觉，本人渐渐变成了本人国企那样的笨重。有些公司要结构优化，有些公司内部渐渐有了工程效能部。有些公司开头大张旗鼓的要做大陆与台湾。 人月定律真的是不行以克服的么？或者说我们已经做到了理论上的极限了么? 我们过去的路正确么？正确的话为什么现状是这样的？不正确的话问题在哪？我们现在的路是正确的么？它和过去的路有什么本质差异和不同？我们有决心么？决心来自哪里？ 软件的本质 前面谈软件研发中的种种问题可以简化为《人月神话》中说的人月定律。但软件工程为什么会遭到人月定律的制约？其深层次的基本原理是什么？ 软件受人月定律制约，其缘由不行能是由于人月定律是什么，而必定是软件和软件工程是什么。若为不行规避的，随时随处体现的顽疾，则必为软件的本质因素所打算。人月定律的确为软件不行规避的顽疾，却也并非随时随处肆虐的外症。FrederickP.Brooks.Jr.（人月神话作者）用突然变异为人狼的村民来描述它。所以它必定不是软件或者软件工程的本质本身，而只能软件和软件工程的本质有关系，也必定需要肯定的条件才能触发。 软件的本质什么？这么重要的问题，搜索一下会发觉这个问题少有人探讨，已经我搜索、比较和思考过很多答案，都不能让我满足。直到有一天我发觉《人月神话》中有这么一段作者使用了格外格外大力气的描述词标记，但是少有人关注和引用的话： “一个相互牵制关联的概念结构，是软件实体必不行少的部分，它包括：数据集合、数据条目之间的关系、算法、功能调用等等。这些要素本身是笼统的，体现在相同的概念构架中，可以存在不同的表现方式。虽然如此，它仍旧是内容丰富和高度精确的。 我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程度进行验证。当然，我们还是会犯一些语法错误，但是和绝大多数系统中的概念错误相比，它们是微不足道的。假如这是现实，那么软件开发总是格外困难的。天生就没有银弹。让我们来考虑现代软件系统中这些无法规避的内在特性：简单度、全都性、可变性和 不行见性”。——《人月神话——软件的根本困难》 变化并非是全部软件的本质属性。很多软件功能特性是不变的，这种软件极少有听说研发陷入顺境的；变化的越频繁，变化之间的差异性越大，软件研发陷入泥沼的概率越高。尤其是大家常见的需求频繁开发周期紧急的业务类软件。 基于软件的本质：概念和概念对的关系，比较一下物理学中引起核子爆炸的链式反应你会发觉：在软件中各种要素同样相互影响，耦合，牵一发