PART1/3
程序员做的功能上线后一般是交给别人使用的，比如运营后台会给运营人员使用，网站会交由最终用户使用。而程序员自己，往往很少光顾的。后续呢？程序员会不断收到功能修改和完善的请求，然后，机械性的去编码给予实现。
互联网IT团队分工细化，除了程序员，还有QA、UE。
我们常常看到，程序员将功能提测后，QA/UE会提出来一堆的问题，一部分是功能实现的bug、还有一部分是包括对原需求的改善，以及UE如界面交互的提升。一个测试过程对程序员来说，有时工作量比开发过程还大。
等测试ok上线发版后，对程序员来说一切就万事大吉了。
功能不被使用，就不会被发现有哪些不足。
自己不用，你永远不知道自己做的东西有多烂。这话听起来多少有些尖锐刺耳，事实往往正是如此。
PART2/3
我之前发文，介绍了一款自己做的运营工具。当然，只是team内我们几个技术人员用。不过，在每天至少两次的使用过程中，发现操作还是比较繁琐的。于是，我再度做了改进。chrome里F2看到的效果是下图这样子的。
PART3/3
那天跟公司的UE小伙聊天，真有一种共君一席话胜读十年书的感觉。他介绍，在体验公司的在线理财产品过程中，整个网银支付环节，浏览器地址栏跳了6次，体验极差，一旦用户网络慢，体验将更差。这我才意识到，这的确是个糟糕的实现。一个网银支付，涉及到公司的三个站点，首先是那个在线理财平台，然后是公司的聚合支付网关，然后是公司的支付中心。这三者的通信靠的是form表单自动提交的方式，这就涉及到浏览器的跳转。最终支付中心同样会通过这种form表单自动提交的方式将请求数据发送给第三方支付平台，最终到网银端，用户输入卡密完成支付。
曾经我和同事争论，就网银支付来说，我同事说让下游支付系统通过服务端与支付中心通信，支付中心返回请求三方的form表单，由下游支付系统输出进行跳转。我凭经验，坚持认为应该让下游支付系统用form表单自动提交的方式，将数据请求到支付中心，这样也保证了数据的安全。
现在兼顾UE的角度来看的话，就有必要废除我那种经验式的实现了。解决方案是改为服务端通信，支付中心把请求三方的form表单作为一个url返回给下游系统。下游系统重定向到这个url，这个url实现form表单自动提交，这样就减少了一次浏览器跳转。进一步来说，考虑到下游支付系统是公司内部系统，不妨利用我同事的那种方式，直接把请求三方的form表单返回给下游系统，这样下游系统来输出到浏览器实现跳转，这样就又减少了一次浏览器跳转。这对用户体验来说，将是很好的提升。
CONCLUSION
泡了一瓶水，一篇文章，一个午后。调皮的小侄儿非要给拍个照片O(∩_∩)O
