关于编码设计

编码设计在大型项目里常常被搞得异常复杂，大多数是人为因素增加了复杂度。小型项目则往往走向另一个极端，忽视编码设计，在后续维护时发现数据随着时间的推移越来越凌乱，无意中增加了维护成本同时界面友好度大幅下降。

 

大多数情况，往往是因为没有专门负责呈现和分类的字段，所以才费尽心机设计编码，以便让其担负更多的任务！

 

1、编码分类

a、客户是否可能接触到此编码，以及以什么样的形式接触，比如，是否需要记忆？
b、此编码是否有再次分类的可能 ？
c、此编码是否有辅助字段，比如排序字段 ？
d、此编码数量的预估变化幅度，未来会以什么数量级的方式增长？

2、重要性

a、客户操作方便最重要
b、系统健壮稳定
c、效率
d、程序员习惯最不重要 

 

3、具体措施

a、所有客户没必要见到的编码一律隐藏，客户是比较讨厌编码的，程序员喜欢见到各种各样的编码，至少调试方便。
b、界面呈现的规范，比数据库内部的规范更重要，可以为呈现的规范增加复杂度，而不应该为数据库的排列规范增加复杂度。北京之所以排在上海前面是因为排序字段确定的，而不是ID在上海的前面，如果是后者试问是否所有类似的字段都要一次性加齐？就算一次性加齐，如果有一天上海成了首都是不是程序要重写？
c、维护统一的规则比某些地方的简便更重要。请检查某些字段外键不能建立是否是因为一些特例？维护统一处理掉特例是我们应该做的，而不应该着眼于特例带来的便利。
d、消除程序员心理影响。一个自增字段，免不了隔数跳数(插入数据失败，或被删除)，期望一直保持连续反而是隐患，要花更多精力在保持一致性或者交互复杂度方面，程序员们一致认为跳几个数除了造成一定心理影响，没有别的坏处。

 

4、技巧

a、考虑到所有可能性，达到整齐。比如订单的运输方式应该设置{-1:'未确定',0:'无',1:'航空',2:'汽运',}，这样避免Null的使用，而且不影响列表的使用，加上条件即可。Null在很多时候都要特殊处理，因此商业规则无法普适，需要不断修正。