本文是为了谈论技术架构管理的，不要带入实际生活

起

工作是这样的，有一款产品需求完成国际化的注册需求，界面如下 ：

血压飙升！记一次关于手机号存储的前后端谈论

触及到的手机号码，由于要区分国家区号，所以和手机号是分隔的，前端形状是分隔存储的。一开始数据确实也是分隔存的，么的问题。

本来是很简单的表单需求，效果出了幺蛾子。

承

对于前端来说，这便是两个字段，在表单传值和数据逻辑处理时，直接用两个字段无疑是最直接和简单的：

const formData = {
    country_code: '86',
    phone: '13345431234'
    ...
}

但是，产品侧有一个强需求：手机号和其他的两个字段要做唯一性校验，不光要求三个至少存在一个，而且还要查其他业务库的数据表来校验这个注册人员的唯一性，有一套杂乱的逻辑。总结一下便是，后端分隔两个字段来判别很麻烦，这个也好了解，有耦合的逻辑重构要本钱的。所往后端是这么要求数据的：

// (86)13345431234
phone: `(${country_code})${phone}`

将国家堆积在前缀括号里拼接为一个字符串。这样一来，前端的本钱就相对高了一些，不光在表单提交时要拼接，而且在列表查询时，要依照括号匹配解分出前缀来动态显示。

const regex = /^\((\d+)\)(\d+)$/;
const matches = phoneNumber.match(regex);
// 假设匹配成功，回来国家码和号码的数组
if (matches) {
    const countrycode = matches[1];
    const number = matches[2];
    return [countrycode, number];
}

就算这样，也可以接受，之前也不止一次挖过这种自己拼接自己解析的坑了。但是随后就有点让人血压上升了。

转

由于业务扩展，上面的手机号，要传递给一款即时通讯软件 xxx 的 API 来做下发，下发侧则规则了，需求不带括号但是要有国家区号前缀的手机号码：

// 8613345431234
phone: `${country_code}${phone}`

这就有问题了，我们直接对接的后端需求括号的，下发侧对接的后端同学不需求括号。

第一阶段

血压上升 20%

谈论让后端换成两个字段存储，这样更活络，便利拼接；或许给下发侧发数据时去掉括号也可以。后端很为难：”唯一性判别还有其他的逻辑很杂乱，有耦合性，拆开字段就要重构，工期又紧，刚完成就要改，误了工期只要我背锅；去掉括号不是不可以，但当地有点多，还要考虑批量数据的功能，而且已经进入测试了，不接受暂时需求“。我一想有道理啊，就去问下发侧同学。

第二阶段

血压上升 60%

问下发侧对接的同学，可以处理后再给 API下发吗？决断拒绝。他们也有理由的：”依照软件规划的标准，我们不应该非标处理这个问题的，下发的标准理应便是我们接口的标准，由于标准还有许多，这个当地让步了，往后必定还会有更多的非标处理，我们的代码就乱了。“

我草，我一想之前那那么多屎山的由来，觉得更有理了，那怎么办？弄得如同前端这儿没有理了。

第三阶段

血压上升 120%

下发侧对接的同学反过来给我们前端提了主张，让我们在注册的时分，把前端两个字段就直接不用括号来拼接给后端，在需求解析的时分，运用特别手法解分出国家码。还善意的给我们搜索了一个解析手机号的 js 库：

血压飙升！记一次关于手机号存储的前后端谈论

我只能说，我 TM 谢谢你。

前端不可思议的随便多了需求，而且加个库为了给后端擦屁股，还增加了打包体积，出了问题我们得首要背锅，这必定不可。

合

这起工作牵涉的技术问题并没有多难，甚至有些单纯，但是却蕴含了不少上班族哲学，最主要的一点是：怎么学会背锅的问题。锅不是不能背，但是背锅换来的应该是产品成功后更多的劳绩酬谢，而不是这种暗箱操作，老板压根不知道，只要扛不住的人吃暗亏。

个人觉得，这个应该是架构师或许技术总监的任务，提早了解上下流业务，并确认好字段与数据结构，而不是等用的时分才发现数据对不上。规划好用什么方案来开发。并将方案规划交于老板开会谈论得出定稿。之后再分派人员开发，就不会有这个工作了。

相似的问题还有许多，前后端与下流核算价格进制与单位不统一，每次都要非标转换；

最后的结局，产品出面调停，软磨硬泡，毕竟后端让步了，夹在前端和下发侧之间, 确实为难。针对前端还是本来的逻辑不动，运用括号存储，他在下发侧拉取数据的时分做转换，去掉括号。其间触及的功能问题和开发本钱也申请了延长工期。

Happy Ending ！！

血压康复 0%

血压飙升！记一次关于手机号存储的前后端谈论

附

方案规划注意事项：

  • 注意产品迁移的问题。同类型的产品，假设针对的客户集体不同，其体现形状或许彻底不一样，产品迁移过程中，要提早分分出新产品的业务场景的差异，做好危险分析。
  • 提早确认产品上下流生态，做好危险管控。比方下发侧有 API 对接的，需了解其 API 文档与运用束缚，并在服务不可用时规划告警方案等。