本文分享了在工作中关于 ElasticSearch 的一些使用建议。和其他更偏向手册化更注重结论的文章不同，本文将一定程度上阐述部分建议背后的原理及使用姿势参考，避免流于表面，只知其然而不知其所以然。如有不当的地方，欢迎指正！
测试左移这个测试方法已经出现很久了，但收益如何，收益如何体现，在不同的团队如何实施起来，现阶段在质量平台还暂未标准化和统一化。测试人员来实施测试左移，则需要测试人员具备业务分析能力，能做一定的业务分析，能看懂业务架构和技术架构，甚至具备代码查看和编码能力，能分析代码逻辑等。 在QA方面，测试自动化是一种行之有效的方法，可以让业务测试更加便捷，减少任何形式重复劳作和返工测试，提高轮次测试执行效率。目前自动化已在迭代应用中进入收益阶段，不仅在回归阶段代替手工回归测试，将自动化作用价值体现最大，也让自动化提前介入需求测试分析中，做到“测试左移”。 今年第一季度团队已提前试点“测试左移”，将自动化提前纳入需求测试分析阶段，在研发提测节点按需完成自动化左移。但是光从口头上说“测试左移”，也不能印证自动化左移的数据，以及左移带来的实际收益和价值，现阶段平台侧将 RDC(Research and Development Collaboration / 研发协同平台，得物技术部自研的一套项目管理工具）、协同面板、流水线、用例平台、自动化平台五方联合，共同搭建出测试左移的全链路操作。
前端 monorepo 在试行大仓研发流程过程中，已经包含了多个业务域的应用、共享组件库、工具函数等多种静态资源，在实现包括代码共享、依赖管理的便捷性以及更好的团队协作的时候，也面临大仓代码文件权限的问题。如何让不同业务域的研发能够顺畅的在大仓模式下开发，离不开有效的权限管理方法。好的权限管理方法能够确保研发同学轻松找到和理解项目的不同部分，而不受混乱或不必要的复杂性的影响，并且也应该允许研发同学合作并同时工作，同时也要确保代码合并的更改经过代码审查，以维护代码的质量和稳定性。本文通过实践过程中遇到的一些问题以及逐步沉淀下来的最佳实践，来阐述下前端大仓 monorepo 在权限这块是如何思考以及设计的。
应用连接数据库基本上都是通过连接池去连接，比如常用的 HikariCP、Druid 等，在应用运行期间经常会出现获取连接很慢的场景，大多数同学都是一头雾水，不知道从哪下手。而且很多时候都是偶发场景，让人头疼不已，别着急，本文带你逐步剖析获取连接慢的所有可能的原因，以及对应的调优手段，让你成为连接池排障大师。
得物大模型训练与推理平台上线几个月后，我们与公司内部超过 10 个业务领域展开了全面的合作。在一些关键业务指标方面，取得了显著的成效，例如： 效率相关部门的合作，多维度打标总正确率取得 2 倍以上提升。利用大模型开辟了新的业务，提升了效率部门的人力产出。 某业务订单 NPS 的识别准确率由 70% (PROMPT 方式)提升到 85% (平台训练大模型) 。 本文基于我们与业务合作的经验，将分享如何在大模型平台上实现业务效果指标提升。我们将以大模型平台上从训练到推理部署的全链路流程为基础，提供优化思路，最终达成业务效果指标的提升。这些流程包括大模型选择、数据准备、大模型训练、效果评估和推理部署。
由于多个域共建情况比较多，一方面应用随业务发展在不断扩展，各个应用代码复杂度会不断增加，如何准确、全面判定代码修改影响范围会越来越重要，另一方面共建过程中如果不能准确预估出各域共同改动所带来的影响面，就会存在测试遗漏；如果各域信息不对称可能会存在一方改动另外一方无感知，导致评估不到位带来一些影响。基于以上背景商家域引入精准测试平台实践，可以帮助QA扫描出每个版本开发改动的接口范围，并且可以有效地提高测试的覆盖率和可靠性。 基于第二季度在商家地址专项上探索实践了精准测试并取得了一定的收益；第三季度扩大规模化实践，因此根据商家核心业务需要，选择了核心的 4 个应用，并沉淀了持续几个迭代的过程和结果数据。以下是几个迭代下来使用精准测试平台的一些实践数据和心得。
得物效率前端所在的效率工程为提升企业协作效率而生，面临大量的 PC 侧的中后台应用场景。 在之前的微信公众号《得物效率前端微应用推进过程与思考》中详细介绍了效率前端推进微应用落地的思路和部分效果。 这篇文章将着重介绍得物效率前端微应用推进中，微前端的研发效率遇到的挑战和解决方案。
目前得物的商品分为三种类型，分别是：新品、商品、草稿。但是只有商品是可售卖的，新品和草稿都不是可售卖的。 新品有很多种创建的渠道，商品可以由新品选品通过后由系统自动生成，也可以由运营直接创建。而商品草稿是在商品被编辑后创建而来，草稿在更新审核通过后，会重新覆盖已有的商品信息。
