业务架构初探之二:选择项目的效率
选择项目的简单说明
选择项目,是我在开发的时候一个简单的总结,其实,就是指某些文档框(字段)的内容是固定的选择项目的,最常见的是:“性别”,通常只有2项(喜欢加入“未知”的童孩,不要坏笑哦);或者“省份”,那就是我们固定的行政省的名称列表了;或者,财务方面的,“收入、支出”,等等。
常见的解决方案
因为是常见的,所以,很多前辈,朋友也都接触过,也都解决过,解决的方案是多种多样的,例如:
- 在前端/窗体代码里直接写;
- 设定特定的类,作为业务的基础类,给各个窗体重复调用,实现,代码重用,
- 配置数据字典,在代码里,实现集中管理;
- 提供配置文件,开放一个集中管理的渠道;
- 其它;
概况、评估的视角与维度
我有多年系统开发的经验,也看过不少其它人做的项目,在这一个"选择项目“的需求的解决方面,真是八仙过海,各显神通,什么样的解决方案都有人做过,也上线过。
如果,以单一的问题来讨论,这个真不是什么”大问题“ 、“关键问题”,为什么呢?因为,各种方案都可以落实行的,大家都过了海,大家都是神仙。
但是,能用,就是“好用”,“好管”吗?那么,就涉及一个评估的视角与维度的问题。
很多人认为,这个“小问题”,能用就行了,还需要评估吗?
但是,我认为,不同的视角,或者说,不同的立场,看同样的问题,答案是不一样的。
我提出以下的视角与评估维度:
(1)开发效率的维度,开发量大的时候,怎么“小问题”重复出现一百次,一千次,那就不是小问题了,因为,优势与劣势都会被重复放大的;
(2)重用性的维度,既然,是基础的,通用的,需求,那么,如果可以重用,那么,代价就是最小的。
(3)代码/数据可维护的维度,这些选择项目,有一部分,是稳定不变的,有一部分是会变的,所以,如果变代的代价太大了,也会将小问题放大成为大问题。
没有结束(解决方案)的结束语
怎么,才能将这个功能,做得好用,好管?
什么才是在不同维度的评估下,都是好的方呢?估计,目前还没有一个公认的答案。
以我本人所积累的经验,暂时,没有较大的,较明显的突破,只是先将问题提出来,期待大家的讨论,参与,进展。