从“差不多了”到 正式发布 -- 新浪微博WinPhone UWP版诞生记

时间:2023-03-08 16:17:56

本文粗略记述了UWP团队从接手新浪微博项目到发布第一版的过程。本文不是技术贴,而是回顾“软件工程周期失控是一种怎样的体验”。

接手新项目:捡了个大便宜

2016年1月份,UWP team开始接手新浪微博项目。前一个研发团队的最后一名员工计划于1月底离开项目组,我们需要在此之前完成技术交接工作。经过几轮讨论,项目状态很快搞清楚了:东西已经做“差不多了”,把几个基本问题改掉就可以发布了。我们立马有一种捡了大便宜的感觉:别人辛辛苦苦做得产品,居然留给我来发布!

怀着捡了便宜的激动心情,我们很快进入状态。按照老板的要求:1个研发人员1个月内提交第一版。我们1月19号创建了新的代码分支,之后熟悉代码、编译过程、安装调试环境,按照前同事的建议改进、完善,然后回家过春节。。。

从“差不多了”到 正式发布 -- 新浪微博WinPhone UWP版诞生记

在这期间主要对软件启动做了一下性能优化,我们特意找了一个配置很差的手机(工程机)来测试Debug版本的启动时间,经过一系列优化之后,启动时间从1月25日的14.64秒缩减到了2月19日的7.97秒。(4月25日发布版本在950XL上的启动时间是2.35秒)

附:1月25日debug版本的启动时间(工程机)

从“差不多了”到 正式发布 -- 新浪微博WinPhone UWP版诞生记

附:2月19日debug版本的启动时间(工程机)

从“差不多了”到 正式发布 -- 新浪微博WinPhone UWP版诞生记

第一次提测:丢人丢到家

春节回来就是2月中旬了,我们把之前团队建议的几个“未完成项”都完善了之后,2月23日打包提交测试,提测日期比老板的要求晚了几天。在等测试结果期间,我们还在不断地熟悉代码和整个产品。测试组3月2日提交了部分测试报告,说产品不满足发布状态。经过一番折腾,测试组3月4日提供了完整的测试报告:测试中发现了44个bug,其中A、B、C类(必须修复)bug共19个。

这样的结果印证了老板春节前留下的那句明智的话(老板说完就去美国了):不要高兴得太早,如果真是“差不多了”的话,为什么前一个团队不多干几天把版本发出去再闪呢。Weibo UWP 从来没有在手机端全面测试过, 这里面的问题一定非常多。

教训1:研发说“到目前为止没有发现问题”不等于真的没有问题,可能只是因为没有跑过Full test而已。

看到测试报告的那一刻,当初捡便宜的心情瞬间就消失的无影无踪了,取而代之的是惭愧。作为微软的软件工程师,把带有这么多bug(事后证明远不止这么多)的半成品提交给测试组,真的是一件很丢脸的事。更丢脸的是,其中三分之一的bug我们都不知道在说什么,因为接手项目时间太短,之前把大部分时间都花在了已知的需要改进的几个问题,还没有来得及熟悉整个产品,以至于一些bug中提到的功能页面都找不到。

教训2:对于新接手的项目,在完全熟悉产品和代码之前不要自以为是地敲定发布计划,否则请准备好被打脸。

附:第一次提测的bug list

从“差不多了”到 正式发布 -- 新浪微博WinPhone UWP版诞生记

打回重做:知耻而后勇

惭愧归惭愧,事情还是要继续做的。因为之前用新浪微博只是看一下首页和消息页面,很少切换到其他页,更不用提二级、三级页面了。现在既然小修小补不能解决问题,大改之前要先了解整个客户端产品:

  • 首先赶快申请加两个Full time的研发进来,并且申请项目延期;
  • 大家分工详细了解每一个页面,和页面对应的逻辑;
  • 对于找不到的页面,探索怎么把它们弄出来;
  • 深入了解每一个功能模块,并且熟悉每一个操作细节。

经过一番探索之后才发现,微博客户端的内容还是蛮多的,而且其中有相当一部分都没有开发完。得出这个结论后,我们只好放弃了“尽快发布一版给WinPhone10用户”的想法,把新浪微博作为一个长期项目来做。之前计划在“差不多了”的基础上,1个人1个月就把第一个版本发出去;调整计划了之后,3个人再延期两个月才把第一版发出去了。

教训3: 功能“差不多了”不等于产品“差不多了”。你花了4个月时间做了80%的功能,并不意味着1个月后就可以发布了。剩下20%的开发和产品完善的工作可能又要4个月。

在之后不断熟悉新浪微博客户端的过程中,除了解决测试报告里的44个bug之外,我们自己还发现了大量隐藏的bug,其中有记录的有50个左右,没有记录的小问题就更多了。前前后后加起来,总共解决了100多个bug之后才达到了我们自己认为比较满意的状态。

附:研发组自测的部分bug list

从“差不多了”到 正式发布 -- 新浪微博WinPhone UWP版诞生记

第二次提测:一波三折

在解决了100多个bug和两轮自测之后,我们在3月29日第二次提交了发布包给测试组。4月15日,测试组完成测试并提交了测试报告,其中没有A、B类bug,C类bug7个。到这时候我们心里有底了:这次才是真的“差不多了”。

教训4:如果研发说“差不多了”,你就当他什么都没说。测试报告说“差不多了”才是真的差不多了。

研发组迅速解决了所有C类bug,并在下一个工作日(4月18日 星期一)提交了新的安装包。在新一轮测试中,我们发现了一些以前从没遇到过的、很诡异的问题。其中情况最复杂的是私信页面的一个bug:

1)     在项目交接之前,私信页面上拉加载更多时,部分私信会重复出现;

2)     2月19日,研发组解决了1)中提到的问题,之后很长时间没有发现私信重复的问题;

3)     3月4日,测试组提交的测试报告中所附的44个bug里面,没有提到“私信列表重复”的问题;

4)     4月15日,测试组的第二轮测试报告提交7个C级bug中提到私信重复的问题

5)     4月15日,研发组调试时发现私信页面上拉时,前20条私信无限循环加载;

6)     4月15日晚,研发组解决了5)中提到的私信无限循环加载的问题;

7)     4月17日,私信循环加载的问题再次出现,重新安装新版本后消失,未来得及确认私信重复的规律,也无法确认复现问题的版本是fix之前还是fix之后的版本;

8)     4月18日,反复测试新版本私信列表未发现异常,研发组再次发包提测;

9)     4月19日,接到测试组的测试反馈提到“私信列表仍然重复”;

10)  4月19日19:30左右,研发组在自测中发现新的私信重复模式:前20条私信重复加载两遍,其他部分正常;

11)  4月19日20:00左右,研发人员回公司启动调试环境后发现9)中提到的问题自行消失,反复尝试仍然无法重现,也无法调试。

相信所有研发对很难重现的问题都会头疼。根据之前的经验,我们怀疑这个bug是和服务端相关的(大部分时间工作正常。一旦出问题时,所有手机的客户端都会发现同样的问题)。最后我们决定:在开发环境里面反复测试每一个诡异的bug,一旦发现问题立即跟踪调试并解决问题;如果连续测试12小时仍然无法重现的话,我们认为该问题对实际用户影响很小,不影响发布版本。

在反复测试的过程中,有一些bug在开发环境中被重现并解决了。其他问题经反复试验无法重现,降低优先级后留到以后解决。

正式发布:鲜花和鸡蛋

4月25日,新浪微博WinPhone UWP客户端终于提交到了应用商店。收到了很多正反馈,当然也有一堆骂的,在这里就不贴图了。

下一个版本

在接手这个项目的时候,我们接到的指示是“不添加新功能,尽快把已有功能完善后发布出去”。但在实际开发的过程中,我们发现现有的版本还缺失很多重要的功能:比如搜索功能、视频的横屏模式、夜间模式等。这些都已经被列入了下一个版本的开发计划中,请各位耐心等待下一版本的发布(会很快)。

另外,各位有什么功能需求可以直接在评论区留言,我们会定期查看并筛选一些需求添加到下一版的开发计划中。

致谢

感谢新浪微博相关部门/个人的协作并最终促成了产品的发布。尤其感谢研发组的技术支持,感谢测试组把UWP提到主线产品的优先级进行测试,感谢产品经理的多方沟通和配合。

感谢新浪微博商务和微软商务促成本次合作。当前的版本还有很多不足,我们会持续发布更新版本,尽快提升产品的用户体验。