复杂系统设计开发的正道和关键

 

经常见到一些开发人员在讲，使用框架（例如Spring、ORM）是为了解决复杂度的问题，系统太复杂、业务太复杂，如果不用这些，做起来岂不是非常困难？

 

对此，我的看法是，期望工具解决系统复杂度的问题非常不现实，它们起到的是实现（代码）阶段的一些规范化和减少代码量，使程序员对于一些通用类型的模块和工具不再重复工作，但是对真正的系统复杂度，大体上是无能为力的。

 

复杂度的问题，我更赞成的是“系统复杂，实现复杂；系统简单，实现简单”，复杂系统设计和实现非常简单，是不切实际的幻想；简单系统，做的无比复杂，设计师难辞其咎。

 

真正的复杂度降低，应该是靠系统分解来做到的，完整系统切分为一系列相互依赖和通信的子系统组成，合理切分，合理定义依赖和通信是关键；子系统如果还复杂，要切分为模块，模块间一样存在依赖和通信，也需要合理定义；如果模块还是非常复杂，要定义其中的子模块，再往后，定义其中的程序单元（例如包、类、函数等等）。

 

说整个系统是复杂的，这个是常见的现象，甚至说，一个子系统复杂，也很正常，但是你要是经过多次切分，到了一个程序单元那里，还复杂无比，那说明架构师不称职。

 

就像做一把椅子，设计师定义好椅子面、腿、靠背的样式、尺寸以及它们相互对接的部分的明确要求，每个部分实现都不复杂，每个部分只要按照架构师给它的“部件需求规格说明”来设计自己的部分即可。而且，架构师也不用管部件的设计细节，定义先用锯子还是先用刨子。在一个“椅子产品”的设计和实现中，架构师和部件设计实现者各司其职就可以了。

 

实际的软件系统当然比作一把椅子复杂得多，但是这个例子中的方法，是解决复杂度问题的正道。没有工具能够解决你特定业务的的复杂度，因此，应该把一个称职的、优秀的架构师，作为系统设计和开发的核心，这样，才能做到《道德经》说说“挫其锐，解其纷”，做出好的产品。