摘要：大家要注意，对于任何一个事物的复杂性，往往它都是由多个维度、多个因素相互叠加而成。如果我们分析事物的复杂性，只从单一因素出发，就容易犯以点概面、以偏概全的错误。对于大型软件项目和软件系统的复杂性，也是同样的道理。

Hello大家好，我是人月聊IT。今天简单聊一下软件系统的复杂性。

大家要注意，对于任何一个事物的复杂性，往往它都是由多个维度、多个因素相互叠加而成。如果我们分析事物的复杂性，只从单一因素出发，就容易犯以点概面、以偏概全的错误。对于大型软件项目和软件系统的复杂性，也是同样的道理。

软件开发的首要任务和次要任务

在《人月神话》这本书中，作者将大型软件项目的管理和软件系统的设计分为首要任务和次要任务。他认为首要任务是将现实中真实的业务需求和用户需求转化为一种抽象的模型。而次要任务则是针对这个模型，将其转化为代码和可执行的程序。

软件行业发展了这么多年，在首要任务上，我们并没有找到一种能够指数级提升效率的方法。对于软件工程这个领域，没有所谓的“银弹”。

同时这本书在“外科手术队伍”这一章节中，作者又专门指出，为了保证整个软件系统的架构设计的概念完整性，需要将核心的工作掌握在一个人手中，类似于做外科手术的主刀医生。

所以，对于《人月神话》在谈软件复杂性的时候，更多的是从业务层面、架构设计层面来谈。首先是业务复杂，这才会导致我们技术实现上的复杂。

一切难以理解和变更的都是复杂性

包括我上个月讲的《软件设计哲学》这本书，它也谈到了软件的复杂性。它认为影响到我们对一个软件系统理解和变更的所有因素都是软件的复杂性，并且指出了软件复杂性的两个关键因素：依赖性和模糊性。

所以，《软件设计哲学》这本书更多的是从技术角度和软件开发实现方面来谈大型软件系统的复杂性。

但是，当我们谈依赖性的时候，我的理解是它其实不是原因，而是结果。我们不能犯因果倒置的错误，而应该去思考究竟什么原因导致了软件系统的集成和依赖关系复杂。

软件复杂性=业务*技术*治理

基于这两本经典书籍对软件系统复杂性的分析和阐述，我个人的理解是，我们应该从三个重要维度去理解软件系统的复杂性：业务复杂性、技术复杂性、上线以后的管控治理复杂性。

这三个复杂性刚好覆盖了整个软件全生命周期的过程管理。

对于业务复杂性，我们经常说的思路或解决方案包括业务建模、领域建模、MDA（模型驱动设计）、组件化、模块化、SOA横向分层，包括当前主流的微服务架构设计和微服务的拆分。这是从业务角度我们要去做的事情。

对于技术复杂性，更多的是我们在谈纯技术架构上面，如何支撑整个软件系统的高可用和高并发。对于这一块，我们经常谈到的类似于集群、分布式架构，负载均衡、数据库底层的水平拆分垂直拆分、读写分离、消息中间件、缓存、分布式事务处理等，我把它纳入到技术复杂性。

对于治理复杂性，则是一个系统上线完成后，你怎么样去运维、监控、观测它，以及如何应对软件系统后期的变更。在这个地方更多的解决思路首先是要做好底层的过程支撑，类似于研发过程管理、当前谈的比较多的DevOps的持续集成和持续交付，包括从资源到服务、从服务到应用的整体IT资源服务、应用链路监控，包括类似于混沌工程、面对可观测性的设计，都可以把它纳入到管控治理层面。

所以说，一个大型软件系统的复杂性一定不能从单一维度来看，它往往是业务、技术、管控治理三个维度的相互叠加，而且它不是简单的累加关系，它往往是一种相乘的关系。由于存在这三个维度的复杂性，再一相乘，整个复杂性就出现指数级的增长。

对于任何一个大型的软件系统或软件项目，我们都要从这三个维度去思考复杂性。类似于很多互联网的架构师，他们其实更多的是解决技术复杂性的问题，但到了很多B端的企业，去做大型的B端业务系统，如ERP、CRM、SCM系统的时候，往往做得并不是特别好。其中关键的一个原因就是他们期望通过技术复杂性去解决业务复杂性的问题，这显然是不正确的。

我们做任何的软件大项目或软件架构设计，一定要从业务、技术、管控治理三个方面充分意识到整个大软件系统软件项目的复杂性，这样你才能够把整个软件管理好、设计开发好。

好了，今天的简单分享就到这里，希望对大家有所启发。再见。

来源：人月聊IT