背景
题目起的有点大,其实只是想随便说说。最近工作中遇到一些事儿,发现很多人其实迷失在其中,违背了一个亘古不变的真理:越简单越不容易出错。我来详细说说我对于这个真理运用在程序编写,产品制作上的一些理解吧。
分层架构意义何在?
很早很早以前,大概是我还在玩泥巴的时候,IT圈子中的大牛们就已经意识到彼时的程序就如果面条般混乱不堪。于是乎,由一个大牛牵头,各方诸侯呼应,探索并制定了一系列软件开发的方法论,我们称之为『软件工程』。
从那个时候开始,就讲究分而治之。从很多的案例以及算法中都能看到这个思想的影子。如:快速排序,MVC架构,各种单一职责的工具与软件。
那么,为什么他们要这么做呢?显然,一个工具只用来处理一个事情,是最不容易出现问题的,也是能够长期保证稳定的。如,快速排序算法中,一个步骤用来比较大小,一个步骤用来调度,一个步骤用来记录。如果写在一起,那么在比较大小的时候需要去关心是否要去调度,什么场景需要调度,大大增加了实现的难度,也就使得这个工具的出错率提高。
这也就是为什么大家都提倡『高内聚,低耦合』的原因。在MVC,MVVM,以及Hybrid架构中都有非常好的体现,而面向对象将这个理念推向了巅峰。
那么业务呢?
那么,对于业务,是否也应该讲究分而治之?将业务部门的职责规划清楚,部门内对于每个人的职责定位清楚,互相补全而不是互相重叠。
很想当面问问,为什么知道在软件设计上要分而治之,职责单一。为何在人事安排上就会出现如此混乱的场面?
在业务上,个人的体会就是一个字『拆』。起步阶段,拆除非核心业务。对于核心业务,也是一个字,『拆』。拆到不可拆为止。如此逐步迭代,步步为营。方为王道。
当然,这也就要求决策者具有长远的目光,以及拒绝不合适需求的勇气,甚至承担由此带来的各种非议。