目前实时数仓提供的投放实时指标优先级别越来越重要，不再是单独的报表展示等功能，特别是提供给下游规则引擎的相关数据，直接对投放运营的广告投放产生直接影响，数据延迟或者异常均可能产生直接或者间接的资产损失。

本文主要分享了流程图和时序图绘制的一些小Tips，因篇幅有限其他UML图在后续的文章再做补充。我们倡导规范且有逻辑地画图，这对读者是非常友好的，便于其快速熟悉业务流程，并理解实现思路。

随着得物业务规模的不断增加，推荐业务也越来越复杂，对推荐系统也提出了更高的要求。我们于2022年下半年启动了DGraph的研发，DGraph是一个C++项目，目标是打造一个高效易用的推荐引擎。

商家后台前端代码目前代码量达到十万级，每个迭代团队需要在同一仓库中迭代几十个需求，在日渐庞大的巨石应用下如此活跃的迭代，开发效率与构建效率上给我们带来了一些挑战。

得物提供大量商品买卖等服务，资金流转量大，任何由于设计缺陷、系统缺陷、系统故障、人为操作、安全漏洞等因素都会引发直接或间接资金损失。资损防控就是在项目全生命周期内，引入多种资金分析和控制手段，预防资损故障或控制资损故障影响范围。

随着公司业务的快速发展，流量越来越大，网关迭代的业务逻辑越来越多，以及安全审计需求的不断升级和稳定性需求的提高；SCG在以下几个方面逐步暴露了一系列的问题。

订单的履约之路就是从发货开始，看似简单的发货功能，其背后却藏着许多的小秘密。

发货的业务特点：

• B端业务，性能要求不高，因为存在批量发货的场景。
• 发货时间比较分散，所以并发量不大。
• 业务复杂，涉及到N种订单类型的发货，不同的订单类型有着不同的业务规则。

随着公司业务的发展，订单类型的增多，没有进行抽象的发货逻辑随着迭代的推进难免会显得落后。当然，在迭代的过程中，也一直在优化，一直在演进，正所谓没有最好，只有符合当前业务现状的最合理。

Flutter虽然火了很久，但是大家对Flutter代码静态检查原理与应用依然有很多大大小小的问题，在Flutter开发中就存在一些大家都会遇到普适性的问题。

随着业务的发展，组织规模的扩大，越来越多的企业开始意识到协作效率对于企业团队的重要性，甚至是决定其在某个行业竞争中突围的关键，是企业长久生存的根本。

作为客服域访问量最大的页面之一，订单详情页在客服的日常工作中被用来查阅用户的订单信息，以此为进线的买卖家用户提供更好的购买服务，进而提升用户的满意度。

越来越多不同类型的需求开始用自动化测试左移来实践，在实践过程中也有了新的提效诉求。这类需求会期望不同染色环境在相同的配置条件下，拆分后的代码和基准release代码的接口响应response有全量对比结果才能更好达到需求验证点。

词分发平台通过架构改造，稳定性的升级，使得平台具备灵活、可拓展的场景接入方案，协助业务实现个性化的需求定制，在更多、更广泛的场景和业务域中充分发挥平台的应用优势。

包体积优化中，资源优化一般都是首要且容易有成效的优化方向。资源优化是通过优化APK中的资源项来优化包体积，本文我们会介绍得物App在资源优化上做的一些实践。

本文主要对于git sparse checkout 的原理和在其之上的应用——大仓按需拉取cli 和 vscode 按需拉取插件展开讲解。当下的按需检出实现方案可能不是最终极的解决办法，后面还会继续迭代和优化。

本文通过重点渠道举例的方式，逐渐给大家展开权益投放的故事，包括我们支持的权益投放业务，我们是如何设计的，未来在权益投放方面我们有哪些发展演化方向，同时期待能和大家一起有更多的交流。

随着得物App的用户流量增长，业务选择数据库越来越多样化，异构数据源之间的数据同步需求也逐渐增多。为了控制成本并更好地支持业务发展，我们决定自建DTS平台。本文主要从技术选型、能力支持与演化的角度出发，分享在DTS平台升级过程中获得的经验。