我正式参加的第一个项目是移动渠道运营,由于公司人手不够,老大将渠道资源的大模块交给我一个人来负责,由于之前的详细设计极为粗略,库表设计也没有,所以一切就得自己来搞定了。
开发过程中与客户进行过2次粗略的交互,可由于我是新手,对移动业务很是不熟悉,他们的需求我难以全部消化。两个月后一期开发完毕,昨天在现场与客户测试的时候,发现很多地方都没想到,虽然界面和已实现的功能他们颇为满意,可还是提出很多他们需要的功能以及需要修改的功能。客户的素质颇高,只是希望我尽快考虑他们的需求,添加一些他们迫切要求的功能。还好,老大没有批评我。
经历这次事情,感觉需求与详细设计是多么的重要。出现这样的问题,我分析了一下,有以下原因:
1. 前期与客户交流不够,只是粗略的沟通,很多细节问题都没有涉及到;
2. 自己对移动业务不熟悉,造成对客户的要求不能完全理解,出现偏差;
3. 设计的实现方式自己还是欠缺,比如如何设计一个高效的库表系统,库表之间如何关联等;
解决的方法依次如下:
1.. 前期沟通一定要充分,在开发过程中哪儿有问题,需及时和客户进行确认,万不可按照自己的主观臆断行事;
2..多阅读客户方提供的业务资料,通过阅读以及与客户的沟通,做到尽可能熟悉客户方的业务需要,这样对开发有很大帮助,提高软件的实用性;
3. 数据库设计方面,多与公司的前辈沟通,参考公司以前做的系统,并结合业务需要。全面的模拟整个使用环境,考虑到在使用中可能出现的各种问题;
4. 从用户的角度出发进行分析。比如设计一个票据领用登记归还的模块,那首先得领用登记吧,得做个领用登记的页面和功能,需要个领用主表和,明细表;领完了得查询吧,这段时间谁领了多少票吧?好,得提供查询功能;票领完了发现领多了或者没用完,得归还吧?ok,加个回收登记的功能。可要回收那肯定是有领用记录才行,所以还是先得查询。库表设计方面,可以设计成四张表,分别是领用主表、领用明细、归还主表、归还明细;可这样的话关联也太多了,归还主表得记录领用记录主键;归还明细得记录领用记录主键。不可取。何不就设计成两张表呢,一个是主表,一个是明细表,主表字段有领用id、领用人、领用部门、领用原因、归还原因等基本信息;明细表字段有 明细id、领用id(外键)、发票类型、领用数量、领用日期、归还数量、归还日期等。这样存领用的时候归还字段均为空;归还的时候直接先查出领用id,然后直接把归还信息存入不就行了吗?
注:我是个刚毕业半年的新手,啥也不懂,都是刚开始学,这是小弟积累的一点点经验。希望能给和我一样的新手有所帮助,我这里面肯定有不对的地方,还望高手看到后能给予指点啊,小弟不胜感激!