距离支付宝9.0发布已经一个月了，是时候总结一下了。

开发节奏

支付宝9.0的开发节奏，初期是比较乱的。我刚接手的时候，遗留了许多零零碎碎问题。同时需求是一直在改，包括进入RC阶段后。甚至出现某个点之前需求还在做，已经有了新的修改想法。这时候开发被拖累得很严重，项目延期风险很大。之后技术大佬们有意控制需求变更，问题逐渐收敛，最终如期发布。

恶性循环

以前在点点大多数时候九点左右回家，除了担任Scrum Master那段时间。在支付宝9.0开发过程中，工作强度感觉达到以前的2倍。相应地工作时间变成了十零六。有人做过研究，睡眠时间不足的工作状态与饮酒类似。开发过程中正在忙的事情常常被打断，其他人经常来找，反馈问题询问实现逻辑沟通需求等等。白天基本上在处理这样的问题，写代码的时间只能放在晚上，并且时间占到工作时间的一半。这样的工作状态导致写代码容易出现问题。相应的代码出现问题，会有别人来反馈，测试提bug，会花费更多时间，形成恶性循环。

跳出循环的办法就是谨记状态不好不要写代码，尤其是关键代码。把自己的工作时间做好规划。用工具来记录每天要做的事情，反馈的问题先记下来，之后花时间一起改。编写关键代码的时候找会议室或者露台来避免被打扰。做了这样的调整之后，工作状态明显有所改善。

用户体验无小事

开发过程中一个很深的经验就是用户体验无小事。之前在点点，一些难以解决的问题，或者交互上的小问题，大家沟通过认可就可以了。发布后也没有遇到客户投诉之类的问题。在钱包这样一个用户量很大的重视客户体验的客户端中，这样的问题要么用户或者测试反馈，要么老板发现，甚至上线后用户反馈。总之最终一定会暴露，而且暴露越晚越被动。典型的问题就是界面的红点提醒。接手的时候方案已经定了，存在不一致的问题，技术上服务器端没有精力解决，产品也认可。最终上线后这个问题反馈比较多，老板也非常关注。虽然问题只能服务器端解决，但是用户始终看到的是客户端。用户体验的问题一定要有owner意识，无法独善其身。

最后时刻改需求是万恶之首

总结一些bug，开发后期多个bug都是由于最后修改需求导致的。即使改动点很小，自己考虑过可能涉及的地方，还是难免有疏漏。此时暴露出问题来，影响比之前暴露要大。最后改代码找人review是必要的。同时自己静下心来仔细思考涉及的改动是最关键的。

自己不是万能的

以前在点点开发中遇到一些问题，自己会去跟踪下去，直到找到对应的开发，解决问题。在支付宝这样一个庞大的系统中，事实证明这样做是事倍功半的，系统庞大到4通电话都找不到责任人。遇到问题，排查自己这里没问题，将问题向下反馈，这样效率最高。如果能做到熟悉自己的代码，很快可以确保自己这里没问题，就更好了。

从繁重开发中抽身

这次商家首页和类目/搜索页由我负责，两个非常重要的页面。使用的基础组件并不像手淘那样稳定，经常会踩坑。而且两个页面都用到新技术来开发，要解决的问题很多。整个开发阶段非常忙。9.0结束后思考怎样从繁重的开发中抽身出来。目前已经把部分页面交给其他人负责。同时完善了文档。包括页面唤起协议、一些复杂的逻辑流程图等等。确保别人来咨询一些问题给他们文档就可以了。