2006年初，我正式开始从事研发工作。那么第一件事情就是为我研发的产品规划一个美好的蓝图，制定一个Feature List。经过多方的学习和讨论，以及在领导在远景战略上的指示。我粗粗的规划了，大概具备以下的特征：
1、展示层数据扁平化，逻辑层数据结构化。
首先，我们考虑到了展示层的数据应该是扁平化的，没有对象的概念（如果把一张页面看成一个对象那就另当别论了）。我估计很多人看到这条理论就会在心里暗骂我是个白痴。呵呵，从现在主流的OO思想来说，这确实是不可思议，我也很理解。但是当时我们这样来设计是有我们自己的理由的。
理由一：我们公司主要开发信息管理类的软件，比如ERP等。从技术角度来说，就是让用户在WEB页面上录入一些信息，然后系统经过一定逻辑运算后，保存到数据库里，其后在将数据库的数据原封不动的展示给用户，或者经过ETL之后通过报表引擎或BI工具进行展示。在这样的前提下，从用户的角度来说，他们并不知道什么对象的存在，是我们这些软件设计人员通过对业务的理解提炼出来的。这个提炼过程没问题，也是必不可少的。那么在我们比较正确的提取对象之间，我们的工作都在没有对象的情况下进行。这个应该没有人反对了吧。简单明了点的说，我们在使用原型法第一次构建系统时，我们还没有对象。因为原型构建是在需求调研阶段，是与用户沟通的业务时做的辅助工具；在这个阶段下我们没有比较正确的对象或者根本没有对象。那么我们在做原型时，展示层的数据是不是扁平的？看到这里，大家估计有点明白为什么我的第一个平台特性“要求展示成数据扁平化”了吧！是的，在需求调研过程中的原型，要最大可能的保留到将来交付的产品中，减少软件的开发成本。很欣喜的告诉大家，我们公司现在能将最初的原型中70%的代码、特性等保留到最终交付的软件产品中。当然，为了满足这个原型保留的目标，光这么一个特性是不够的。还需要其他的工作。
理由二：用户眼中只有数据，没有对象。用户不关系软件系统后台的业务逻辑是怎样执行的，他们只关心在页面上有没有他们需要的数据。、
理由三：将当业务对象变更时，所产生的影响降到最低。因为，我们对业务的理解是逐步求精的。最了解需求的时候，是软件系统交付的时候。所以，这就导致我们前期提取的对象有可能是错误。在整个项目周期中，我们时常要调整对象。而对象调整后对软件系统的冲击是巨大的。所以，我们将展示层的数据扁平化，不至于受对象变更而导致重构。同时，从以前的项目经验告诉我，逻辑层的复用度比较高，而展示层的复用度比较低。换句话说，展示层的开发量比较大。所以要保证展示层一定的稳定性，将对象变更产生的风波隔离在逻辑层，这样变更时工作量就少很多了。
晕！午休时间没。先这样吧，待续……!
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
