事情都没你想的那么简单

几个月前，项目组有一次开会说要为我们的活动频道集成支付模块，让一些需要交费的活动可以线上付款，免得活动发起人每次在活动举行前都催着交款。有人说，接口集成很快的，最多半天就行了。给人的感觉就像是活动集成支付模块，最多半天/一天的功夫就能集成上去一样。

事情真的有那么简单吗？有这么简单就好了。

调通支付宝接口可能很快，但是与现有的业务对接起来，要做的事情还蛮多的：

1. 你要申请支付宝接口吧？不同类型的接口的限制(是否能用信用卡，每笔交易的限额等)要了解清楚吧？这些限制会影响业务需求吗？

2. 加上支付功能，当前活动模块的流程肯定会有变化:

   • 像创建活动时，要设置每人需要交多少钱。注明是否是需要交费的活动。
   • 活动报名的状态，可能要加上”未支付”/“已支付”的状态。
   • 活动发起人的报名表，要加上支付状态。
   • 支付过程中可能会出现各种推送通知，这些通知触发条件和内容模板是什么？
   • 如果用户真的不能在线支付，只能线下支付怎么办？
   • 用户支付成功，但由于各种原因不能参加活动了，钱如何处理？退款？
   • 用户支付成功，但最终活动取消，钱怎么退还给用户？
   • 用户交的钱，如何交给活动发起人？是否需要活动前只给70%，活动结束后再给剩余部分？
   • …

3. 加上支付模块，肯定不能只为”活动”服务。如果以后有频道需要支付功能，也应该能很轻松的集成进来。订单系统如何设计？

4. 用户应该有一个交易明细表，这样用户就能看到自己的交易流水！
   交易明细表如何设计？用户查看交易明细的入口在哪里？

5. 是否需要每天生成一个对账单？以便于每天与支付宝对账！

6. 支付宝给出的示例代码，并不是万无一失的。其中可能隐藏一些bug。这些都要小心！

7. …

老总要加上支付功能，并不是调通支付宝接口就OK了, 你要考虑的是整个支付模块及相应的频道功能的调整！

其实，单是支付宝接口在调试时要特别注意两点：

• 支付的编码问题。因为要考虑签名及商品名的正常显示。
• 要多测试特殊商品名(如含有html标签)对支付接口的影响。

对于第三方接口，都要考虑以下的：

(1). 假定不稳定 
不能因为对方挂掉而拖垮你的网站。

(2). 设置超时 
如http请求，要设置连接超时和读超时。
以前我也是有教训的：在hui99时，使用第三方的短信接口，并使用官方提供的JAR包。由于接口方服务器调整，导致读接收短信时，数据不返回，且连接不释放。最终导致tomcat连接数耗尽而网站崩溃。
主要是对方JAR包内http连接，未设置超时。说起来都是泪啊！

(3). 添加监控 
是否能连接？
是否能正常响应请求(响应时间)？
出错记录日志并提醒。

(4). 用日志界定边界 
–所有的输入输出 

许多人都会高估自己，同时低估了事情的难度。一个功能，普通程序员预计一两天能完成，实际上到完全可用大概需要一周的时间。

许多事情看起来简单的事，想真正做好却很难。

酷壳上有一篇”你会做Web上的用户登录功能吗？“也能说明这种情况。

##不要轻易“低估”事情的难度

在2012年，我决定学习linux/linux运维的时候，我就觉得学linux是困难的。不抓住重点学，不边学边用，没有人带你走，弄不好还被linux搞。

从图形界面转到文本命令行，一开始是不适应的。

linux种类繁多的命令和参数选项是很吓人的。单是”鸟哥”那两本linux厚书，也让人有不少压力。

就算你将常用的命令和软件都比较熟悉了，常见的问题和错误都遇到过、解决了。一些好的思想和习惯可能你都没有。如：

操作前备份，操作后检查;
不清楚的命令，首先使用man;
查软件文档，首先要去官网，这样就能拿到第一手的资料;
...

所以 rm -f / 成了许多人心中的痛。

大半年的时间，大过分的下班时间都放在linux运维学习上，写了过千页的总结文档和笔记。很多都是线上的生产环境上的经验。

事情的”困难”和”容易”之分，就在于你所处的高度。大牛们经历过许多东西，所以他们能够举重若轻。

笑来有一篇文章提到:

如若一个人在一个方面能做到优秀甚至极致，那么他自然就会懂得一个道理：

精通某个技能，需要大量的练习、重复、自我观察、自我纠正、反思、进阶、自我否定、自我怀疑……以上循环，最终达到一定地步，进而自信……这个过程中反复能体会到的东西就是，越是简单的环节越容易成为短板，所以要格外重视；越是复杂的东西就需要越多的重复训练——直至最终做到“举重若轻”……

所以，简历上不要轻易写”精通”两字。