[某书]FineReport项目中遇到的坑总结

熬掉了无数的头发,键盘手上的油染的锃亮,终于阶段性的结束了让人难受的某书项目。

1.项目的交接

项目的交接至关重要,但是在某书这个项目中无论是我方成员和甲方成员都没有进行正规的交接。

内部交接

首先,在进行我方内部交接的时候,交接的那位女士告诉我她的电脑重装了,在我强烈要求下,才提供了一个甲方项目组转发给她的邮件。
其次,由于自身刚刚加入帆软团队,没有什么项目经验,天真的以为项目上遇到的难题应该没有帆软认证上的题目难,无非就是一些数据填充。因此后面也没有再向其索要项目资料了。
后果,后果就是导致项目中遇到了很多让人头大的事情,比如说一些常规项目上不用的动态列,动态字段绑定图表分类等等,就变成了项目现场的问题,极大的影响了项目的进度

外部交接

当来到某书进行项目交接的时候,某书这边的技术丢了一个很长的没有注释sql文件,还丢了环境配置库,顺便说了一句,我放了几个我们其他的项目在开发环境,你自己看一下。
然后就是某书的产品经理,没有一点的项目管理意识,问了她好几次排期都是一问三不答,这样就导致很难安排后面的工作,感觉就像请女朋友吃饭一样。

开发环境的问题

开发环境存在一个隐藏的大问题
那就是查询效率是真的很低,筛选条件绑定的数据源,直接通过数据源访问都要30多秒,加了limit 100 的报表主体加载更是要1分钟才能完成。
为啥说这是一个大问题呢? 你想一想一个页面10个筛选条件。进行整体测试的时候,测试一遍要多少时间 。
首先打开页面加载初始化报表1分钟
测试筛选条件1 等待读取到数据 30秒
等待报表刷新 完成1分钟
查看报表是否有问题 30秒
就这样子,我们进行10个筛选条件的单选测试就用了20分钟
然后再进行关联测试又是20多分钟
遇到问题后除了单元测试还有回归测试,这样想象一下,几乎所有的时间都是在测试上了。
如果是一个特别熟悉某书业务的报表开发人员,那么很好,一次通过,但是不熟悉的人做它的功能测试,我想你在报表开发后期,从早到晚最多也就30多次测试过程。

产品经理的不专业

遇到的产品经理也是很神奇,刚开始的时候设计了一个负责的业务,耗费大量时间好不容易弄出来后,又说让改为最常规的。
在报表马上要独立验收的前一天,又增加了需求,好不容易加上去后,发现之前的筛选功能都不能用了,然后又要耗费大量时间回退版本

总结

1.项目交接的时候一定要发邮件,抄送领导,明确的告诉对方你要的东西,项目过程文档,干系人清单,项目问题清单
2.如果遇到单元测试的时候时间超过3秒就要马上向甲方提出风险,一个业务模块开发出来最少要经过上百次的测试验证,一个单元测试3秒意味着页面10个单元的话, 测试就要花费30000秒 也就是开发周期中要花费8个小时在测试上。
3.数据字典,操作手册,以及代码注释一定要要,否则你直观的去看根本看不出来对面给你的东西是要做什么
4.明确告知用户验收前1日不接新需求,新需求意味着你的项目存在重做的风险,如果你的项目重做时间大于2天,那么就是验收前2天,如果是10天,那就验收前7天。不要想着做版本控制了,因为版本回退也需要时间。
5.对于没有成功案例的需求,能推掉就推掉,推不掉就放到第二期,因为未知的本身就是最大的风险。

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值