碎片化系统

进入新公司也差不多超过半年的时间了,在这段时间中参与了两个不同产品的开发,这两个产品的系统设计取向虽然截然不同,但是都呈现出类似的状况,就是系统的杂乱无章和碎片化。

中间层

如果把应用所处的平台和基于的应用程序框架(如Android Runtime)当作系统的底层,应用所包括的各项功能实现的集合当作系统的上层,通常我们还需要一个所谓的中间层,这个中间层可以起到的作用包括:

  • 为跨平台的应用构造一个隔离层,自身可以适配不同的平台;
  • 对平台本身的一些模块进行封装和增强,解决系统兼容性问题,增加应用所需的功能;
  • 从应用所包括的各项功能中抽取通用的逻辑,为功能的实现提供强有力的支撑;
  • 为各个功能模块提供各种管理,数据传输和通讯服务;

碎片化

一般而言,如果是不太复杂的应用,本身又基于一个比较成熟的平台和应用程序框架,对构造一个中间层的需求并不大,大部分情况下都可以忽略掉。但是很不幸,上述的这两个产品由于自身的复杂性,或者由于所处的平台,或者由于技术方案的选择,都要求必须要有一个强有力的中间层作为支撑,而缺少这样一个设计良好的中间层,导致了上层的各个功能模块都不得不为本来应该是功能无关的通用逻辑提供自身的实现,而这些实现通常缺乏严谨的设计,并且大多为了赶工仓促而就。

总之,这使得整个系统充斥着大量这样的小模块,它们相似但又不完全相同,设计蹩脚,实现粗糙,很多明显残留从别的地方把代码拷贝过来然后进行修改的痕迹。各个功能模块之间缺少一个统一的中间协调者,不得不自己直接跟其它模块交互,系统的相互依赖性和耦合度轻易就泛滥到无法收拾的地方。

这样一个系统就像是由一堆碎片拼凑堆砌而成,为了整个系统不至于散架,还需要淋上一打胶水把这些碎片紧紧地粘合在一起。随着功能的增加,系统的复杂度的增长,这个系统越来越变成像是一个吞噬工程师血汗的怪兽。每一次修改,常常都波及大半个系统,每一个功能的增加,都像是要在这一堆粘的密密实实的碎片中撕开一道裂缝,然后再把自己硬塞进去。每一个身处其中的工程师都苦不堪言,咒骂着参与制造这样的怪兽的人,然而他们自己也将在不久的将来成为后续维护这个系统的工程师咒骂的对象。

成因

考究这样系统的成因,可以大概归为:

  • 缺少一个有经验的系统设计师在开始作出一个完善的全局设计,并在后续的演化中维护这个设计的基本架构;
  • 产品的开发以功能实现为导向,工程师只追求尽快实现功能,而无法做更长远的思考;
  • 没有分配工程师专职于系统中间层的构建,所有工程师都忙于于功能的实现和bug的修正;
  • 一些较为有经验的工程师会试图抽取一些可复用的代码,但是因为这些代码还是直接跟具体的运行上下文绑定在一起,并且API也不完备,缺少良好的文档,最终还是仅仅停留在只能供自己使用的程度;
Advertisements