随着业务的不断发展，严选库存管理逐步形成以全渠道共享库存为大基调，兼顾供给、履约、营销等不同业务场景对锁定库存的诉求，将严选锁定库存从基础型能力逐步发展成支持复杂业务场景的策略型能力，以达成共享库存和专用库存之间的管理和平衡。

都说探索式测试非常适合敏捷项目，可如何在实际项目特别式游戏项目中真正应用好探索式测试却一直不太容易。作者结合了自己的实践以及思考，为大家很好的介绍了探索式测试。

严选基于故障处理驱动，通过监控+报警+事件总线机制的立体化协同建设探索，为微服务架构下的监控报警体系化能力演进提供更多可能。

本文结合过去一段时间云音乐数据开发团队在数仓建设、数据治理方面的具体实践，分享我们在数据治理方面的一些思路。

云音乐 iOS 启动性能优化实践，从分析 App 启动现状瓶颈到对 App 治理实践，本文介绍了云音乐 iOS 如何从动态库、+load、二进制重排、业务层面代码等各方面治理实践的过程。

想要了解异常检测、故障定位在游戏行业如何设计算法与落地效果？快进来看看吧。

互联网技术发展到今天，移动互联网仍然是一个重要的战略核心，APP也仍然是绝大多数互联网企业用户获客留存的核心渠道。

组件的核心意义是「提效」，这里的提效是指研发提效，可有效减少冗余代码、避免重复工作，提高「交付效率」，让我们能够更好更快地进行项目协作和需求开发。一个完善、高效的组件体系可以激发前端同学组件开发的热情，有利于前端物料的积累。本文将介绍网易云商组件体系建设的整体思路和实现原理。

在当前移动互联网时代，一个产品想快速、准确的抢占市场，无疑是需要产品快速迭代更新，如何协助产品经理对产品当前的数据做出最优判断是关键，这就需要客户端侧提供高精度、稳定、全链路的埋点数据。

针对动态列表问题我们使用RN进行了一下探索尝试， 利用我们已经相对完善的RN基建，结合客户端列表能力低成本的实现了一套的动态化能力，同时兼顾一定的性能体验。

严选基于故障处理驱动，通过监控平台+报警管理+事件总线机制的立体化协同建设，为监控报警的体系化能力升级提供更多可能。

网易云音乐（以下简称“云音乐”）的前端团队大概在 4 年前初具规模，4 年多的快速发展过程当中做了很多 0 到 1 的平台，造成了平台深井，比如研发的体系，部署的体系，监控的体系等，这些体系在云音乐初期快速发展中起到了非常大的作用。但是随着人员的更迭及业务不断的发展，初期各自发展的垂直体系遇到了和产品后期同样的问题，新增一个功能越来越复杂，涉及的链路越来越长，花费的代价越来越高，用户需要在各自的平台跳入跳出，会有各种各样的卡点，导致效率降低。如何串联各平台场景，打破平台深井，这是云音乐前端工程化面临的第一个挑战。

除去研发之外，所有的应用在上线前还需要经历测试和部署以及上线后的运维，但是每种应用类型在每个阶段的关注点不一样，所依赖的服务也不一样，比如 Node 应用的部署会依赖云原生，但是 H5 的应用依赖 NOS 的静态资源服务。如何使用一套架构支持不同应用类型的全生命周期发布，这是云音乐前端工程化面临的第二个挑战。

云音乐的业务从单一的播放器发展到社区生态的过程中，为了体验和效率之间的平衡，涌现了多种多样的应用形态，比如 H5 的应用、RN 的应用、中后台的应用、Node 应用等；为了一些极致的体验，在 H5 下又细分离线和闪开，RN 又细分为拆包应用。这些不同的应用类型，工程规范不一致，脚手架也不一致，导致开发同学在上手时有一定的成本，也造成了维护上的困难。如何使用一套架构去收敛这些不同的研发体系，这是云音乐前端工程化面临的第三个挑战。

本篇文章着重针对前两个挑战分享解决思路，我们也发起了一个代号为 Febase 的项目，这个项目目标是针对前端开发者，通过一站式应用研发平台，提升开发部署的效率和体验，并且降低后续应用扩展的维护成本。

本文将作者负责组内测试用例建设以来，在评审流程优化过程中的心得体会做了一个总结，希望能给大家带来帮助。

目前云音乐旗下 APP 众多，其中涉及到 RTC 业务的不在少数，例如：常见的音视频连麦、PK、派对房，1v1 聊天等。由于业务线不同，功能不同，开发者也不同，大家各写一套，不断的重复造轮子。

本篇文章介绍了在跟用户面对面测试期间，应该如何追问用户、如何保持客观。并提供了一些话术参考。

NASL是轻舟低代码平台提供给开发者的一门可视化编程语言，在此前分享中有不少人对此感到困惑，今天我们围绕NASL做一些解读，希望大家对NASL及低代码实现原理有更深入的理解。