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

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

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

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

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

附：1月25日debug版本的启动时间（工程机）

附：2月19日debug版本的启动时间（工程机）

第一次提测：丢人丢到家

春节回来就是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

打回重做：知耻而后勇

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

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

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

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

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

第二次提测：一波三折

在解决了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）中提到的问题自行消失，反复尝试仍然无法重现，也无法调试。