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面临同样问题时,却面临着改动实体、改动代码的严峻考验
如何使得在不改变原有代码基础上,动态加入新题型[已实现],已经相应的业务逻辑以及显示方式[难点],已经成为考试的一个瓶颈。
终于走到了,文章的末尾。
我想告诉你:
谢谢考试系统的小伙伴们的陪伴。因为思维的碰撞远比闭门造车要有益。
项目功能的结束固然重要,但是‘团队‘更加重要!
考试系统,你一定要好好的。