转转推送系统（后面简称系统）在早期设计中主要考虑了三个核心指标：

• 吞吐量：指系统在单位时间内能够发送多少消息的能力。
• 扩展性：指系统在快速支持更多APP主体、发送策略、发送通道、通道策略等能力上的难易程度。
• 性能：指系统API的接口耗时。

为了同时满足三个核心指标，我们在系统中大量采用了异步、并发、批量等设计。这些设计虽然很好满足了系统设计指标，但是同时也给系统带来了较高的复杂度，再加之一些环境因素（如测试环境的不稳定），导致业务方（指系统使用方）在接入测试中经常需要系统人员协助定位问题，这种状况既降低了业务方的开发效率又增加了系统的维护成本。

为了解决业务方的接入测试问题，在之后的系统演进中我们又增加了第四个指标：易测性，希望通过这个指标来提高系统的可测试性和降低系统测试成本。本文将重点讲述我们在系统易测性指标上的一些设计经验供大家参考。

瀑布流是大家日常开发过程中经常遇到的一个场景，我们公司内部的组件库中也提供了一些解决方案。但这些方案适用场景都很单一，且每个实现方案都或多或少存在一些问题，基于此，我们设计与开发了一个兼容多场景的瀑布流组件。

公司现在访问测试环境方式，使用线上域名，本地配置host，通过host控制访问不同的环境。这种使用方式，存在诸多问题，比如：

• 忘修改host，或浏览器存在socket缓存，host没生效。会访问更改线上数据，风险大。
• 需要频繁配置修改host，产品，运营，测试在测试环境作业中效率较低。
• 与第三方联调时，每次更换测试环境，都需要运维同学更改nginx配置。

如何将游戏类运营活动赋予新的玩法，打破老套运营方式给予用户新鲜感？

本文旨在为大家提供 Fair 在实际项目中落地的完整案例，包含了使用 Fair 进行动态页面改造、复杂场景使用、接入过程中遇到的问题、Fair 接入前后的性能对比、热更新方案设计等等内容。

我们在 Vue2编写组件的时候，会在 props、data、methods、computed 等 options 中定义一些变量。在组件初始化阶段，Vue内部会处理这些 options，即把定义的变量添加到了组件实例上。等模板编译成 render 函数的时候，内部通过 with(this){} 的语法去访问在组件实例中的变量。

那么到了 Vue3，新出现的setup启动函数，是整个组件逻辑组织的入口，我们可以在它内部写composition-api，以更加直观的形式声明变量，有利于代码的逻辑组织和复用，但是我们要明确一点，composition-api 属于 api 的增强，它并不是 Vue3 组件开发的范式，如果组件足够简单，还是可以使用 options-api，在了解了 composition-api的应用场景和使用方式后，我们需要进一步思考，setup启动函数是如何执行的，它所返回的数据又是如何与模板建立联系的？

高效率、低成本，一种快速上手的流量回放方法。

又到了每年晋升述职的时间，在过去的 5、6 年里，我以评委身份参与了大量的晋升述职（主要是前端，也包括客户端和测试），也辅导了许多（100+）组内外的同学，指导他们书写和完善 PPT。过程中我发现大家有许多共性的问题，这些问题导致了某些同学，明明有 80 分的能力，却让评委觉得只有 60 分。而有些掌握了晋升技巧的同学，同样 80 分的能力却能给评委 90 分以上的感觉。

后来，基于这些共性的问题，我制作了一个 晋升述职PPT模板，把晋升述职相关的注意点，包括述职准备、内容结构、表达技巧、规划重点等都集成到了这个 PPT 模板中。因为准备 PPT 是晋升述职的核心工作，所以把需要注意的点都融入到 PPT 里面后，在写 PPT 的同时就能融汇贯通起来。

转转支付中心与多家第三方支付平台、金融机构存在合作，例如微信、支付宝、分期乐、合利宝、平安银行等。

在收单、打款、退款等业务上，大部分接口都需要通过HTTP协议与第三方进行交互。

目前业界上或转转内部都有封装好HttpUtil工具类提供使用，但开发人员在接入三方渠道时，不同渠道方提供的文档有所差异且内部研发人员变动等原因，实现时自然会存在一些问题：

• 缺少统一的设计流程，代码复杂臃肿、耦合度高
• 开发人员水平参差不齐，不同人的设计风格千差万别
• 抽象程度不够，复用性较低

由此，支付中心研发了统一设计风格、注解式的HTTP客户端，建立一套面向“使用HTTP协议与三方渠道交互“的“设计规约”。

如何实现一个像“蓝湖”那样的标注功能，这篇文章带着你一步步的去揭秘关键性的技术点，让你从零开始上手一个sketch标注。

DeepLink是什么？如何应用DeepLink来获客引流？

58集团作为国内领先的生活服务及分类信息平台，业务覆盖招聘、房产、汽车、二手、本地生活服务及金融等领域，各业务每天生成海量信息，对内容安全、业务违规的高效治理和处罚的需求亟需解决，本文站在中心化建设视角，阐述58集团处罚数据中心的设计与实践。

面对复杂多变的情况下， 如何能够灵活、简单、高扩展的完成业务需求？ 是否存在零代码就能完成产品需求迭代？

互联网中爬虫的进攻不曾停息。让我们跟随转转的攻城狮们，走向这硝烟弥漫的战场。

在平时的搬砖过程中，当我们拿到新需求的设计稿时，为了加快开发的速度，通常会看看是否有曾经写过的组件可以复用。如果能找到类似的组件，有很大概率可以在原有的基础上修修补补就能直接用了。

混天项目：58集团共建的Swift基础设施平台建设， 主要目的是推进集团App对Swift语言进行使用，并打造复杂工程下Swift-OC混编、编译耗时优化、包大小检测（支持Swift）等基础能力的建设。

小游戏Native化背景：梦想小镇在同城10.7.0版本前， 是由H5技术研发，优点是可以跨平台，完美支持iOS以及Andriod系统。但是，小游戏的核心业务模式是通过用户合成升级， 当达到一定等级后，给予用户现金奖励（在同城中是发放神器矿石）。但在10.9.0版本苹果审核人员明确表明此业务模式触发了4.7.7审核条款， 如果继续使用H5的技术手段，只能去掉奖励。但是如果去掉奖励的话， 也基本失去了用户玩小游戏的动力，对App的日活以及业务导流都会有比较大的影响。

基于上述同城对混编语言建设的现状， 以及苹果对H5游戏审核政策的变化，使我们坚定了用Swift语言开发游戏的新思路。