前言
在前面关于ScalableIO的博客中我提到程序设计其实是一门管理科学，好的软件架构是在构建一个好的管理模型。有读者给我私信希望我就软件架构与管理这个话题展开聊一聊。这个需求真是不好接。因为在这个方面，之前我只是抓住了一些零散的感悟，并没有形成一个系统的思考。这个星期我也尝试着把这些零散的点串联起来，同时查阅了一些资料，总结了这样一篇博客。
定义
要探索两个事物之间的联系，我认为首先要理解他们的定义。很可惜，我没有找到公认的绝对权威的定义。借助搜索引擎找到几个我认为比较靠谱的解释。
关于管理的解释：
-
广义的管理是指应用科学的手段安排组织社会活动，使其有序进行。狭义的管理是指为保证一个单位全部业务活动而实施的一系列计划、组织、协调、控制和决策的活动。
-
所谓管理，是指同别人一起，或通过别人使活动完成得更有效的过程。
关于软件架构的解释：
-
软件架构是指一个系统的基础组织，它具体体现在：系统的构建，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则。（IEEE1471-2000）
上面都是教科书式的条款，乍一看好像没什么营养，似乎都是人人都知道的道理。因为要写这篇博客的关系，我认真地对这些概念进行了思考和资料搜索。我圈几个点，后面详细解释的时候会用到。分别是组织，构件，协调，决策，变化。这些关键字都是从上面提取出的，下面我们一起来看一下，这两者之间有什么联系。
组织
我这里说的组织是一个动词。就是将一组对象聚集起来，为了同一个目标去做事。在管理中这个组织的对象是人或者部门。在软件架构中组织的对象是构件（模块）。这两者差别看似很大，因为人是有自己的思想和情绪的，而代码是没有自己的思维的，如何能够相提并论。是的，由于组织的对象不同，所以我们在实施过程中所使用的技巧，需要的能力，知识，肯定是不一样的。但是我认为从实施准则上来说，两者是一致的。下面我们就来具体说说。
切分
组织行为是对一系列对象实施的。那么对于组织者来说是不是应该先决定一下每个对象的职能是什么，到底需要多少个对象。这就是功能切分。对于管理来说，就是要决定用多少人，每个人做什么事情。对于软件架构来说就是要决定系统划分为多少个模块，每个模块的功能是什么。那么这个划分的准则是什么？这就要回归到组织活动的目的。
对于管理来说，目的是降低成本提升效率。如何提升效率，我认为应该是专注和专业（可以参考流水线生产模式）。帮助个体划分一个simple和clean的职能，能够帮助他提高专注度，最大化生产效率，而且能够提升生产质量。因为专一所以高效，因为专注所以专业，因为专业所以质优。所以为了追求极致的效率，管理划分的准则是专一。
对于软件架构来讲，目的是帮助软件系统更好的应对环境的变化，嗯，是更好的应付产品经理。他的模块划分的基本准则就是我们常说的那句高内聚低耦合。高内聚就是专一。一个模块内部封装同一类别的功能，同一类功能也一定要放到同一个模块内部避免实现分散，这就是高内聚。这样在应对未来的变化时，我们才能够以最小的变化代价去满足产品的需求。
可见在划分活动中，虽然各自的目的不同，但是管理和软件架构所依赖的基本准则是一致的，就是专一。
组合
有切分必然有组合，组合就是为了形成切分个体的最大合力。回归到管理提升效率的目的上来。如何提升，我认为应该是简化，就是个体之间需要对接的内容越少越好，这样才能降低沟通成本。将每个个体之间的交互依赖降到最低，帮助个体更专注更高效（构建一个独立的执行环境）。可以通过两个手段，首先在边界划分的时候就简化和明确边界。第二个是将对接的功能进行聚焦，如果边界实在无法简化，则可以将边界对接的职能聚焦到独立个体身上，从而保证大部分个体的专注。
对于软件架构来讲，组合的基本准则就是低耦合。低耦合的目的就是减少模块与模块之间的接口依赖。将模块之间的依赖以数量有限的标准接口的形式定义出来。通过标准接口依赖的方式能够帮助我们在软件变化的过程实现模块的插拔式替换，从而更灵活的应对环境的变化。
可见在组合过程中，两者的基本准则都是简化连接。对于管理来说这样可以降低沟通协作成本提升协作效率，对于软件架构来说可以降低模块替换成本提升架构灵活性。
变化
阿里有一句土话叫做“唯一不变的就是变化”，相信很多人都听说过。所以变化是常态，外部环境，需求变化了，我们的管理流程和系统架构也要随之变化。为了应对变化，要勇于“及时重构”。没有一个人能够看到未来，因此在管理流程和系统结构上总是会有缺陷。当发现不能适应新的环境，或者感觉到应对吃力的时候。我们的组织架构，系统架构都要及时重构。阿里的逍遥子曾经说“我们总是在最好的时候变阵”，这里的变阵就是管理重构。对于软件架构来说及时重构更是一个基本准则（推荐一本《读代码大全》）。
说了这么多空话，来结合Web开发中MVC分离的思想，来对比介绍一下。我们知道MVC分离的思想是一套非常成熟的Web层次划分准则。其中DAO层与业务解耦就是非常重要的设计。但是我之前看到一些工程师在开发过程中违背了这一准则。将大量的业务逻辑下沉到DAO层，通过SQL的方式实现一些业务关联逻辑（通过多表JOIN 的方式）。这种方式违背了分层思想。一旦外部环境发生变化，比如说数据量激增需要进行分库分表操作或者要切换到NOSQL数据库，这种实现方式就会被彻底颠覆，重构代价很大。更进一步分析，这个实现有一个潜在的边界连接关系。就是数据库性能的影响。一类复杂的耗时的业务SQL，可能会将其他业务的数据库请求BLOCK，造成大面积的业务超时。这就是因为设计者违背了模块划分尽量单一，模块间连接尽量少的设计原则导致的。
后话
最近翻看一些资料发现我这里的比较还是很片面的一部分。这里主要还是从做事的角度来进行分析的。实际的管理还涉及很多方面，比如个体热情激发，能力培养等等多个方面。除了做事，管理还需要考虑个体的情绪，能力等等。而在软件架构中，还要考虑使用技术的物理边界，这也导致两者在执行和决策时需要不同专业能力。
以上是我结合软件架构设计中的一些感悟进行的简单分析，有点牵强附会了，欢迎大家交流。再次推荐《读代码大全》。
