关于前后端接口的可扩展性思考

Posted 2022-11-01 zcube

在写ios和android客户端程序，尤其是涉及到和后端对接口的时候，大家通常会针对下面三个问题引发一些争论：

• 不能写死
• 容错能力
• 过度设计

之所以会争论，是因为这三点很多时候是对的，但是如果不分情况和场合的应用就会出现一些扩展性的问题。

不能写死

不能写死，比如这个边框颜色写死到客户端还是后台下发。下面这张图红框标注的叫外置筛选项。

在7.6版本的时候这个框和文字都是绿色的，选中态和未选中态的颜色是由后端控制。7.7的时候设计改为了蓝色，而且右下角加了个小对勾。这时候该怎么办，让后台做版本控制只在7.7下发蓝色的UI颜色，但是前端依然需要改变组件，在右下角加小对勾图标。要知道绿色在之前连续3个版本都没有改变过。那后台下发颜色达到灵活控制的意义是什么？不能写死，是真的死吗？这个值得思考下。

做客户端需求时候，由死到活目前有三种方式：写死-》后端控制-》i版Hybrid。当然还有RN动态化之类技术，目前在公司用的不多。往往要不要用i版一经确定，没有什么好争论的。但是要不要写死，却需要理智判断。首先“死”不是真死，因为每个迭代周期都可以赋予它新的生命。所以在决定要不要写死的时候，要从下面两个方面判断：

• 变化频率：需要问下这个是否根据业务逻辑实时变化，比如上面的按钮就不需要变化。
• 是否界面：如果是设计的UI界面，通常将切图直接放在客户端。如果需要根据业务逻辑更新界面，比如标签，尽量让后台直接下发切图链接，而不是描述性的界面数据，因为描述性的界面可扩展性不强，例如边框颜色数据可以用背景图片链接。

容错能力

容错能力，客户端同学往往感觉不能相信后端数据，万一不符合预期，客户端也能正常显示。但是也得从易变和不易变区分考虑：

• 易变：是否为产品需求逻辑，这个是易变的，所以客户端不需要保证。
• 不易变：接口字段类型，ID类型，这个是不易变的，需要校验。

客户端要保证的是在出错时候不要给用户很不好的体验就好了，比如crash。往往后端数据出错属于线上故障，发现后应该立即修复，互联网公司app大多为展示型app，所以如果后端出问题，客户端是没有可能容错的。如果产品逻辑也容错的话，就会造成扩展性降低。

比如下图产品要求显示3个cell，如果不够3个就不展示，假如后端下发2条或4条，客户端要不要展示呢？

下面的对话是两个客户端同学的对话：

• A：这块逻辑后端会控制，咱们以有无下发对应模块的数据进行显示判断就好了。
• B：这样不行吧，那假设后端下个了 1个，你也显示啊。
• A：如果一个后端就不会下发数据。
• B：我是考虑如果后端出错，返回不符合逻辑的数据的时候客户端应该如何处理，客户端应该有容错的能力，不能单纯靠后台保证。
• A：那产品要改为下发 2个 或 4个 呢？
• B：那就把 bug 果断的转给 PM吧！

B的容错想法非常好，但是如果进行逻辑容错反而会造成扩展性的降低。因为显示3个是产品的决策，客户端没有必要为产品的决策去容错。因为人的决策往往不一定是对的，而且常常会进行调整。在开发展示型客户端时候，大规模依赖后端数据进行展示，要做到的容错也仅仅是不crash就好。至于数据的对错，交给后端同学进行逻辑判断和过滤。

过度设计

过度设计，客户端同学和产品同学，往往考虑的情况会太多，陷入细节不可自拔。比如之前需求讨论过一个定位刷新问题：如果用户打开app，走了一段距离位置变了，我们应该怎么处理；如果用户没杀掉app从海淀到了朝阳，位置变了又打开应用应该怎么处理。其实有很多场景是概率极低的，即使有这种情况，其实也可以忽略。

怎样避免过度设计和过犹不及的情况，可以从以下两个方面考虑：

• 是否必须：如果不特殊处理会不会对用户造成损失和非常不好的体验。

• 场景概率：这种概率有多大，是不是会经常出现。

过度设计这个很难界定，一般当写代码时候需要很奇怪的各种判断时候，就需要考虑考虑是不是存在过度设计情况了。因为过度设计添加的各种判断，往往会增加代码的复杂度和降低代码的可扩展性。

一般符合好的设计，程序实现也比较容易，不好的设计，程序设计需要很多奇怪判断。所以RD也要多思考简单优雅的逻辑供产品同学参考，而不是两耳不闻产品事，一心只写我代码。