[JAVA考试系统]项目总结

太过爱你忘了你带给我的痛 2022-08-07 01:59 204阅读 0赞

****

**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。**

**![SouthEast][]**

**（图1）**

**![SouthEast 1][]**

**(图2)**

**（二）题库设计**

> **1、JAVA版考试已有的设计思路：**
> 
> **   所以，引入了"大题型类"和"题型类"的概念（如图所示）。以实体结构相同的作为同一种"题型类"作为划分。且相同实体结构的题型的页面展示方式是相同的。**

**![SouthEast 2][]**

> **特点：通过'大题型类'来管理'题型类'**
> 
> **利：若新增的"题型类"的表结构已经存在，则直接利用已有逻辑代码可以实现，不需要增删改查。**
> 
> **弊：若新增的"题型类"的表结构不存在，则需要新增加代码来处理。**
> 
>   
> 
> 
> **2、.NET版考试系统的设计思路：将所有题型的所有属性，汇总到一个实体中。**

**![SouthEast 3][]**

> **特点：将题型中所有可能用到的属性，都汇总到一个实体中**
> 
> **利：通过页面控件的拖拖拽拽，可以动态的生成一种新题型**
> 
> **弊：数据库字段设计冗余；若'新题型'中的字段在这个大实体的属性之外，同样面临着改动代码的问题。这不过不仅仅是增加代码，而是需要CRUD.**
> 
>   
>

> **相比较而言，两种设计思路上，同样体现了不足：**
> 
> **    JAVA版在面临添加新题型时，需要增加代码**
> 
> **    .NET面临同样问题时，却面临着改动实体、改动代码的严峻考验**
> 
> **    如何使得在不改变原有代码基础上，动态加入新题型\[已实现\]，已经相应的业务逻辑以及显示方式\[难点\]，已经成为考试的一个瓶颈。**  
>

**终于走到了，文章的末尾。**

**我想告诉你：**

**    谢谢考试系统的小伙伴们的陪伴。因为思维的碰撞远比闭门造车要有益。**

**    项目功能的结束固然重要，但是'团队'更加重要！**

**    考试系统，你一定要好好的。**

[SouthEast]: /images/20220805/8b746578aa9c4ea492c057fc3d5f7c50.png
[SouthEast 1]: /images/20220805/b569b2acb2ed483abf8e7620c19783e3.png
[SouthEast 2]: /images/20220805/497dc0e6192a4b7d8eeb0521399814f4.png
[SouthEast 3]: /images/20220805/716210c359744d2fb9904b0d85c69030.png