阿烈的博客

事情都没你想的那么简单

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

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

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

  1. 你要申请支付宝接口吧?不同类型的接口的限制(是否能用信用卡,每笔交易的限额等)要了解清楚吧?这些限制会影响业务需求吗?
  2. 加上支付功能,当前活动模块的流程肯定会有变化:

    • 像创建活动时,要设置每人需要交多少钱。注明是否是需要交费的活动。
    • 活动报名的状态,可能要加上”未支付”/“已支付”的状态。
    • 活动发起人的报名表,要加上支付状态。
    • 支付过程中可能会出现各种推送通知,这些通知触发条件和内容模板是什么?
    • 如果用户真的不能在线支付,只能线下支付怎么办?
    • 用户支付成功,但由于各种原因不能参加活动了,钱如何处理?退款?
    • 用户支付成功,但最终活动取消,钱怎么退还给用户?
    • 用户交的钱,如何交给活动发起人?是否需要活动前只给70%,活动结束后再给剩余部分?
  3. 加上支付模块,肯定不能只为”活动”服务。如果以后有频道需要支付功能,也应该能很轻松的集成进来。订单系统如何设计?

  4. 用户应该有一个交易明细表,这样用户就能看到自己的交易流水!
    交易明细表如何设计?用户查看交易明细的入口在哪里?
  5. 是否需要每天生成一个对账单?以便于每天与支付宝对账!
  6. 支付宝给出的示例代码,并不是万无一失的。其中可能隐藏一些bug。这些都要小心!

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

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

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

对于第三方接口,都要考虑以下的:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
(1). 假定不稳定
不能因为对方挂掉而拖垮你的网站。
(2). 设置超时
如http请求,要设置连接超时和读超时。
以前我也是有教训的:在hui99时,使用第三方的短信接口,并使用官方提供的JAR包。由于接口方服务器调整,导致读接收短信时,数据不返回,且连接不释放。最终导致tomcat连接数耗尽而网站崩溃。
主要是对方JAR包内http连接,未设置超时。说起来都是泪啊!
(3). 添加监控
是否能连接?
是否能正常响应请求(响应时间)?
出错记录日志并提醒。
(4). 用日志界定边界
–所有的输入输出

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

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

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

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

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

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

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

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

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

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

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

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

笑来有一篇文章提到:

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

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

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