浅谈业务与架构

背景

题目起的有点大，其实只是想随便说说。最近工作中遇到一些事儿，发现很多人其实迷失在其中，违背了一个亘古不变的真理：越简单越不容易出错。我来详细说说我对于这个真理运用在程序编写，产品制作上的一些理解吧。

分层架构意义何在？

很早很早以前，大概是我还在玩泥巴的时候，IT圈子中的大牛们就已经意识到彼时的程序就如果面条般混乱不堪。于是乎，由一个大牛牵头，各方诸侯呼应，探索并制定了一系列软件开发的方法论，我们称之为『软件工程』。

从那个时候开始，就讲究分而治之。从很多的案例以及算法中都能看到这个思想的影子。如：快速排序，MVC架构，各种单一职责的工具与软件。

那么，为什么他们要这么做呢？显然，一个工具只用来处理一个事情，是最不容易出现问题的，也是能够长期保证稳定的。如，快速排序算法中，一个步骤用来比较大小，一个步骤用来调度，一个步骤用来记录。如果写在一起，那么在比较大小的时候需要去关心是否要去调度，什么场景需要调度，大大增加了实现的难度，也就使得这个工具的出错率提高。

这也就是为什么大家都提倡『高内聚，低耦合』的原因。在MVC，MVVM，以及Hybrid架构中都有非常好的体现，而面向对象将这个理念推向了巅峰。

那么业务呢？

那么，对于业务，是否也应该讲究分而治之？将业务部门的职责规划清楚，部门内对于每个人的职责定位清楚，互相补全而不是互相重叠。

很想当面问问，为什么知道在软件设计上要分而治之，职责单一。为何在人事安排上就会出现如此混乱的场面？

在业务上，个人的体会就是一个字『拆』。起步阶段，拆除非核心业务。对于核心业务，也是一个字，『拆』。拆到不可拆为止。如此逐步迭代，步步为营。方为王道。

当然，这也就要求决策者具有长远的目光，以及拒绝不合适需求的勇气，甚至承担由此带来的各种非议。