奥运会后台项目开发总结

1:没有解决重名的问题,但很多地方都是根据人名来关联的.

2:没有打测试和生产不同的PATCH,以至于修改的时候两边都会更新.

3:每个图片都加上title,可以让搜索引擎搜索到该图片

4:因为项目开发没有计划,即没有开发清单列表.一般都是策划人员与开发人员直接提问题单.

这样一来,程序员就会经常被打断,被打断后再重新回到原来的思路上去就没有这么简单了.

故我认为系统经常性的出现小BUG都与这个有关,因为程序员有点被搞得焦头烂额的样子

5:出错信息没有办法输出出错的行号,不知道在那个地方配置错了???搞了一晚上也没有找到解决办法

6:增加产品发布审核功能,以防止意外情况发生,也可以做成部分需要审核另一部不需要审核,最好就是配置型开发

7:对于页面合成,是否可以完使用使用JS来注入数据,这样一来页面结构看起来不会乱,也容易复用一起处理逻辑,同时

使用VELOCITY的工具方法来加强页面合成的力度,这样只需要像STRUTS一样搭建一个处理数据的流程的框架,后面的所有东西都可以处理了

8:下拉提示有点错位?

9:使用自动保存编辑录入的数据,以防止丢数据的情况发生.

10:同步的问题,如果两个人同时修改一个产品的话,会有冲突发生,这里应该引入锁的机制,使用同步的方式来生成数据,或者是自动提醒协作功能

11:很多地方没有考虑到取到的值为null的情况,造成系统异常.

同时要注意写工具类的时候少返回NULL值.

12:编辑器增加热键的功能,可以加快编辑的工作速度.不知道能否提供类似WORD的双击选中功能,就像它的格式刷一样.

13:版块标题最好弄成编辑可定制的,这样方便编辑修改版块的描述信息,但是有多少版块应该是前已经确定的,是否可以提供更灵活的版块控制,可以让编辑自由的添加.或者在每个版块提供选择按钮是否发布?

14:尽量通过JS来控页面数据块的显示逻辑,如此一来就可以把数据是否显示以及一些页面元素显示的修改都可以开放给编辑,尽可减少开发人员的修改时间.同时可以把页面显示的HTML代码与后台数据注入的JS分别存入不同的文件,以防止编辑修改带有页面显示逻辑的JS

15:如何做到不改变页面布局信息的前提下给页面注入数据,这样的好处是可以让美工不停的修改页面,而不需要程序员再重修改格式化页面?JS的熟练使用比较重要.]

16:修改后台架构,把数据的提交与用户的认证分开.也就是说重启服务器后不需要用户重新登录或者重新登录不会使用数据丢失.

17:所有功能分开,在列表页面显示生成页面的控钮,生成带缓存页面和不带缓存页面的选项卡

 

18:使用AJAX判断提交是否成功?同时检测超时,也就是如果服务器正在重启,可以先不提交等服务器正常后再提交?使用AJAX轮询来判断服务器是否已经正常了.

 

19:对于首页的滚动图片最开始是程序自动更新的,后来编辑觉得这样太慢了,要改成手动修改的方式来更新.

     但是手动修改的方式编辑由于对HTML代码不是很熟,或者经常会不小心犯一些小错引起页面问题.

     我想能不能使用一个HTML读取器的方式把代码内容读出来,然后使用一个后台页面来让编辑添加数据,而页面的生成还是靠程序来生成.

     这样就可以保证页面不错了.好有一个组件可以这样用,htmlparse.

20:运动员头部摘要信息的长度,编辑一直在修改它的长度,对于这种类型的东西可以做一个统一的修改参数的页面,让编辑自己去慢慢玩.而且还有警告信息.

21:客户IE的时间不可信,不能根据客户端的时候来生成数据,要不然一旦客户端时间不对,效果就显示不出来.

22:flash奖牌榜,根据人名去匹配productid.但是运动员存在重名的情况,同时还有另外一个问题,输入了错误数据但是没有清空数据,造成垃圾数据有FLASH奖牌但是精心制作的数据没有FLASH奖牌榜

23:能不能先从后台取到一个ID号,再来更新数据,这样就没有必要知道是插入数据还是更新数据的判断了.

24:对于异常信息的输出一定要加上时间,要不然都不知道什么时候出的异常.(经常出现连接吧的503错误)

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
目 录 1 1 奥运会赛事管理管理系统需求分析 1 1.1开发背景 1 1.2 系统主要业务分析 2 1.2.1 运动员信息管理业务分析 2 1.2.2 运动队信息管理业务分析 2 1.2.3比赛项目管理业务分析 3 1.2.4 计分项目管理业务分析 3 1.2.5 裁判员管理业务分析 4 1.2.6项目类型管理业务分析 4 1.2.7国家管理业务分析 5 1.2.8赛事地点管理业务分析 5 1.2.9赛事信息管理业务分析 5 1.2.10赛事纪录管理业务分析 6 1.2.11运动员参加项目管理业务分析 6 1.2.12赛事项目对应管理业务分析 7 1.2.13赛事裁判对应管理业务分析 7 1.3 系统功能需求分析 8 1.3.1运动员信息管理需求分析 8 1.3.2运动队信息管理需求分析 9 1.3.3比赛项目信息管理需求分析 10 1.3.4计分项目信息管理需求分析 11 1.3.5裁判员信息管理需求分析 12 1.3.6项目类型管理功能分析 12 1.3.7国家管理功能分析 13 1.3.8赛事地点管理功能分析 13 1.3.9赛事记录管理功能分析 14 1.3.10赛事信息管理功能分析 14 1.3.11运动员参加项目管理需求分析 15 1.3.12赛事项目对应管理需求分析 16 1.3.13赛事裁判对应管理需求分析 17 1.3.14查询、审核需求分析 18 1.3.15评分需求分析 18 1.4 系统数据模型 19 1.5 数据字典 24 2 奥运会赛事管理系统逻辑结构设计 33 2.1 系统模块划分 33 2.2 数据库逻辑结构设计 34 3 奥运会赛事管理系统功能设计 36 3.1.1 裁判信息增加操作 36 3.1.2裁判信息删除操作 36 3.1.3裁判信息修改操作 36 3.1.4裁判信息查询操作 37 3.1.5赛事信息增加操作 37 3.1.6赛事信息删除操作 37 3.1.7赛事信息修改操作 37 3.1.8赛事记录增加操作 37 3.1.9赛事记录删除操作 38 3.1.10赛事记录修改操作 38 3.1.11赛事地点增加操作 38 3.1.12赛事地点删除操作 38 3.1.13赛事地点修改操作 38 3.1.14赛事裁判对应表增加操作 39 3.1.15赛事裁判对应表删除操作 39 3.1.16赛事信息查询操作 39 3.1.17赛事记录查询操作 39 3.1.18赛事地点查询操作 39 3.1.19赛事裁判对应表查询操作 40 3.1.20保证同一时间只能举行一个项目的触发器 40 3.1.21 比赛项目增加操作(项目编号、项目类型编号、项目名称) 40 3.1.22 比赛项目删除操作(项目编号、项目类型编号、项目名称) 40 3.1.23比赛项目修改操作(项目编号、项目类型编号、项目名称) 41 3.1.24比赛项目查询操作(项目编号、项目类型编号、项目名称) 41 3.1.38运动员增加操作 43 3.1.39运动员删除操作 44 3.1.40运动员修改操作 44 3.1.41运动员查询操作 44 3.1.42国家增加操作 45 3.1.43国家删除操作 45 3.1.44国家修改操作 45 3.1.45国家查询操作 45 3.1.46计分项目增加操作 45 3.1.47计分项目删除操作 46 3.1.48计分项目修改操作 46 3.1.49计分项目查询操作 46 3.1.50运动员参加项目增加操作 46 3.1.51运动员参加项目删除操作 47 3.1.52运动员参加项目查询操作 47 3.1.53place的删除触发器 47 4 课程设计总结 47 4.1 总结 47 4.2 展望 48
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值