ITOO项目共分为两个方向：JAVA、.NET。
而考试系统又是JAVA方向中，业务逻辑最为复杂的一个。
在被'考试系统'坑了'100天'以后，我仍然期盼能得到一个相对完美的结局。
项目开发周期：
11.10-01.27：参与ITOO1.0考试系统开发
01.28-02.16：担任ITOO2.0考试系统组长
第一次迭代
主要以：需求确定、原型设计、实体设计，为主。项目的开发只是涉及到单表的CRUD。
（一）需求和原型的设计
立足于去年.NET的考试系统。这样的做法有利有弊：
1、利
通过运行的系统，直观了解考试系统已有的需求，上手快
通过去年产品经理对考试系统的展望，立足于用户体验，为JAVA版考试系统提供了建设性的意见
2、弊
受到已有设计思路的禁锢。往期的开发人员更加肯定已有的需求、原型设计的认知。而新的开发人员主要通过点击已有项目来了解需求，接受往期开发人员的催眠。在探讨阶段尽可能的向产品经理展望的角度来设计，但是却受到往期开发人员"是否能实现？数据量？性能"的阻挠。
（二）实体设计
关于业务逻辑的实体也就20个左右，而各式各样题型的处理，却是占了70%的比重。
所以，引入了"大题型类"和"题型类"的概念（如图所示）。以实体结构相同的作为同一种"题型类"作为划分。且相同实体结构的题型的页面展示方式是相同的。
详细请参加'第二次迭代'之设计思路的改进。
第二次迭代
迎送了一个'盛试'时代，马上面临就是下一个'盛试'。
（一）高度、心态、百家争鸣
任谁都知道'考试系统'是最具有难度的！此难度并非在于技术的实现，而在于产品经理对考试系统的种种期待，更包含了面对如何多刁难的客户，产品经理以一敌百的血腥场面，所带来背后的支持。因为害怕达不到产品经理的高度，而望之却步的一种责任！更多的是怕您失望！
可能是因为我们的目光短浅尚且达不到您的高度！既然选择了这里，就要100%的相信！
跟随着一期，一路摸爬滚打，也渐渐对这种码农的开发模式渐渐产生了倦意，甚至是抵触。总是想着停下脚步，追一追进度，又或者学习底层的设计思路、公共模块的知识拓展。却不知道，正是在这种'思维的切换过程中'，消耗了大部分的时间和精力。
二期的开发人员大多都是从.NET考试挖墙脚过来的，所以对于业务的理解方面具有一定的优势。从某种角度而言，也带来另一种的设计理念。当两种设计思路出现出入的时候，出现'百家争鸣'的场面是必然的。正是这种'百家争鸣'的场面，也让考试系统取长补短，而争鸣的百家自是受益匪浅！所以，同样感谢你们。
（二）设计思路的改进
于2015年2月07日晚上7:40正式开始，10:00结束
本次争论，主要从集中两点：1）考试配置；2）题库设计
1、考试配置
核心：考试-->考场-->考生-->试卷/模板，一路绑定
JAVA先前的设计思路：前一个实体绑定后一个实体后，生成第三张表的自增ID，后绑定下一个实体，以此类推。见图1
从'实体设计'角度考虑，是缺乏灵活性的。打个比方来说，如果我现在要交换'考生'和'试卷'的绑定顺序[考试-->考场-->试卷/模板-->考生]，那么已有的实体设计思路是满足不了这种要求的。
所以，为了增加'实体设计'的灵活性，见图2。
（图1）
(图2)
（二）题库设计
1、JAVA版考试已有的设计思路：
所以，引入了"大题型类"和"题型类"的概念（如图所示）。以实体结构相同的作为同一种"题型类"作为划分。且相同实体结构的题型的页面展示方式是相同的。
特点：通过'大题型类'来管理'题型类'
利：若新增的"题型类"的表结构已经存在，则直接利用已有逻辑代码可以实现，不需要增删改查。
弊：若新增的"题型类"的表结构不存在，则需要新增加代码来处理。
2、.NET版考试系统的设计思路：将所有题型的所有属性，汇总到一个实体中。
特点：将题型中所有可能用到的属性，都汇总到一个实体中
利：通过页面控件的拖拖拽拽，可以动态的生成一种新题型
弊：数据库字段设计冗余；若'新题型'中的字段在这个大实体的属性之外，同样面临着改动代码的问题。这不过不仅仅是增加代码，而是需要CRUD.
相比较而言，两种设计思路上，同样体现了不足：
JAVA版在面临添加新题型时，需要增加代码
.NET面临同样问题时，却面临着改动实体、改动代码的严峻考验
如何使得在不改变原有代码基础上，动态加入新题型[已实现]，已经相应的业务逻辑以及显示方式[难点]，已经成为考试的一个瓶颈。
8267
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
