代码的一些思考

程序=处理过程（函数）+数据模型（数据）
我们在编程，其实本质是在处理数据某型。因为这些模型的存在，导致我们需要以一定的方法来处理。如你要把水果加工成果汁，你需要搅拌机。只是我们处理的不是把水果加工成果汁这么简单的事情，我们需要处理构建在虚拟之上的内容。web应用看上去可以分层为M-V-C，用户提交一个数据某型，服务器端把这个数据某型转成VO，我们从VO->DO->数据库的数据，这个过程都是对数据的一部分转换，在各个不同的阶段需要处理不同的数据模型。
处理过程：
其实这里说的处理过程我觉得更像是依附于数据的，所以我重点谈一下模型，因为模型才导致数据变化

模型复杂原因：
实例为主，在整个exodus2中，其实exodus2本身并不复杂，我们看到大部分代码都是比较简单的，但是为什么代码写出来就是会出现故障，出现一些考虑不到的问题，其实主要是在于我们的数据模型过于复杂，导致我们处理了大量原本不必要处理的逻辑。
a）模型过度关联
举例：我们要把一条offer存在数据库，我们需要先获取一个offer的页面对象，但是实际上代码是怎样的，代码中对offer页面对象和context对象，group对象，MutableOfferBaseModel对象进行混杂，导致一个原本很简单的模型变得异常复杂，我们需要出不同的地方把这些数据取出。这样显得凌乱而且又难控制，这是取数据导致的人为复杂化了。
b）模型过分复杂
举例：offer有几个字段是大家进入offer组必须了解的，想必都知道member_define_properties、PICSAMPLE_ARRAY.这两个字段承担了offer很大一部分故障。由于早期原因，这些字段设计成比较难处理是数据格式xml，而且这两个字段过于臃肿，存储了过度数据。我们常说上帝方法，其实这个就是offer的上帝数据了。
c）模型有增无减
举例：我第一次来时，听大少讲offer有100多个字段，其中有用的就30多个字段。这说明什么，offer中存在大量无用的字段，这些字段从产生开始就应该关注他的消亡，我们在处理应用时一般是增加、增加，增加效率高，短期内不会出现太多问题，但是这样长期发展下去就是offer状态，老系统难维护很多一部分原因来源于此。
d）模型过度冗余
举例：offer大家最清楚了。price、price _terms、unit、packaging、quantity、member_define_properties。这些数据大部分都能由一个字段解决，但是由于历史存在，导致代码中不得不处理这些数据。在比如表之间，offer、member、company，这个冗余使得代码中处理offer中member 信息，company信息变得没意义，而且消耗性能。
e）模型自身约定不一致
举例：offer有个price字段，这个主要是用来记录价格，但是他是以分为单位，我估计很大一部分人不知道，因为大部分地方都是以元为单位。物体有惯性，思维也不例外，在未仔细思考下，就会用相似的想法，结果故障就来了：）
f）文档
模型是建立在一定的约定基础之上的，我们不能说口头传承，我们需要一个文档，而且是持续更新的文档记录模型，模型之间的约束，模型自身的关系。