简介：技术团队的素质水平不仅影响用户体验和业务成果，还与团队的研发效率和技术氛围密切相关。有赞的移动端受线下门店场景特殊性影响，需要支持硬件能力较为有限的本地离线计算和收银设备。这也对移动终端质量体系建设提出了更高、更严格的要求。在探索移动质量提升的过程中，我们积累了一些思路和方法论。

品质稳定是技术团队的基础

在技​​术团队中，相信大家都熟悉质量这个话题。以有赞的业务为例。无论是业务的交易环节还是流量导流环节出现质量问题，无论是启动时的死机还是耗时过长的性能问题，都会给我们服务的商户带来问题。运营效率低下和GMV损失导致商家对有赞的技术能力产生质疑和抱怨，最终影响了有赞SaaS服务的续订率。

但事实上，质量不好不仅会对业务和商家造成影响，对技术团队本身的影响也不容小觑。

有赞移动团队也经历了从0到1在线快速迭代功能而对代码质量重视不够的阶段。这些陷阱导致业务在快速扩张的过程中出现了大量的线上问题和故障。线上问题的频繁出现会让整个团队陷入效率的恶性循环：处理线上问题会打断正在进行的项目的进度。严重的时候，很多开发同学甚至要花一整天的时间忙着处理线上的问题。 ，直到晚上才有时间开始补今天的开发进度。这种情况下，不仅会出现超时、延迟等显性影响，更严重的影响还会是技术方案考虑不周、代码不精炼等隐性影响，这会进一步降低线上代码的质量。这样的恶性循环，也会让整个团队忙于救火，让技术积累和氛围更加无从谈起。

质量差给技术团队造成恶性循环

所以我们深深的感受到，对于一个技术团队来说，品质和稳定性其实才是团队的基础。在良好品质的基础上，我们可以更好地追求业务支持和推广、研发效率提升、团队技术氛围等其他目标。

有赞移动质量要求特点

在不同类型的业务场景下，对移动终端的要求也会有不同的优先级。一些具有金融背景的企业会对应用安全性有更高的要求，而另一些具有电子商务背景的企业可能对动态能力有更高的要求。技术团队质量工作的方向和重点与业务特点密切相关。

那么有赞的业务场景对移动终端有哪些要求呢？我们总结为以下两个突出特点：

1、线下业务能力

对于市场上的大多数应用程序来说，当用户在移动应用程序下订单时，移动端通常只负责信息显示和用户交互。订单金额的营销计算（例如某款产品是否可以使用优惠券减价、某款产品是否满足成为订单赠品的条件）、数据验证、订单生成等敏感业务逻辑留下了。结束处理。

但在有赞门店业务场景中，我们为门店收银员开发的收银终端高清应用需要提供线下计费能力。

这是因为卖场场景面对的是来到卖场的顾客和真正在收银台前等待付款的消费者。该场景要求收银系统在面临网络断线或服务器宕机的挑战时具备本地收银能力。如果来到商店的消费者因为收银系统卡顿而离开商店，商家将遭受巨大损失。

门店场景收银高清应用

本地进行营销计算和订单生成的要求，不仅对移动终端的本地数据缓存能力、数据变化的及时性、逻辑复杂度、数据安全性提出了更高的要求，而且在质量保证方面也带来了两个挑战：

营销计算中的资金损失风险：如果移动端只负责订单创建过程中的信息展示和用户点击操作，那么由于移动端自身的bug而导致资金损失风险的概率极低。然而，当商品的折扣计算、折扣分享、分组拆包、折扣叠加、互斥逻辑全部本地化到移动端时，编码bug导致订单金额计算不正确，进而导致订单金额急剧下降。商家或消费者赔钱的可能性增加。 。例如，如果某个产品没有纳入商家的限时折扣活动，但该产品由于bug而打折出售，就会给商家造成经济损失。资金损失故障非常严重。这就要求我们有更严格的机制来保证核心代码的L0稳定性。

及时修复问题的能力：当线上问题可能涉及资产损失时，会对移动端的问题修复能力提出更高的要求。

在问题及时修复方面，移动端相比前后端有着天然的劣势。当后端或者前端同学发现线上问题时，可以通过回滚的方式在几分钟内止血。但不可能每个终端都在移动端卸载并重新安装旧版本。同时，市场上的热修复方法也存在很多局限性。这迫使我们更加深入地思考，探索问题修复过程中的每一个环节，以便在问题发生时迅速止血，减少影响。

2、硬件水平有限

在商店场景中，我们为商店收银员提供的高清应用程序版本运行在收银机上。关于收银机的硬件能力，我们可以通过简单的对比来感受一下：

我们抛开CPU性能等其他因素，但在考虑内存时却存在巨大差距。有限的内存容量要求我们移动技术学生不仅在编码和技术方案设计阶段对性能方面有更细致的考虑和设计，也要求我们对在线应用性能滞后有更强的分析和解决能力。 。

有赞移动品质提升的探索与实践

结合上述有赞业务场景的需求，我们围绕以下命题来思考和探索如何提升移动质量：

我们将探索过程中的经验总结为以下几点：

1、主动发现问题

我们曾经经历过一个线上资产丢失失败的案例，由于场景实际触发频率较低，在测试过程中被漏掉了。这个bug是在6月6日发布的，但直到7月10日有商家举报案例，我们才发现这个涉及资金损失的问题。这件事引发了我们的反思。对于核心业务环节的异常行为，难道只能靠用户举报吗？

天网数据报警平台

事实上，主动发现问题、解决问题对于流动学生来说并不陌生。即使在建立初期，移动团队也会通过一些第三方平台对每个上线版本进行监控和分析。平台是主动发现问题、解决问题的表现。那么我们能否主动报告、主动发现、主动修复业务流程中的问题呢？答案一定是肯定的。

因此，我们搭建了天网报警平台，目的是达到对核心业务环节异常情况进行报告、分析、跟踪的同样效果。一个分析平台通常具备以下能力：问题报告、数据聚合、任务分配、版本过滤、上下文信息等。我们的天网平台也提供了同样完整的能力：

在搭建了完整的平台能力之后，我们也知道，整个系统的有效运行，深度依赖于商科学生对业务流程关键环节的主动分析和洞察。只有丰富的业务洞察才能让这个系统真正发挥作用。主动业务防控是有效的，因此我们也总结了适合主动业务埋点的最佳实践：

以下是 警报的示例。收银员操作订单时，移动终端上报给后端的计费参数会包含以下信息：

我们曾经遇到的一个bug是，在一个大型项目的改造过程中，调用后端API传递参数时，没有传递选定的会员卡号。在这种场景下，当这张会员卡设置为发放多张积分时，会导致该订单最终发放的积分不正确。在这个场景中，我们添加主动验证参数：当计费参数中的营销信息中有会员卡折扣，但会员信息中没有卡信息时，很可能是开发中出现了Bug。通过这种内部参数交叉检查，我们可以主动报告。

事实上，一年后的一次重构过程中，开发同学居然又犯了同样的错误，而天网报警提供的信息这次对我们帮助很大。

目前，我们已在核心业务环节预埋了数百个报警点，并对线上问题进行了多次真实预警，让我们能够第一时间主动修复。

2. 及早发现问题

看完上一篇文章，有细心的同学可能会问：如果问题报警了，为什么要等到上线才处理呢？能否在上线前解决问题？

回归阶段

答案当然是肯定的。有赞的移动端发布采用的是发布车机制。每周一我们会将通过测试验收的所需代码发送到dev分支打印出“高铁包”供测试学员返回，并配合自动化测试返回核心流程。验收后，高铁方案将于下周一投放市场。高铁本周是回归、发现问题的最佳时机。

因此，我们将分析警报和天网业务警报的范围扩大到回归阶段。高铁阶段出现的问题也会主动触发警报。过去一年，两个平台在上线前主动报告bug方面都取得了很多立功成果。

发展阶段

回归阶段的警报并不是我们思考的结束。核心环节问题能否更早发现并解决？在开发阶段，甚至方案设计阶段，是否有机会将一些线上问题消灭在萌芽状态？

我们针对最终可能出现资金损失的地方设计了单元测试，并将单测的运行与CI流程连接起来，这样代码提交时就可以直接通过单测检查。

那么什么样的代码适合编写单元测试呢？

经过讨论，我们将范围缩小到两种场景：移动端重新建模和生成计算。各个业务领域的同学通过整理，产生了自己的单一测试用例。

项目设计阶段

还有比开发阶段更早的时间吗？能否在项目开发前主动预防？我们设计了移动端的行为验证机制

行为检查

所谓行为验证，就是对用户的操作行为和数据进行交叉核对。这种验证可以增加一个新的维度来防止bug的发生。

我们还是以上面提到的订单参数中忘记传递会员卡信息的bug为例。这里选择卡的操作是由客户端用户点击触发的。那么用户选择卡的操作就意味着最终的计费参数应该包括会员资格。卡交叉检查站。

这种验证逻辑对于我们来说就是一个“验证规则”。我们开发了行为验证的底层SDK，就是在核心计费业务环节添加整个流程的用户操作行为以及最终的订单数据。一个维度保护业务，避免开发过程中出现低级错误的可能性，提前引入bug。

类似规则的例子有很多。比如线上订单收款成功之前，支付接口必须已经调用成功，可以用来防止部分同学出现页面跳转的bug；

目前我们的行为验证已经在核心业务环节承载了多重规则，大大降低了资产损坏失败的可能性。

问题的发现和解决贯穿整个研发过程

3、有效的流程机制支撑

虽然我们有多种工具平台可以报警、及时发现问题，但这能提高质量吗？在实践中，我们深刻认识到工具只有在高效、合理的流程机制的支撑下才能真正发挥其威力。

在平台建设初期，在线及数据验证报警平台缺乏报警时的策略，没有与AT负责人在报警频率上收敛。这样一来，如果单个设备出现小问题，机器人就会在群内短时间发出警报。为每个人提供数百条警报消息。这种“狼来了”的警报只会让大家关闭群消息提示或者关闭奇伟通知。

不知道如何克制自己就报警就等于不报警。

因此，我们反复优化报警策略。本着“凡是报告的问题都需要立即响应，不需要立即响应的就不报告”的原则，我们沉淀了一系列的报警策略。详情请参考之前公众号文章。相关章节。

除了报警策略之外，我们其他的流程规范积累都在Code链接中。

在我们团队质量问题最严重的时期，我们扭转被动局面的核心方法就是强化Code​​。但CR要真正发挥作用而不仅仅是流于形式，很大程度上依赖良好的流程机制来支撑。在加强和实施CR的过程中，我们面临以下挑战：

CR流程中的沟通成本

我们认识到CR流程必须通过流程标准化来提高效率，减少对开发学生的干扰和负担，让大家真正能够高质量地投入CR并互相保护。

最后，我们推出了一个机制，通过以下机制来解决上述挑战：

我们在2020年6月推出这个机制后，团队的线上问题数量立即得到了有效控制。那一年的第三季度，我们很快将线上问题数量减少到之前的1/3，并在此后很长一段时间内保持了非常低的线上问题率。

近两年移动团队在线问题趋势

有了有效的流程机制，工具能力才能真正发挥作用。

4.注重绩效

前面也提到了有赞移动的性能挑战。我们针对绩效问题的行动包括以下三个方面：

可用性、性能和流程规范共同构成移动质量构建矩阵

质量改进的结果

两年来我们对品质的深耕和探索，也给我们带来了丰硕的成果。这个成绩不仅体现在我们月均在线提问数上，也体现在我们持续的技术输出上。当技术生救火的次数减少时，他们就有更多的时间主动出击，建立系统的体系来预防线上问题的发生。预防机制可以进一步降低线上出现问题的概率，形成良性循环。这无论对于团队，对于培养同学的个人成长都是非常有帮助的。

近两年来，有赞移动团队就制作了多篇关于品质建设的公众号文章。每一篇文章的背后都是技术同学的积累和沉淀：

终于

本文提到的有赞移动质量提升和实践的过程，实际上在一定程度上代表了我们团队的工作作风。在处理有赞业务场景的过程中，我们会遇到线下收银、深度性能优化等具有挑战性且有趣的技术问题。面对这些挑战和问题，我们将主动出击，寻求系统的解决方案。这些解决方案往往涉及到后端服务和前端页面的工作，以及面向产品的思维。在这个过程中，我们的流动学生无限制地扩展了他们的技能，最终形成了一种给人成就感的技术。沉淀。

我们也非常期待并欢迎更多喜欢这种工作方式的同学加入有赞移动大家庭。