发表于: 2017-11-24 21:51:49
1 704
一.今天完成的主要事情
1.完成进真实项目评审
这是最终的ppt中的内容,昨天贴出来的还没有总结整理到位
1.复盘项目期间的学习总结
聚金融复盘项目
聚金融项目主要是一个由线下转到线上的P2P金融理财项目.主要为用户提供实名认证,绑定银行卡,投资产品,查看投资相关信息等功能
主要和小组成员一起负责方案设计,数据库表结构的设计,撰写接口文档,以及独立完成后端前台和跑批任务的功能实现部分
项目中遇到的难点
一是需求理解
主要体现在金融项目的专业性程度高,理解需求有一定的困难,最后通过老大讲课以及查阅相关资料彻底理解需求
二是设计方案,接口文档,以及数据库表结构设计的具体实现
一开始对方案设计中要包括的内容,粒度如何,数据库表结构设计包含哪些内容,有哪些原则和注意的点等没有清晰的概念,尤其是对重要的sql语句怎么写没有清晰的认识,结果浪费很多时间.最后通过一是观看老大和培宇讲课视频,二是通过方案评审的反馈以及事后的反思,解决了这一难点.
三是部分功能的实现逻辑比较复杂
主要体现在产品续投功能,投资后的回款计划,用户投资的产品到期后如何自动付息和付本金等.这一部分一是通过提前写demo测试思路和算法,比如生成产品的回款计划.二是通过询问老大解决.
总结
现在回顾整个复盘项目,离真正的严谨的,能够上线的金融项目还有一定差距,比如像支付,抹零账户,人,证,卡,手机号校验,容错备份等难点功能没有实现,代码质量也有待继续提高,但是自己也学到了很多做项目时必须要会的知识.比如方案设计,接口文档,数据库表结构的要点,接口中需要注意的规范,日志怎么打,第三方服务怎么调,如何封装等
2.学到的技能
一是方案设计的要点
方案设计按照需求story的粒度进行,先说清楚项目整体架构,再通过文字描述清楚这个story如何实现即.如果是比较简单的实现,就可以简单的一句话带过,如果是比较复杂的功能实现,要描述清楚实现方法,如果有多个方案,列出所有方案,并且描述清楚各个方案之间的优劣.
二是数据库表结构的设计要点
首先,从需求中将数据抽象出来,找到数据和数据之间的关系
其次,是表结构的设计,数据和数据之间的关系一般分为三种,一对一,一对多,多对多,不同数据关系,表结构的设计上也有区别
再次,尽量将同一类型的数据放在同一个表中,增加表的复用性
最后,一些需要注意的细节,比如类型,长度,是否为空的选择,注释中说明字段作用,提供两个假数据测试时使用.
此外,由于使用公司自己的框架,所以要在数据表中将一些常用的重要的sql语句提前写好,要注意写在表中的sql语句一定是可以走缓存的,所以一般只写通过条件查ID的sql,同时必须要写全面,因为代码生成之后再增加或者修改sql,不仅步骤繁琐,而且还非常容易出错,往往会浪费很多时间
三是接口文档注意的事项
接口文档一般按照模块划分,比如前台,后台,支付等,接口采用restful风格命名,包含的要素有字段约定,接口的路径url,具体的http请求方法,入参,出参,备注等.要注意接口中的字段尽量和数据库中保持一致,这样可以避免二次映射,最主要的是,接口文档一定要保持更新,时刻和实际接口保持一致,更改接口文档时要通知到前端人员.
四是基本的项目环境搭建和公司DAL框架的使用,调试以及代码生成
首先搭建环境时要按照规范,代码放在sources目录下,web放在webs目录下,service放在services目录下,并且要分别配置好各个模块部署和启动的脚本以及web容器的配置,最后要配置好nginx服务器.使用公司的DAL框架首先就是要按照规范写好excel数据表,然后按照service依托excel数据表生成代码,代码生成之后,将代码复制到相应的项目结构下,修改几个配置文件,然后跑service的测试,如果service测试能够跑通,说明代码生成成功,如果出错,一般不是excle表格中的书写没有遵照规范,就是配置文件中有错误
五是接口中代码规范
首先要打印入参,然后对入参进行校验,校验通过后再开始业务逻辑的编写.对于接口中的日志,要在关键的操作后记录好日志,比如调用service之后,但是也不能过多的记录日志,否则会非常影响性能,比如一个从service中获取一个List之后,一般不打印list中的所有元素,而是只打印该List的长度.除此之外,日志内容中要能简单描述清楚业务是什么.一个好的方法是一个接口写完之后,跑一遍,然后自己看日志记录,看自己能不能通过日志清楚程序运行到哪一步.
3.对项目开发流程的理解
需求讲解
作为开发人员重点一是要知道为什么这么做,二是要确定自己已经理解清楚需求,三是能够第一时间判断需求能不能实现,大概知道难点在哪,听完需求讲解就能大概知道方案如何设计
方案设计,定义接口文档
要包括DB设计,关键sql语句,用户量预估,部署机器,历史数据迁移,架构图,逻辑图,核心算法等.实现方案按照story设计,一般说清楚功能实现即可;定义接口时由前后端一起,逐个过页面,定下来共有多少个接口,接口的入参和出参,字段约定等要素;接口定好之后一般由后端编写接口文档,接口文档是非常重要的文档,一定要按照规范编写,涉及到的要素要全面
方案评审
方案设计好之后要对方案进行评审,找出方案设计中存在的问题,敲定之前拿捏不定的方案
拆解task
将每个story分解为一个个明确具体的步骤,预估出每个步骤所需的时间.要点一是task的时间粒度要再0.5到4小时之间,二是task要细致到如何一步步的实现stroy.开发人员要在每天的下班之前更新禅道的task,方便项目leader通过燃尽图掌握项目进度,控制项目风险
晨会晨报
晨会从需求讲解之后贯穿止整个开发阶段,但在方案评审之后显得尤为重要.晨会一般采取站会形式,不超过15分钟,会议讨论的主要内容是昨天完成什么,今天计划完成什么,遇到的问题是什么,讨论时的粒度可以是具体到task,但是最终结论的粒度应该是story
要注意的是每天完成的事情要以能够演示出来的成果为主,看不到成果的就不能算作完成.
codereview,性能测试
codereview是请水平比自己高或者水平相当的其他工程师进行.一是看代码是否规范,二是看代码中有没有风险,三是看是否按照设计方案实现功能.codereview如果不通过,demo风险要由自己承担,原则上是当场改正,直到过了为止
性能测试是工程师对自己实现的接口进行性能测试.要求将简单接口的访问时间控制在50ms以下,复杂接口的访问时间控制在200ms以下
项目demo阶段
研发团队完成了所有需求并把产品交付给产品团队
过程是研发团队人员对照需求stroy和验收标准,讲述做了哪些东西,并将所有流程都跑一遍,在这个过程中如果出现任何一个肉眼可见的bug,即为不通过
打包部署
对代码进行存档
开发人员打tag,记录版本,然后申请发布测试环境,发布前要发申请邮件,登记wiki的相关页面.发布测试环境之后开发阶段基本就结束了,如果发现bug,修复bug则进入bug修复流程
bug修复流程
首先是测试人员提交bug,开发人员在两个小时内禅道确定bug.如果是自己的bug,自己根据bug的级别安排时间修复,如果不是自己的bug,找各组leader,另行指派
bug修复之后,开发人员要找测试远远演示修复的结果,测试人员确认没有问题后,开发人员点击已解决,然后申请发布测试环境,登记wiki,发测试邮件,测试人员继续测试.
需要注意的是bug有优先级,优先级不同,处理方式也有区别,minor,normal级别的bug是可以放在下一个迭代版本中进行修复,major级别的bug需要你停下当前开发的项目,优先进行修复,block,critical级别的bug需要你停下手头工作在线上立刻修复
4.对职业素养的理解
主要从两个维度,一个是对待工作的态度,另一个是具体工作时的落实
对待工作的态度有三个关键词,责任,结果,流程
其中责任是指对待工作的责任心,即当项目出现问题时,为这个项目着急,想办法解决问题的人一定是你;结果是指公司只为结果付薪,所以做事要先明白为什么做这件事,规划好自己的时间和资源,以目标为导向,这样努力才有价值;流程是我们通向最终目标的有力保障,它是公司经过长期实践总结出来的提高工作效率的方式,所以我们必须要遵守流程.
具体工作时的落实也有三个关键词,沟通,条理,细节.
工作时不可能是一个人单打独斗,任何一个团队都需要沟通,沟通就是跟别人交流自己的工作进程,需要注意有效性,及时性,主动性.沟通时要明确对方是否真正的了解你的意图,因为人和人之间会存在隐藏偏差,双方对同一个事情的理解可能会大不相同;条理是指把要做的事情分清轻重缓急,按照重要和紧急程度来做,尽量多做重要的事情,即使它可能并不紧急;细节则是指把工作内容要更加具体化,注意细节是一个良好的习惯
5.进真实项目的期望
第一,对方案设计,接口定义,项目流程以及java技术的各个知识点掌握的更加扎实
第二,培养自己在项目中控制风险的能力,确保自己不拖整个团队的后腿
第三,如果有时间,将任务中的深度思考再过一遍,将基础学扎实,为面试做准备
2.复习了请假之前学习的struts的基本知识
二.明天计划完成的事情
1.完成struts的restful风格请求的demo
2.开始研究深度思考中的内容
3.准备进真实项目面试
三.遇到的问题
暂无
四.收获
以上
五.项目进度情况
demo已通过,进真实项目评审也已经通过,接下来就是进真实项目面试
评论