# 新浪微博发布的故事
本文粗略记述了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（�
