Auction网上拍卖项目纪实--Day 4-5

Auction网上拍卖项目纪实—Day 3前情回顾:所有的后台开发工作在有序进行中,一些技术问题也分析出了方案,总之一切都在控制中。

连续两天高强度的模块功能开发,有块产品详细参数的存储显示功能目测最困难,因为各种产品的参数结构不同而且可能会有细小变动不适合设计数据库字段存储,如果花时间把结构持久化管理可能会花掉很多时间,再接上详细参数的存储显示复杂度会很大。

最终在所有人都举足无措的情况下,根据过往经验+灵光闪现果断决定把所有详细参数的数据+参数的结构作为Json格式存储在一起,因为产品类型有限每增加一种产品多做一种参数结构,这样也可以很灵活的根据存储的参数数据+参数结构形成显示。

这么敲定后接着两天就是设计数据模型,以及详细实现,在过程中有个比较麻烦细节,Java的request中的提交的数据作为Map全部获取时不是平整的 Map String->String结构,而是 Map String->String[]结构(因为checkbox等可能提交一组数据),为了满足无脑获取所有表单提交并处理需要将提交的Map String->String[]结构数据转换为想要的Map String->String结构再根据Input的类型做存储与显示实现。

最终把用最优的数据结构作为基础实现了复杂的显示逻辑,并做成了一个macro让后台编辑和显示页面的代码一阵清新简单,同时以后前台站点显示的时也能复用,就这么一番折腾,在加上几十个参数要对应创建参数结构初始化的代码,测试、修改、优化、提交时间就过了一天多。感觉好久没有这么痛快的实现一个复杂的功能,处理完回顾所有需求松了一口气,做些轻松的测试休息半天,晚饭后小睡补补精神。

晚上打雷闪电,核对进度,A君处理完了两个模块,B君和C君也一起处理了两个还差测试,把事情混在一起做进度很模糊,出了问题总是无法避免,总监也处理完了一个模块。再看看进度表,后台管理的基本功能模块只剩下4个左右。剩下的其他问题还没有在过程中暴露,也还有要接着处理的技术点(推送的架构与实现都需要时间)。还有一个问题,支付宝每天支出的默认额度5w,如果申请退定金的人多了使用支付宝每天只能退一个人,财务市场部门因为这个原因决定使用其他的支付平台,花了一天时间做好的支付宝的对接可能报废,其实一开始就知道额度的问题可是也没想到。准备迎接新的平台。

八点半,看看进度列表,决定明天处理添加产品为拍卖品的功能,因为星期五情节+下雨,撤退,明天周六正常工作时间加班。总监喝过红牛还在和A君奋斗。

今天,和C君一起提前走。



本作品采用知识共享署名 4.0 国际许可协议进行许可,欢迎转载内容并请注明出处
《Auction网上拍卖项目纪实--Day 4-5》 http://io97.com/2014/09/19/10009.html