内容《软件研发效能提升之美》之书

总论

  • 研发效能是多⼈组织协同效率的课题，在现代基础设施、架构理论和AI算法的加持下，研发效能的内容也从敏捷方法论快速进化到非常具体的⼯具、流程和指标系统

  • 研发效能定义：在保证质量的前提下，尽可能⾼效地持续交付价值。为此，我们重新审视 整个软件⽣产流程（需求、设计、开发、测试、部署、发布、运营），在不增加成本和保证质量的前提下，提升各个步骤的标准化、⾃动化、系统化和⼀致性⽔平，并不断优化团队的交付效率

  • **没有银弹：**没有任何一项技术或方法可使软件工程的生产力在十年内提高十倍

  • 希望软件研发能够成为⼀个技术密集型产业，⽽不是劳动密集型产业

  • 敏捷作为⼀种通过创造变化和响应变化在不确定和混乱的环境中取得成功的能力，具备高度的实践性和创造性，这样的特性在赋予敏捷强大适配度的同时，也给落地造成了困难

概述

  • 研发效能提升案例

    • 前端代码的自动生成

      • 我们手绘出GUI界⾯的草稿；通过Sketch2Code可以直接将这份草稿转换成目标平台的代码，如果我们指定的目标平台是Web，那么代码格式就是HTML，如果我们指定的目标平台是iOS，那么代码就以XCode项目的形式呈现；最后，完成编译打包，可直接在iPhone上安装执⾏了。

        这种方式的引入将大幅提升原型构建环节的效率

    • 临界参数下的API测试

      • 考虑引⼊⼀种机制，通过⼯具或脚本去主动检测API输入参数的类型，根据不同的类型⽣成相应的容易出错的临界值，我们⽤这些临界值作为测试数据去⾃动调⽤API。如果API返回预期外的异常或错误（如HTTP-500错误），那就说明这个API没有妥善处理我们传⼊的临界值

        进⼀步的，我们可以将这个机制与CI流水线集成，在CI执行走过程中主动执⾏临界参数下的API测试，以求问题更早地被暴露

      • 例如：当⼯具或脚本识别到某API的输⼊参数是String类型的时候，就可以⽣成NULL、超⻓的字符串、包含⾮英语字符的字符串、SQL注⼊字符串等⼀系列临界值，将其作为测试数据去检测程序潜在的问题

    • 基于流程优化的效能提升

      • 效率的提升既可以由技术来驱动，也可以由流程来驱动，流程要整体方便

  • 第一性原理：顺畅、高质量地持续交付有效价值的闭环

    • 顺畅：价值的流动过程必须顺畅，没有阻碍 高质量：如果质量不行，那么流动越快，死得也会越快 **持续：**不能时断时续，小步快跑才是正道 **有效价值：**这是从需求层⾯来说的，你的交付物是不是真正解决了用户的本质问题 **闭环：**强调快速反馈的重要性
    • 鹅生金蛋的故事。是不是鹅生的金蛋越多，效能就越高呢？其实不是，⼀味地让 鹅全日无休地生金蛋，早晚会把鹅累死，这不是可持续的长远战略。真正的效能应该是让鹅生鹅，鹅再生鹅，让更多的鹅⼀起来下金蛋

  • 从软件开发、测试和发布的视角来看⼀下各个阶段研发效能提升需要关注的问题，其主线是围绕CI/CD的⼀些实践

    image-20250301214927395

    举例：选择合适的发布策略也会对效能和风险之间的平衡起到积极的作⽤

    • 架构相对简单，但是集群规模庞大，则优选金丝雀
    • 架构⽐较复杂，但是集群规模不是太大，可能蓝绿发布更占优势

  • 研发效能这个领域，要保证我们所做的研发效能工具⼀定是能解决实际问题的

  • 研发效能提升实践：

    • 找钉子，场景举例：

      • 本地编译耗时长：提供增量编译和分布式编译能力
      • 本地测试困难，测试环境准备复杂且耗时长：基于Kubernetes的Pod提供⼀键搭建测试环境的能力
      • 自动化测试用例数量大，执行回归时间过长：采用并发测试用例执行机制，使用几百、几千台测试执行机并行执行用例，实现用硬件资源换时间
      • 自动化测试用例维护成本高：测试用例采用模块化和分层体系，实现低成本的自动化用例维护
      • 测试数据准备困难：引入统⼀的测试数据服务（Test DataService）能力
      • 集群规模庞大，发布过程耗时过长：各个层级的并发部署能力，集群内节点的并发、集群间的并发等。
      • 项目的过程数据都是后期集中填充，失去度量意义：项目的过程数据由⼯具自动填充，不再依赖⼯程师手工输入。比如，开发完成的时间不再依赖于开发人员手工填写，而是由Jenkins构建完成后自动填写，以保证所有过程数据的真实有效性，从⽽为后面的度量和改进提供可靠的信息输入

    • 全局切入：

      • 软件缺陷的流转，软件需求的实现与交付，软件制品包发布等待

    • 持续改进：

      • 比如，需要在Jenkins中通过hook机制去触发⼀些操作（比如代码静态扫描、单元测试等），最简单的做法就是在hook中实现操作的具体步骤，这种实现在开始时效率很高，也非常容易实现，但却不是最优的⽅案，因为hook中的代码只会被执行⼀次，而且hook越来越多以后，各种实现都散落在各个地方，难以维护，⼀旦有新的需要（比如要加⼊慢SQL扫描），就需要改hook实现，而且这种做法也违背了IaC（Infrastructure as Code）原则。

        更好的做法是引入研发效能的消息中心，通过下游操作的订阅模式来实现未来的可扩展性

    • 效能平台的灵活性

      • 将Jenkins持续集成⼯具视为⼀个平台，在这个平台上支持安装各种插件，以增强平台功能，从而实现平台架构的灵活性

    • 杜绝"掩耳盗铃"

      • 代码质量门禁Sonar设而不卡
      • 单元测试只是执行，不写断⾔Assert
      • 代码覆盖率形同虚设
      • Peer Review走过场
      • 代码递交过于随意
      • 监控超配，有报警但无人认领

    • 发展方向与未来展望

      • 研发各个环节的全链路横向打通 CI/CD和测试不再是⼀个个独立的环节，软件研发从需求开始到最终线上交付采用⼀站式的研发效能平台，实现统⼀的研发⼯具和流程
      • 研发全流程的可视化 研发流程的可视化在后期⼀定会成为⾏业的标配，通过流程的可视化，可以展示各个需求的进展情况，让各级管理者和⼀线⼯程师清楚地知道项目目前所处的状态。
      • “稳态”和“敏态”齐头并进 研发效能的提升并不⼀定都要绑定到敏捷开发实践上，事实上，对于那些需求明确并且稳定的项目，传统的瀑布模型依然是最佳的选择，此时采用“稳态”实践才是获得最佳效率的途径。只有那些需求变更频繁的项目才是践行敏捷实践的最佳选择。因此，敏捷对传统瀑布而言并不是取代，⽽是互补，“稳态”和“敏态”会在长时期内和谐共存。
      • 研发能力的中台化沉淀 研发各阶段的垂直能⼒必然会沉淀到中台，以统⼀服务化的形式对外提供服务。⽐如，代码覆盖率的统计能⼒会统⼀到⼀个单⼀的服务中，为各个语⾔的业务提供代码覆盖率的统计；再如，分布式编译加速的能⼒也会成为企业级的服务，为各种⼤型项目提供编译加速。
      • 数据驱动下的效能提升 以后的决策⼀定会基于数据来开展。效能提升实践的效果衡量也会⾼度依赖于数据。研发效能数据中台的建设必定会被提上⽇程，通过收集存储研发各阶段的各种过程数据，实现基于研发效能⼤数据平台的决策体系

进阶解读

  • 软件生产作为智⼒密集型活动，掺杂着⼤量人的因素，很难严格地标准化
  • 质量和效能是“既要、也要”的关系，效能的提升能够将软件研发中的⻛险更快、更及时地暴露出来，同时减轻⼈脑负担，反过来⼜ 能提升质量本身
  • 渴望尊重和欣赏，是⼈性的需求之⼀。适度的关注和赞美能够产⽣强烈的心理暗示，继而带来效能的提升
  • 反摩尔定律告诉我们，越迟交付的价值其价值越低
  • 信息熵衰减对研发效能的影响是巨⼤的，要想方设法将信息传递的效率提升上去
  • 自解释的代码不是无注释和无文档的代码，而是伴随着⾼信息熵的代码体系。内容简洁合理的注释与⽂档，同样也是优秀代码的⼀部分，能够给效能的提升带来帮助
  • 基于流程优化，打破各个环节看不见的墙，去除不必要的等待，提升价值流动速度，这些是研发效能试图解决的一大类问题

项目管理提效

  • 敏捷宣言

    • 个体和互动 高于 流程和⼯具 工作的软件 高于 详尽的⽂档 客户合作 高于 合同谈判 响应变化 高于 遵循计划
  • 敏捷项目提升五大要素
    • 自组织团队
      • 自组织是指⼀个系统在内在机制的驱动下，自行从简单向复杂、从粗糙向细致方向发展，不断地提高自身的复杂度和精细度的过程
      • 首先，团队成员可以在迭代过程中选择自己擅长的任务，而非硬性分配，在这 种自适应的过程中，团队很容易形成更优的分工安排，这有助于发挥 每个⼈的⼒量，达成全局效率最优
      • 其次，自组织团队倡导人人有责，弱化职级和职位，每个⼈都要提升⾃我，为组织出力，形成正向交互
      • 最后，自组织团队天然的自由氛围，为团队的每个人提供了充分发表意见和想法的机会，这往往会带来更好的解决方案，促进效能的提升
    • 持续改进
      • 鼓励团队花时间反思，并勇于抛出问题，能够有效避免当前迭代中已经发⽣的问题流入下⼀个迭代周期，从⻓远的⾓度看，这样持续改进的团队⼀定会成为⼀个高效的团队
    • 频繁交付
      1. 团队需要转变观念，摒弃以自我为中心的思考方式
      2. 要做好迭代周期的管理、任务的拆解等⼯作
    • 消除对立
      • 敏捷团队的所有角色需要朝着共同的目标前进，荣辱与共
      • 在实践上，尽量避免针对不同的⾓⾊制定可能会产⽣冲突的KPI
        • 对测试人员制定Bug数量的KPI，针对研发人员则制定相反（解决Bug数 量）的KPI。我们甚至建议对整个项目的参与人员制定共同的KPI
        • 如果项目失败或延期，那么整个团队都应该为此负责，并持续改进
    • 未雨绸缪
      • 敏捷管理模式是拥抱变化的，其中⼀项重要的特点就是风险管控，提高对项目有利的事件发生的可能性及其影响力，同时减少对项目不利的事件发生的可能性，并尽可能减少其负面效应
  • 实践常见误区
    • 敏捷开发就是快速开发
      • 如果我们回过头重新阅读⼀下敏捷宣言，就会发现敏捷开发最⼤的关注点其实是价值交付，而价值交付最核心的⼀点就是质量
    • 敏捷开发应当抛弃文档
      • 文档传递的信息熵⼀般比语音沟通更⾼，因此文字是⼀种非常好的信息传输介质。但同时，文档作为⼀种持久化的媒体，需要进行同步和维护，这些隐性的代价也是 需要重视的
    • 敏捷开发只适合小微团队
      • 大型团队可以通过合理的组织拆分，建立多个负责相对独⽴功能模块的Scrum团队，达成全局敏捷的目标
    • 敏捷开发论为小瀑布开发
      • 迭代开发将一个大任务，分解成多次连续的开发，本质就是逐步改进，开发者先快速发布一个有效但不完美的最简版本，然后不断迭代。每一次迭代都包含规划、设计、编码、测试、评估五个步骤，不断改进产品，添加新功能。通过频繁的发布，以及跟踪对前一次迭代的反馈，最终接近较完善的产品形态
      • 所谓"增量开发"，指的是软件的每个版本，都会新增一个用户可以感知的完整功能。也就是说，按照新增功能来划分迭代
    • 敏捷没有约束的
      • 在⼀个迭代周期内，团队只负责完成当前迭代计划的任务，如果有其他任务加进 来，比如需求变更，只能延迟到下⼀个迭代周期
  • 建立度量体系（之后可视化等等写，这种不太重要对我现在）

之后写