两次灾难性的项目开发经历复盘

焦油坑的开发经历

Posted by Jinnrry on November 5, 2020

史前史中,没有别的场景比巨兽在焦油坑中垂死挣扎的场面更令人震撼。上帝见证着 恐龙、猛犸象、剑齿虎在焦油中挣扎。它们挣扎得越是猛烈,焦油纠缠得越紧,没有任何猛 兽足够强壮或具有足够的技巧,能够挣脱束缚,它们最后都沉到了坑底。 –«人月神话»

在这里复盘总结我所经历过的两次最为灾难性的程序开发经历。之所以称之为灾难,是因为以下几个问题十分严重:

  1. 项目开发过程中严重延期,且无法预估到底什么时候能结束
  2. 项目提测质量十分差,测试介入第一天就有上百个bug单
  3. bug修复速度慢,测试新开的bug单远多于关闭的bug单
  4. 代码逻辑频繁改动,测试过程中还在修改业务逻辑

项目就如同这样一个焦油坑,好在最后,我没有一直陷在其中,最终都成功爬了出来。

项目一:马蜂窝足迹2.0

背景

马蜂窝足迹作为马蜂窝品牌级别的项目,从立项开始就收到CEO层面的高度关注。足迹2.0更是基于1.0版本的全面迭代,2.0版本深化了地图上面的交互逻辑,增加了基于地图的各类玩法,同时与笔记互动,在宣传公司品牌的同时达到引流目的。

项目开始,部门leader亲自指挥,调集了各个部门最核心的开发人员提供支持。同时,由于项目的意义重大,也规定出项目得最快时间上线。当我进入项目的时候,项目一共11个研发,4个前端,3个后端,4个测试项目排期已经确定,基本上就是3周时间上线。

排期会基本上就是开发和测试之间商量各自要多少时间。

初期

项目开始,我们3个后端开了一个短会,上一版本的开发介绍了业务背景,然后以前讨论了项目技术方案,确定了每个人的分工,整个会议大致一个小时就结束了。各自有了各自的分工,然后大家就立马开始了coding。

第一次延期

大致在两周后,到了提测的时间点,第一个问题出现了,项目进度大致不足一半,完全没法进入提测。这时,有好几个问题摆在我们面前,

1、足迹在地图上面必须使用正六边形展示,以前调研使用uber的h3算法绘制六边形,但是h3算法绘制出来的完全不是正六边形,会有极大的形变。

2、由于六边形算法没解决,前端也没法完成动画相关的开发

3、国界线附件的poi归属问题(由于gcj和wgs坐标系偏移,无法根据经纬度准确定位出国家线附件的poi属于哪个国家,对于敏感地区,这会带来严重的政治问题)

这时,由于这几个问题根本找不到解决方案,完全没法给出预估提测时间,因此灾难的第一个问题出现了,项目开发过程中严重延期,且无法预估到底什么时候能结束。这种状态大致持续了一周多,我们最终终于找出了解决方案:

1、对于算法问题,我在经过各方调研后,决定自己动手基于墨卡托坐标系来实现一个分形定位算法,保证展示出正六边形。(这个算法后续申请了专利,包含分形和索引两部分)。 2、对于poi归属问题,跟产品多次沟通后决定,直接隐藏掉国界线线附近的poi。

这两点确定以后,就开始了算法推导和代码实现,差不多花了1周的时间。而对于隐藏国界线附近的poi这个方案,又引出了另外一个问题,如何判断一个poi是否是国界线附近?这又是一个难题,因为国界线都是不规则曲线,根本没办法直接确定一个poi离最近的国界线距离是多少。

对于第二个问题,还好我是地图服务部门过来的,我找到了组内同事,经过多次讨论,决定引入goole s2算法来计算距离问题,而封装s2接口,导入数据,生成国界线索引等等问题,大致又花了3天左右的时间。

最终大致在延期半个月后,我们基本上解决掉了主要的问题,完成了整体业务流程的开发。

这时,领导找到我们,问能不能确定什么时候上线,测试那边给出以前的排期时间,一周完成测试,测试完就上线。

第二次延期

而提测后,第一天我们就傻眼了,4个测试,第一天就提了100+的bug单,而我们一天能修复的,大致也就20个不到,这里,第二第三个灾难出现了,项目提测质量十分差,测试介入第一天就有上百个bug单,bug修复速度慢,测试新开的bug单远多于关闭的bug单。

又过了3天,bug数到达顶峰,大概有200+未解决的bug,这3天测试新增bug单的速度虽然放缓,但是依旧高于开发解决速度。到这里领导也坐不住了,给项目派来了人力管理,同时决定加派研发人手,里面从别的项目中抽出了三个后端开发过来专门帮忙解bug。

而由于新人加入,这里项目又停下了2天去给新人梳理业务逻辑,同时分析我们项目架构是否存在问题。经过2天的梳理,最终得到结论,设计没问题,大家继续解bug。

大致到了第二周测试结束,bug已经解决了大部分,仅剩少量待修复,而且由于每天稳定的bug关闭数,大家都觉得上线就在眼前。这时我们决定开始准备上线计划,而本来简简单单的上线计划,这次再次成为大问题。由于足迹1.0的用户数据和2.0的用户数据完全不兼容。

第三次延期

线上根本不能直接上线。而如何完全线上不停机更新,用户数据平滑迁移,再次成为难题。

经过大家的讨论,最终我们决定,分离2.0的数据库,2.0新起数据库,使用脚本把1.0的数据更新到2.0的库中,这样保证线上升级无感知,同时具备紧急情况的回滚能力。然后就是迁移脚本编写、测试,大致又花了两三天的时间。

而由于有库(这里的库不止MySQL,还有ES,部分数据以前在ES里面,需要迁移到MySQL)的改动,又涉及到了业务代码逻辑的改动。业务代码重写以后,又需要测试人员重测以前的所有逻辑。

最终在大致延期一个多月以后,终于完成了最终的上线。延期的这一个月中,所有开发、测试、产品,基本上都每天加班,周末无休。

项目二:小米商家返利系统

背景

以前小米专卖店的返利计算全部都是由财务使用excel计算,费时费力,同时经常算错,和商家自己算的数据经常对不上。随着小米线下门店的增多,迫切的需要信息化系统支持。

初期

这个项目第一时间并不是由我负责的,前两次需求会我都没有参加,但是由于相关同事请假,这个项目被分到了我头上。我是在晚上下班点的时候拿到的需求文档,第二天一早就被拉去了排期会,我大致瞅了瞅需求,然后各位要求给出一个确定的排期日期。

当时对需求也没什么概念,只知道大致就是要做一个后台,能够配置激励政策,然后需要数据组取我这里的政策配置计算商家的激励金额,然后我再去取数据组算好的激励金额,推送到财务去。当时理解很简单,我这里就是一个配置中心,没有任务业务逻辑,所以

就预估着给了两周的排期。由于我们部门还有其他更重要的项目,所以抽不出人手,这个项目的后端就由我一个人来负责了。最后确定的人员是:后端1人,前端3人,数据组2人,财务2人。

开发阶段

刚刚进入开发,我梳理完需求,才发现政策的创建,金额的发放,都是需要接入审批流的。另外,后台的各种操作,也需要加权限配置,不同角色有不同的操作权限。这是第一个意料之外的情况。大致在开发进行了3天左右,产品找到我说发放金额不能只推送一次,

财务那边需要一个预期金额(用于准备资金),这个金额必须在发放前一周推送过去。这时,我叫上了数据组同事,一同商量了对应的解决方案,修改了之前的数据同步方式。

对于审核流,因为公司内部有现成的审批流系统BPM,创建审判流只需要画好审批流程图,给出对于审批节点的审核人就行。当时我就让产品画好审核流程然后去联系BPM同事创建审批流(这一步我当时没有参与,埋下了大坑)

在第一周开发结束后,不旦进度没推进多少,反而业务逻辑加了好多,因此时间瞬间变得紧迫了,后面每天都加班到11点以后,周六周末也是全天无休。最终项目延期一天完成了全部的开发工作,其实仅仅是写完了全部的代码,时间紧得连全流程联调都还没走过。

测试阶段

由于开发阶段时间太紧,连整个流程都没走过,所以冒烟测试啥的肯定是没有的,直接提测让测试介入了。测试介入后,bug单也是哗哗哗的提,根本停不下来,第一天bug大致就破百了。而且同样的bug修复缓慢,其中很多问题其实应该是开发阶段处理的,都留到了测试阶段来处理。

测试第二天,测试同事说审核流程和需求文档对不上,我这时才想起,我都是按bpm同事给的流程开发的,没有看产品文档,会不会产品和bpm沟通出现了问题。赶紧叫来了产品同事,一问,果然,产品某些审核细节bpm同事那边理解有歧义,导致bpm建的审核流不对。导致我开发的程序流程也不对。

事已至此,也只能硬着头皮加班改了。

上线最后一天晚上,测试同事发现最后发钱的时候财务是有一些特殊的驳回逻辑系统里面没有对应处理。这时再产品询问,原来产品以前也不知道这个逻辑,因此急忙在最后一天又改了业务流程,加入了这部分的驳回逻辑处理。

由于测试阶段的几次改业务流程,最终导致测试延期3天。最终上线也延期3天。(虽然只延期了3天,但是背后是所有开发、测试人员连续半个月每天加班到11点以后,周末全程无休)

复盘总结

一、项目前期准备很重要

对比两个项目都能发现,项目前期基本上没有什么准备,排期要么是领导直接就定了,要么就是研发还没读懂需求的情况下给出来的。同时,需求的细节缺少详细的讨论,结果就是开发过程中发现很多问题,这是才找产品讨论,然后再改需求,改业务逻辑

进而导致项目工作量增加,甚至导致之前做了无用的开发工作。

对于一个项目,前期一定要有充足的准备,确定所有研发完全理解需求,了解需求所有细节问题。另外,排期一定是要在设计完项目架构以后给出。

二、无论项目多急,开发流程不能变

不能因为项目时间紧急省去部分开发流程,比如冒烟测试,联调自测。这些流程如果省略了,其实仅仅就是开发把很多问题推到了测试阶段去解决,从而导致测试阶段还在做很多开发工作,测试刚测完的东西,研发又改了,最终测试不停地在重复验证某些流程。

三、产品和其他部门研发对接,己方研发得参与

产品和研发直接沟通,很容易表达出歧义。像返利的bpm流程创建的时候,产品跟bpm说财务审核,其实财务是另外一个系统,而bpm同事以为财务是一个人员角色。导致整个审核流创建出来完全不对,造成了很多无用的开发工作。