业务架构初探之二：选择项目的效率

选择项目的简单说明

选择项目，是我在开发的时候一个简单的总结，其实，就是指某些文档框（字段）的内容是固定的选择项目的，最常见的是：“性别”，通常只有2项（喜欢加入“未知”的童孩，不要坏笑哦）；或者“省份”，那就是我们固定的行政省的名称列表了；或者，财务方面的，“收入、支出”，等等。

常见的解决方案

因为是常见的，所以，很多前辈，朋友也都接触过，也都解决过，解决的方案是多种多样的，例如：

1. 在前端/窗体代码里直接写；
2. 设定特定的类，作为业务的基础类，给各个窗体重复调用，实现，代码重用，
3. 配置数据字典，在代码里，实现集中管理；
4. 提供配置文件，开放一个集中管理的渠道；
5. 其它；

概况、评估的视角与维度

我有多年系统开发的经验，也看过不少其它人做的项目，在这一个"选择项目“的需求的解决方面，真是八仙过海，各显神通，什么样的解决方案都有人做过，也上线过。
如果，以单一的问题来讨论，这个真不是什么”大问题“ 、“关键问题”，为什么呢？因为，各种方案都可以落实行的，大家都过了海，大家都是神仙。
但是，能用，就是“好用”，“好管”吗？那么，就涉及一个评估的视角与维度的问题。
很多人认为，这个“小问题”，能用就行了，还需要评估吗？
但是，我认为，不同的视角，或者说，不同的立场，看同样的问题，答案是不一样的。
我提出以下的视角与评估维度：
（1）开发效率的维度，开发量大的时候，怎么“小问题”重复出现一百次，一千次，那就不是小问题了，因为，优势与劣势都会被重复放大的；
（2）重用性的维度，既然，是基础的，通用的，需求，那么，如果可以重用，那么，代价就是最小的。
（3）代码/数据可维护的维度，这些选择项目，有一部分，是稳定不变的，有一部分是会变的，所以，如果变代的代价太大了，也会将小问题放大成为大问题。

没有结束（解决方案）的结束语

怎么，才能将这个功能，做得好用，好管？
什么才是在不同维度的评估下，都是好的方呢？估计，目前还没有一个公认的答案。
以我本人所积累的经验，暂时，没有较大的，较明显的突破，只是先将问题提出来，期待大家的讨论，参与，进展。