国际化货币那些事儿

内网项目总结发的一篇小文,今年12篇文章告急,滥竽充数了o(╥﹏╥)o

第一部分涨姿势,聊聊什么是货币和国际化的场景下货币遇到的问题;
第二部分分享货币改造,聊聊货币改造是怎么玩的。
期望大家通过本文了解到货币的一些小知识,货币处理的最佳实践,以及分享下个人在项目推进中的一些总结。

一、聊聊货币

在具体谈货币之前,先抛几个小问题

1
2
3
1、$1.000 是多少钱?是1美刀吗?还是1000哥伦比亚比索?
2、哥伦比亚行程计价结果是:$666,用户能现金支付吗?
3、发奖励兜底限额,来个888万写死,够不够?

显然都不行,原因可以跳转下面货币小知识。


那么问题来了,货币到底是什么?
货币在经济学的解释是:货币 ,百科的描述是:货币

作为世界经济体系的核心,到底是个啥,身为一名底层码农,咱也不懂,咱也不敢问,咱也不敢讲。

但作为工程师角度,货币无非就是我们系统中录入,存储,传递,展现的一组变量。如何规范,准确,本地化的处理这组变量就是IBT货币改造的主要内容。


货币小知识
问题一:$1.000 具体是多少钱,要看具体的语言和国家,比如在语言美国(US)和英语(en-US)的情况下,$1.000标示1美元;但是在哥伦比亚(COL)西语(es-CO)的情况下,$1.000就表示1000哥伦比亚比索,西语的千分位都是'.',小数点是',',吃不吃惊,腻不腻害!

问题二:$666在哥伦比亚无法用现金支付,因为哥伦比亚现存的最小现金是50,所以在哥伦比亚的现金支付需要抹零,而且要符合法律规定的抹零。同时,还有很多国家是没有分的,例如日本的最小货币单位就是日元,没有日分(-_-)

问题三:888万看似很大,其实不然,例如哥伦比亚的汇率和人民币差不多1:500,也就是说不到888万,也就1w多。同时,由于int32最多存储2147483647,21亿如果是哥伦比亚按照分存储也就4.2万[21亿/100(分)/500(汇率)],所以存储和传递一定都要用长整形


分割线:科普到此结束,下面会重点分享下,货币改造的实践和项目总结;

二、广告插入^_^

前方高能预警

货币涨见识,时间度量衡更涨见识,多国环境下的架构抽象那才叫酸爽,各位架构师要不要来感受下?
请戳国际化出行平台工程师/架构师 投递链接 内推链接 活水链接

3亿+请求一天够不够玩?不够,那如果是牵涉资金和交易的流量呢?敢不敢来?
PHP/Go研发工程师(国际化支付)投递链接 内推链接 活水链接
Java研发工程师/专家(国际支付)投递链接 内推链接 活水链接

三、货币怎么玩

下面部分为阉割版,牵涉过多内部示例已经处理,仅保留项目推进和问题解决的一些总结


货币的重要性毋庸置疑,毕竟牵涉到
在我滴国际化土匪猛进的时候,货币问题在开发和线上频繁发生,给用户和业务造成了极坏的影响。举几个栗子


currency_iso


除了货币展现不一致的情况,通过上面的讲解你可能已经知道了,西语情况下2.5是有可能被理解为2500


自古有云:再一再二不能在再三,虽然走向了国际,但祖训不能忘

为了从根本上解决货币相关的问题,IBT在六月中启动了货币改造专项行动。

1
项目简介:加密,内容就是解决货币本地化处理和展示的问题,

权知轻重,度知长短,货币改造前先来分析下存在的主要挑战。

  • 本身牵涉细节多,工程量大,100+页面,几十个模块,多部门协调
  • 紧排期情况下,40多个关联模块升级的稳定性风险很高,兼容性升级是重中之重,不能因为改造而引入新的问题。
  • 整体排期,大联调和级联上线,核心一大块:API+收银+账单+fleet+各端+H5的整体排期,联调环境统一部署,占仿真,占pre回归需要提前预估到。
  • 质量把控改造不是目的,解决问题才是,那么落地质量就是需要最严把的关口

说了这么多,货币改造具体是怎么玩的?有哪些经验可以在后续项目中沉淀?

作者本人也是第一次驾驭横向项目,总结了下货币改造一期的在实践中六个步骤和细节,下文慢慢道来,先挂个整体时间图


currency_flow


总的来说就是项目推进的留个阶段:【六步走】细梳理=》定方案=》出排期=》助落地=》控质量=》查遗漏
下面分阶段阐述各个步骤的主要工作,要点和内容参考

3.1 问题现状梳理

核心工作:梳理现状,分析问题,定位重点和难点

货币改造的梳理阶段,梳理了IBT全量货币的存储、展现、传递现状;调研了限额、溢出、失精度,取整等技术和业务问题。梳理后重难点落在两块

  • 重点:用户感知最明显的,终端展现不标准,服务端格式化不统一,以及高风险溢出字段改造
  • 难点:模块间错综复杂调用关系,字段梳理和兼容性改造落地

贴一些该阶段的梳理和调研:参考内网小文

1
2
3
总结:问题现状梳理的核心贵在一个"细"字。
处于六部曲的第一环,一定要梳理尽可能细致、细致、细致的梳理,否则后面问题会被层层放大。
回头来看,这次货币改造还是有些梳理遗漏,给后面实践过程造成了很大的影响,例如:负号问题,券的页面归属,某些情况下司机端周流水页面等等。

3.2 标准制定发布

核心工作:针对调研现状和目标进行问题拆解,制定权威标准和落地可行最佳实践

货币改造的标准制定阶段,按照货币的存在的全生命周期(录入,传递,处理,存储,展现)进行了过程拆解,问题拆解,草拟各个阶段处理货币的可落地标准,结合业务实际情况产出落地最佳实践。

对于标准和最佳实践,着重要考虑了两个方面:

  • 一是权威:保证标准的可信度。在货币的格式问题上,专门成立个货币标准小组,和前线运营,产品确认当地的习惯
  • 二是可行:保证方案的可行。在货币的展现阶段标准上,针对目前系统的图表展示等,对货币原值保留了标准保留。

目前IBT的货币标准和军规 参考内网小文


格式标准举个栗子
currency_iso


处理标准举个栗子

currency_demo


1
总结:制订标准和最佳实践本质上是一个可落地的方案,在权威的基础上一定要注意可行性。

3.3 方案排期拉齐

核心工作:同步方案(涵盖标准/最佳实践/军规),评估各方实现成本,产出整体排期。

货币改造在这个阶段做的最重要的事情就是和15+团队单独沟通,同步方案,结合模块现状和细节,产出团队在业务快速迭代的情况下的方案和排期。

沟通和消息同步是这个阶段的重要事项,最终目的是为了

  • 同步标准。已读不代表理解,还是需要和各个业务方,亲自小范围的沟通方案,解答疑惑,标准的原因,方案如何落地,一定要注意哪些方面
  • 产出排期。家家有本难念的经,各模块的状况不一样,所以需要小范围沟通,结合模块的现状产出,处理重难点,不影响整体进展排期

方案拉齐阶段的一些资料供参考:参考内网小文

1
总结:小范围沟通是保证方案的同步效果,结合模块实际情况产出排期是结果。

3.4 整体改造落地

核心工作协助业务改造,工具支持,推进问题,同步风险

货币改造在这个阶段基本进入了业务的开发过程中,也是问题集中爆发的阶段。在这个阶段横向技术协助业务方接入SDK,协调测试环境,处理理解偏差问题,

针对开发中的问题,横向技术主要通过下面几个方式来推进

  • 开发工具提效:针对痛点问题,从整体和工具层面来协助,比如覆盖率等,应急性的解决问题。
  • 横向问题推进:针对这个阶段的跨团队技术问题的解决、推进,甚至对于风险瓶颈,要亲自上手(作者在这个过程中对于很多确实工作量大和排期紧的项目也是被迫自己上)。
  • 风险同步:针对排期风险和业务隐藏风险,要保证消息的同步通道和效果,本次改造过程中,两次全范围排期风险同步,一次SDK风险同步。

1
总结:核心是保证信息同步通道。只有风险,问题,细节,改造环境等等都完备同步了,才能把控好进度和质量

3.5 交付质量把控

核心工作:交付质量是重中之重,着重从质量通道的角度去把控。

该阶段货币改造过程中,这个阶段是黎明前的黑暗。初期的任何信息同步和设计遗漏,在此时都会彰显,比如没有做兼容,遗漏页面,遗漏接口,负数情况等等。

货币改在在这个阶段的主要抓手有两个:质量团队+RD检查项

  • 自检项:具体到每一点,是否执行到位。
  • 质量团队:QA作为最终质量的控者,从每一个细节去确认,同时从用户角度来把控。横向技术在这个阶段,参与了几乎所有case评审,共性case指定,异常情况探讨等等。

这个阶段特别要感谢QA同学:制定了完备的保障方案和连续两个周末加班支持


currency_check


currency_qa


列下本次整体货币质量保障方面的文档,后续的项目也可以参考借鉴:参考内网小文

3.6 问题遗漏汇总

核心工作:基本完成,一方面查漏补缺,一方面需要总结。

阶段性的总结是为了更好,更低成本的去实现下一次跳跃。
本次货币改造在这个阶段重点做了两件事情

查漏:梳理所有的遗留,遗留问题;针对问题复盘,针对这次货币改造内部复盘
总结:总结相关经验和成果

相关文档参考:参考内网小文

四、小结

国际化改造道重而任远,货币这次小小尝试,只是个开始。
关于时间,度量衡,数字,电话等问题域,也将逐渐展开,技术实现细节后面继续探讨^_^

崔小拽 wechat
欢迎您扫一扫上面的微信公众号,订阅小拽的博客!