模块设计思想

转载：http://www.csdn.net/article/2015-11-06/2826139

我一般讲模块设计的时候，都会先讲架构相关的一些东西，首先架构师必须重视的第一件事情是需求，因为架构的目的是为了满足需求，这一点千万不能搞错。谈到架构，很多人都会喜欢说，我设计了一个牛逼的框架。但是我长期以来在强调的一个观点是说，框架这种事情其实在架构哲学里面一点都不重要，框架其实是实践层面的事情，架构真正需要关心的其实是需求的正交分解，怎么样把需求分解得足够的正交。所谓的正交就是两个模块之间没有什么太复杂的关系。当然正交是数学里面的词，我不知道其他人有没有会把它用到这个领域。但是我觉得正交这个词很符合需求分解的这个概念。

随着大需求（比如说一个应用程序，或者一个服务器）逐渐被切成很多个小需求，小的需求继续分解变成一个个类和函数。这一层层的需求分解的单元，本质上来讲，都是同样的东西，都是模块，只是粒度问题。所有这些app、service、package、class、func等，统一都可以称之为模块。那所有的模块，第一重要的是什么呢？是它的规格。模块里面最核心的，任何一个模块的规格是要体现需求。为什么我会说我是反框架的，因为框架其实就是模块的连接方式，不同的模块如何连接这个框架。那这种连接方式通常是易变的、不稳定的，因为框架是需要演进的。随着需求的增加、修改，它会不断演进，肯定后面会发现，之前搭的框架不太好了，需要重构。框架需要变的时候，通常很痛苦，所以也是很多人为什么重视框架的原因。但是不应该因为这一点儿把框架看得太重。因为不稳定的东西，通常是最不重要的东西。你要抓住的是稳定的东西。因此，框架只是实践程度可依赖的东西，但是从架构来讲不要太强调。

模块，刚才我讲了，模块其实最重要的是规格（接口），也就是使用界面，或者叫interface（接口）。对于一个应用程序来说，interface就是用户交互。对于一个service来说，interface就是api。对于一个package来说，就是包的导出的函数或者类。对于一个class来说，就是公开的方法。对于函数来说就是函数的原型。这些都是interface。模块的interface必须体现需求，否则这个interface就不是一个好interface。

总结一下，如果要提炼模块的最佳实践的话，我会提炼这样三点。

第一，模块的需求一定要是单一职责。就是这个模块不能做太多的事情，如果有太多的事情，它就要进一步的分解。

第二，模块的使用界面要体现需求。大家一看这个模块的界面，就知道这个模块是干什么的。比如一个软件，你下载下来玩的时候，一看就应该知道这个软件目的是什么，而不是看了好几眼都分不清楚这个软件到底是财务软件还是什么软件，那这个interface就太糟糕了。所以其实所有的interface都是一样的，都要体现需求。

第三是模块的可测试性。任何一个模块，如果提炼得好的话，它应该很容易测试。为什么这一点很重要呢？因为测试在软件系统里面其实非常重要，尤其是在服务端开发，尤其是像七牛这样一个做基础服务的，一个bug或者一个故障会导致成千上万甚至上百万的公司受影响，那么这个测试非常非常重要。可测试性包括什么呢？它包括把模块跑起来的最小的环境。如果一个模块耦合小，意味着外部环境依赖少，这个模块就很容易测试。反过来，很容易测试意味着这个模块的耦合很低。因此，模块的可测试性，其实能够反向来推导这个模块设计得好与不好。