项目复盘之回到上海后的第一个项目,我受益匪浅

项目复盘之回到上海后的第一个项目,我受益匪浅

随着jxlife项目接近尾声,我也接到了项目组调离的通知,即将开往新的项目组,回想这个项目的点点滴滴,有很多感慨。为了后面走的更加顺利特此进行复盘,将项目中的优点继续发扬光大,将项目中的缺点尽量挖掘,并寻求最佳解决方案。

优点

  1. 按项目工期如期完成
    这个似乎不是我个人的优点,是我们团队的优点,在我们团队负责的这一块,都是按照计划中的时间节点按时交付,所幸个人没有拖后腿,希望再接再厉
  2. 项目bug数低于预期
    这个依旧不是我个人的优点,是大家共同努力的结果,在大家冒烟测试后直接发布到环境,执行了接近4000个测试用例,bug数200左右,这是我们团队前期的需求KT,详细设计质量较高的功劳

不足(专指个人)

  1. 代码质量较差。
    冒烟测试,单元测试覆盖率20%发布到环境,团队200个左右的bug个人贡献了其中的1/3,一部分是个人在编码的时候手误造成一些低级错误,比如相似字段set错值导致updte到db出现字段错位,一部分是对需求理解不到位,没有把需求细节和设计文档吃透开始写代码(虽然有时间上的要求和自己对业务不熟悉,但这不是可以亡羊补牢的借口,因为不允许亡羊),没有把需求和设计理解清楚就开始写代码,往往会造成回头发现有问题,再进行修改的浪费时间和精力的后果。好在没有delay,不然这个结果足以导致整个项目出现delay。
  2. 功能开发估时与实际有较大偏差。
    在估算时间的时候往往会只算当前功能编码时间,缺乏考虑一些外部因素。比如开服期间会被打扰到(有统计学家统计工作中每10分钟就会被打扰一次),比如没有调研清楚当前功能的上下文及场景,把功能想的太过简单。除了编码时间,还有单元测试,自测。自测的时候需要考虑环境,权限,上下文等联系。
  3. 出现问题得出结论缺乏理论支撑。
    其实编码工作在上UAT环境之前2周就已基本完成,后期一般进行性能测试和优化,其中个人编写的服务由于查询效率低下成为了性能优化的重点,期间出现过各种数据库瓶颈,个人认为是数据库链接的问题,因为当前数据库链接使用的自研框架(因为公司封装了一套类似sharding-jdbc的分裤分表中间件),出现瓶颈问题的时候总是把眼光放在了这套框架上(个人思想是开源的框架大都经过大小公司的洗礼,有问题会及早暴露),实际上缺乏理论支撑,自己并没有任何证据证明当前框架有问题,只是自己的主观臆想。
  4. 理论有,但实践起来往往想不到。
    几乎每个玩spring的大佬都知道,同一个service里,加了@Transactional注解的A方法调用同样加了@TransactionalB方法,B方法是不会被拦截到的,当前项目中出现了这个问题,直到出现数据不一致情况,才发现这个问题,这个问题是知道的,只是在编码的时候没有注意到。稍微懂mysql的都知道联合索引的最左匹配原则,建索引和查询的时候,都会把查询的字段和建索引的字段按照统一顺序进行查询和创建索引,项目中忽略了这一点,结果导致数据库查询虽然创建了索引,但是依旧全表扫描,效率低下。在CompareAndSet这种场景下往往会出现并发问题,应当时刻注意这个问题,但在项目中出现场景:先根据条件查询,查到返回主键,查不到保存这条数据然后返回主键。这种场景是典型的CompareAndSet,直到并发条件下,出现了两条除了自增主键和业务主键不同,其他字段均相同的数据才发现这个地方忘记考虑并发问题了。
  5. 粗心大意,丢三落四。
    当前项目部署了五套环境,分别是DEV、TST、UAT、PRE、PRD,项目的配置使用配置中心,其中一套环境添加某个配置时,其它四套应该做相应修改,有时会出现环境在修改,只修改了其中两套,然后被人叫走,回来后剩余的忘记修改,导致上线后出现问题,排查到最后发现配置未修改。另外一种场景是在当前环境进行测试,想着发布别的环境的时候修改,结果过了一段时间发布环境却忘记修改。
  6. 缺乏独立思考能力。
    从项目开始就一直按着项目设计文档实现功能,一个分支,一个跳转都不会有任何怀疑的实现,看似一丝不苟,其实缺乏了自己独立思考的能力,项目到UAT环境进行复盘的时候才发现自己的服务很多地方都讲不通,不是设计问题,是自己太死板,本该想到的矛盾点就摆在面前,丝毫没有发现,正常情况下应该对一些逻辑进行质疑,而事实是并没有。
  7. 缺乏大局意识,往往想不到各个服务间的关系和影响。
    在修改某个功能的时候,往往只能看到自己服务内部的情况和影响,缺乏对整个流程和上下游业务的整体把控,导致自己能自圆其说,但是对于上下游服务来讲,严重影响协作服务的业务逻辑,甚至有些实现在服务内部是合理的,在协作服务那里却不是合理的实现,欠缺对上下游服务影响的考虑,无法整体把控。
  8. 技能包不够全面,尤其是性能方面。
    直到性能测试的时候才发现自己的性能测试方面的技能包几乎为空白,从性能到监控,自己甚至都不知道指标是什么,用什么工具去监控,用什么工具去压力测试。真的是砖到用时方恨少,自己搬的还是不够多。
  9. 缺乏稳重。
    在和客户沟通的时候情绪容易激动,当听到客户想实现一个不太现实的想法的时候,自己的第一反应居然不是耐心的给客户解释,而是直接怼回去。这种心理和想法,从一开始就是错误的。

针对性解决方案

… to be continued

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

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

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

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值