在具体开始讲Robert C. Martin提出的The Clean Architecture之前，我希望就软件的复杂性谈一谈我个人的一点浅见。

《面向对象的分析与设计》这本书的前面几章，专门就阐述了作者对软件的复杂性的理解，非常有深度，建议阅读。

但我仍然想谈一谈我的思考。我个人理解的软件的复杂性，主要归纳为三个方面：

• 软件的现实问题与业务映射的复杂性
• 软件开发技术的复杂性
• 软件开发管理过程与人的复杂性

一）

先说第一点。

软件是什么，如果简而言之，软件就是试图基于二进制的计算机及其衍生的互联网及其它的机器来模拟及映射现实背后的问题与业务。

所以，这里显而易见存在两个方面的难点。第一个是准确理解现实业务的复杂度，第二个则是用无感情理性的机器去映射有感情无理性的人及背后的业务的复杂性。

这两个显然都是不好解决的。

对现实的理解是复杂的

软件行业发展这么多年，为什么面向对象的语言成为主流，而不是面向过程或面向函数？我认为一个重要的原因就是因为在所有这三种编程范式中，面向对象是最容易映射现实的。面向对象的语言把现实理解为一个个对象，对象包含属性与行为，对象之间有交互，这几乎与现实是一致的，至少在大体上是非常一致的。

但现实或业务是非常复杂的，事实上很难有一种标准化的方式能够将需求能够无偏差的转为软件的设计与实现。

这就导致了很多时候软件的理解与实现压根并不正确。从源头上来说，软件就可能会出现差错。

无感情理性映射感性的现实的复杂性

编程也好，技术也好，软件也好，它们的共通性就是它们是理性的东西。当我们试图用语言，技术，框架构来准确的描述现实业务时，我们是期望现实也是理性的，可以客观的衡量的。

但我们都知道不是如此，现实是非理性的，或者说某种程度上是难以预测的。

用理性的计算机来映射非理性的世界，自然就会出现不一致。

这就导致软件永远面临一个困境，就是需要反复的修改与不断的迭代。

二）

软件技术是复杂的。

随着计算机与互联网的繁荣与发展，今天做一个软件在技术的复杂度是不言而喻的，以前一个服务一个机器就能搞定的软件，现在可能背后需要成千上万的服务来交互与支撑。

不同的技术发展，不同的框架，不同的架构模式，虽然各有适合的场景，但对于今天的架构师来说，使用技术来构建一个稳固的软件，是越来越具有挑战的事情。

不同的技术选择越来越多，这其实也反应出软件越来越复杂，需要越来越多的技术来支撑与实现。

永远没有停滞的技术更新，新的技术，新的方法论，新的架构模式，技术人员圈内，一句调侃话语是：“求不要再更新了，学不动了”

就算是有现成的方法论与架构模式，让你知道它是非常合适你当下的场景，但仍然有很大可能，应用它仍然会是失败的。

妥妥的证明，软件技术的复杂性。

三）

软件开发的过程，本质上就是人沟通与合作的过程。

我认为软件开发，与足球可以做类比，都是团队的过程。依靠一个人能搞定一个软件的阶段早已不适合当下的软件开发及需求了。

架构师，开发人员，产品经理，项目经理，测试人员；想像一下，一个再简单的软件开发过程，都需要一个团队，不同角色的人共同合作来完成。

但软件开发与足球运动又有显著的区别，足球运动的参与方共享着同一个知识理念，大家都认同或知道足球怎么做才是最好的，而软件开发团队则完全不同，不同角色对如何做好一个软件的认知可能完全不同。

技术人员更偏重技术上的一些知识点，管理人员更偏重管理过程，进度与交付等，产品经理更关注对需求的理解，产品的体验，这些人员之间是存在知识跨界的。技术人员可能压根不明白管理是一个复杂的事情，而管理人员则也很难理解所谓的技术质量这种看不见的东西要怎么做才是恰当的，至于产品经理对需求的理解导致的频繁需求变更也更加令技术人员厌烦这就是业界人所共知的现状了。

这样一个团队，沟通与合作起来，想要顺畅，并不是件容易的事。人与人的合作本来就不容易，一个任务，由知识不共享的不同的人来合作，要做好就更难了。

这就是管理过程的复杂性。

四）

这就是我理解的软件的复杂性。由三个维度组成的，软件对问题理解与映射的复杂性，技术本身的复杂性以及管理与人的复杂性。这三个复杂性相互交织，造就了软件的复杂性。

而Robert C. Martin提出的The Clean Architecture这个整洁架构，我认为它仅仅在上述三个复杂度中，是对技术复杂性的值得我们技术人员探究与思考的。

所谓的整洁架构，是为了降低技术上的复杂性。而对于问题域的复杂性以及管理与人的复杂性，并不是这个架构能够解决的。

但做为技术人员，尝试在技术上降低软件的复杂性，这是我们义不容辞的责任。