在创业初期，只有几个人的研发团队往往展现出“十倍程序员”的高效与灵活，但当公司规模扩大、代码量激增，研发效率和产品质量却面临严峻挑战。为应对这些问题，涛思数据在2024年10月重组了最重要的资产——研发部门，并提出“一切都要代码化”的核心原则。本次演讲将结合公司内部实践，深入剖析从环境配置、CI/CD 流程到文档与测试用例管理的关键痛点，并阐述如何通过将环境、流程、文档、基础设施全面纳入版本管理和自动化体系，显著提升协作效率与产品质量。

借助“一切都要代码化”，研发人员得以摆脱大量重复性、依赖个人经验的操作，不论是新入职环境配置还是现场快速交付修复版本，都能“一键”完成。在此过程中，文档与测试用例也实现了同步更新与分类，让协作更加透明、质量更加可控。最终，通过更高效的研发模式，团队能够释放更多精力专注于创新与产品竞争力的提升。

演讲提纲

1. 问题背景

• 以涛思数据公司研发部门重组的背景出发，提出“一切都要代码化”的原则及其重要性。

2. 研发效率低下的典型场景

• 现场解决BUG后，因环境依赖无法快速交付新版本
• 新入职研发人员需花费大量时间熟悉开发环境
• CI/CD系统效率低，测试流程耗时长
• 测试例与文档脱节，覆盖率不足
• 测试资源协调困难，需人工开会协调

3. 效率低下的根本原因

• 工作难以重复，依赖个人经验
• 工具、工作流管理代码未纳入版本管理
• 文档与代码脱节，用户手册更新滞后
• 计算、网络资源管理原始，依赖人工

4. 一切都需要代码化

• Environment as code：开发、测试环境自动化部署
• Pipeline as code：CI/CD工作流代码化，纳入版本管理
• Documentation as code：文档代码化，自动生成测试例列表等
• Benchmark as code：对比测试代码化，减少环境依赖
• Infrastructure as code：计算资源分配自动化，虚拟化管理

5. 代码后的效果

• 本地快速打包与发布，提高 BUG 修复效率
• 性能测试便捷性
• 新人快速上手，降低文档依赖性
• 版本透明度提升
• 资源申请便捷化

6. 总结

• 强调“公开、透明”文化和“实事求是”工作原则
• 代码化提升效率，促进团队积累，增强产品竞争力

您认为，这样的技术在实践过程中有哪些痛点？

在实际的实施过程中由于团队规模原因还是会有一些阻力和与预期偏差的结果，作为企业领导者需要在规则执行过程中不断纠偏，以达成预期目标。

听众收益

1. 了解 TDengine 研发部门重组的痛点及实践经验。
2. 了解“代码化”对研发效率和团队协作的提升。

企业架构作为一门管理科学，得到越来越多的企业重视，很多大型企业基于企业架构思想指导实施数字化转型取得了一定的成效，然而传统企架思维和方法持续时间长，投入大，后期维护成本高，让不少中型企业望而却步。

随着企业架构在各个行业的持续推进和建设，伴随着生成式AI和智能体AI的演进和在各行业的持续运用，大、中型企业如何抓住AI时代红利实现弯道超车或者继续扩大竞争优势，成为企业架构从业者和管理层要考虑的问题。演讲者结合自身实践提出企业架构2.0思维，由传统面向单个企业建设其企业架构，到基于行业参考架构建设企业架构，结合行业的领域专有AI模型，可以助力企业架构师建设开放、标准、智能、符合行业最佳实践的企业架构，以实现智能体AI时代超越企业边界的低成本无界信息流。

演讲提纲

1. 传统企业架构思维和建设方法
2. 传统企架面临的困难和挑战
3. AI时代的企业架构2.0思维

• 基于行业参考架构模型
• 业务架构构建块作为价值锚点
• 设计思维打造场景产品
• 平台化架构和规模化敏捷组织
• AI全方位赋能

4. 如何制定和使用行业参考架构标准（以银行业为例）
5. 行业领域专有AI模型

您认为，这样的技术在实践过程中有哪些痛点？

1. 架构思维和实践处于不断演进中，可能总结得不够完善
2. AI在企业架构中的运用还处在开始阶段，只描述可预见的影响

听众收益

• 了解企业架构新的发展趋势
• 了解生成式AI和智能体对企业架构思维和方法的影响

随着业务系统规模和复杂度的持续增长，一线业务开发者需要耗费大量精力应对复杂业务逻辑的实现和臃肿系统的维护，而晦涩的代码、模糊的数据协议和残缺的项目文档更是加重了开发者的认知负荷。为此，作为一门以提升开发体验与交付效率为根本目标的学科，平台工程不应止步于 CI/CD等研发工具链的实施，而应上提到代码层面，通过提供贴近业务的标准化开发框架引导开发者构建出敏捷、易维护、可演进的平台架构，简化系统开发复杂度，助力业务知识传承，提升团队研发效能。

本次分享介绍了京东广告投放团队面向复杂B端业务推出的一种标准化平台开发框架，详细阐述了该框架适用的业务场景、要解决的问题、底层方法论及具体的落地措施，希望给面临相同困境的业务开发团队提供问题解决思路和方案参考。

演讲提纲
1 传统架构的研发痛点

• 客观：过于粗放的封装在实现高复杂度业务时毫无章法
• 主观：“面向数据库编程”的设计思想让系统加速腐化

2 构建面向B端复杂业务的标准化敏捷架构

• 2.1 架构指导思想与框架设计原则
  • 正交分解：复杂业务逻辑模块化拆解与标准化封装
  • 业务与技术分离：通用技术组件全面托管，实现标准化、填空式开发
  • 业务、数据、存储模型三分离：存储模型支持灵活可拓展、数据模型强调直观可理解
  • 代码即文档：将代码工程本身作为业务知识库，保障业务知识全面、准确、即时地传承
• 2.2 PICASO：一种基于上下文的能力拆分与编排框架
  • 框架综述
  • 通用可执行实体发现与路由机制
  • 标准上下文机制
  • 基于DSL的能力编排执行引擎
  • 聚合与资源库
  • 分布式可重试事件总线

3 落地实践与效果收益

• 基于PICASO框架的平台开发流程速览
• 落地案例与效果收益

4 当前存在的痛点问题与解决措施
5 下阶段规划与未来展望

您认为，这样的技术在实践过程中有哪些痛点？

• 实施痛点：设计思想转变成本、框架API学习成本、系统重构阶段人力投入成本较高
• 应用痛点：编码强依赖业务建模，增加了设计成本，实际收益在很大程度上受制于业务建模质量
• 技术痛点：逻辑模块化拆解导致代码中实体数量膨胀，JVM元空间内存占用增加、服务启动速度承压

演讲亮点

• 从抽象方法论到落地措施详细地介绍了一种面向B端复杂业务的平台构建框架
• 以领域驱动设计作为思想内核，但并不拘泥于DDD中的各类概念，所有组件均以实用为第一原则，紧密结合业务实际进行设计

听众收益

• 了解到一种贴近业务的平台工程实践新思路
• 获得一种可复用的、面向复杂B端业务的标准化平台架构方法论与落地框架
• 整体方案中的局部设计理念，如上下文机制、业务-数据-存储三分离等，无需引入框架也可在自己业务系统中实践应用