GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）是一个长期关注互联网技术和架构的高可用架构技术社区和msup。 它是架构师、技术领导者和高端技术从业者的年度技术架构会议。 这是中国最大的技术架构会议。 其中一场会议。
第六届GIAC将从互联网架构、技术管理、系统架构、大数据与人工智能、移动开发与语言、架构相关领域最热门的前沿技术，分享技术创新与研发实践的典型架构案例。 。
在团队协作的话题上，腾讯研发效率资深专家茹冰生发表了题为“提升研发效率最佳实践探索”的主题演讲。
茹冰生，TEG-基础设施部-研发效能中心专家工程师，业界知名实用软件质量和研发工程效率专家，腾讯云最有价值专家TVP，互联网应用技术智库专家中国商会委员，畅销书《测试工程师全栈技术进阶与实践》《高效自动化测试平台：实用设计与开发》作者，InfoQ极客时代《软件测试52》作者讲座《从小工到专家的实用技巧》，并参与DevOps走向能力成熟，编写了国家学位模型标准，还参与了DevOps企业教练国际认证课程的设计。
以下为演讲实录：
我很荣幸受GIAC全球互联网架构大会邀请，在本次大会上担任“测试前沿技术”的演讲嘉宾。 我还受邀发表关于提高研发效率的主题演讲。 这里我简单总结一下本次演讲的精髓，希望对关心提升研发效率的同学有所启发和帮助。 以下为主要内容回顾。 欢迎大家参与。
现代软件业已不再是“大鱼吃小鱼”的时代，而是转变为“快鱼吃慢鱼”的时代。 对于很多大型传统软件公司来说，“大”原本是他们的优势，如今却陷入了“大而难翻”的尴尬。 对于大量小而美的互联网软件项目来说，创意和细分领域确定后，主要竞争对手争夺的是研发能力，具体来说就是将需求转化为软件或服务的能力。 其中，研发效率水平对需求影响显着。 转化率起着至关重要的作用。 同时，如何有效降低研发和运维成本也是研发效率需要关注的重要问题，尤其是大型互联网项目。 当某个环节只进行少量优化时，由于其规模效应（如集群规模、用户流量等）的放大效应，最终节省的成本将是相当可观的。
与敏捷的概念类似，研发有效性也很难准确定义。 事实上，很多复杂的概念并不是被定义的，而是逐渐演变的。 它们首先以现象的形式出现，然后找到适当的表达方式。 要理解如此复杂的概念，最好的办法就是理清发展脉络，回到历史，回到它诞生的时间，走遍它的发展历程，真正理解它的本质。 但由于时间限制，本次演讲我们没有足够的时间带大家回顾历史，所以我将通过几个案例让大家直观地感受到“提升研发效率之美”。
我们先看第一个例子。 很多时候我们在做产品原型设计的时候，需要使用产品原型工具来设计产品GUI界面，以此作为沟通的基础来开展后续的工作。 但你会发现，即使有像Axure、Modao这样的原型设计工具，“画界面”的成本仍然很高。 这里我们介绍一种一键式自动化生成方案，可以将图片GUI设计稿甚至手绘GUI设计稿转换为目标平台代码。
上面的例子中，首先手绘GUI界面设计，然后通过Sketch2Code直接转换为目标平台的代码。 如果您指定的目标平台是Web，则直接生成HTML。 如果你指定的目标平台是iOS，那么就会生成一个XCode项目，编译打包后可以直接在iPhone上安装执行。 该方法的引入将大大提高原型构建过程的效率。
我们来看第二个例子。 在API接口测试中，输入参数临界值处理不当的情况是很常见的。 例如，输入参数是String类型，但代码实现中不考虑String变量的值为NULL。 此类问题通常是在后期API集成测试或联调阶段发现的。 发现后修复的成本通常比较高，而且修复后还必须考虑回归测试的成本。 因此，我们可以引入一种机制，主动扫描获取API输入参数的类型，然后根据参数类型生成容易出错的值，并使用这些值自动调用API。 如果出现500错误或者抛出异常，则说明问题已被发现。 （例如，对于String类型的输入参数，可以生成NULL、超长字符串、包含非英文字符的字符串、SQL注入字符串等。）进一步，我们可以将这个方案与CI管道集成并执行在CI过程中主动进行这样的测试，以便更早地暴露问题。
上述两个例子都是以技术为主导的。 以下示例与技术无关，而是以流程为主导。 上图中，厨师正在制作三明治。 左图中，食材的摆放没有特定的顺序，因此厨师必须不断地来回移动才能完成任务。 右图中，食材按照使用顺序摆放，厨师站着就能轻松完成三明治。 生产，大大节省了不必要的行走时间，从而大大提高了效率。 可见，效率提升可以通过技术或流程来驱动。
看完上面的例子，我想你对研发效率提升有了非常感性的认识。 接下来，我们来看看研发有效性的本质。 如果让我用一句话来概括研发有效性，我会用“一个闭环，持续平稳、高质量地交付有效价值”。 解释一些关键概念：
在这个理念的指导下，我认为五个持续（持续开发、持续集成、持续测试、持续交付和持续运维）是这个理念得以落地的必要实践。 同时，我们还需要从流动速度、长期质量、客户价值和数据驱动四个维度来有效衡量研发成效。
以上从概念层面描述了研发有效性。 是不是看起来有点教条主义？ 其实我也这么认为。 那么下面我就用一些通俗的例子来解释一下我对研发有效性的理解。
左图就是所谓的“方轮”效果。 老板在前面使劲拉着车，员工在后面使劲推着车。 老板着眼大势、大方向，向前看。 很难发现推车的轮子是方形的。 拉车的员工可能也看到了。 是方轮，但由于老大在我面前用力拉，所以根本不敢停下来，只能用力推。 一旁的学生建议换成圆轮，却被无情无视。 换成圆轮确实需要额外的停顿，但殊不知这是为了让后背跑得更快、更远。 （题外话：突然脑子里闪过一个酒店的标语，就停下来走了）。 你可能以为这里的圆轮其实代表着工程效率。
右图根据事情的重要性和紧急程度分为四个象限。 这里我们只讨论象限A和象限B。 A 象限重要但不紧急。 通常是一些基础性的、长期性的重要事情，比如抢占市场的新产品规划、基础设施建设、流程优化、人才培养等。我喜欢把这个象限称为“准备象限”。 B 象限既重要又紧迫。 通常涉及必须立即处理的事情，例如系统故障、在线缺陷修复等。我经常将这个象限称为“消防象限”。
理想情况下，应将更多的时间花在“准备象限”上，而将少量的时间花在“救火象限”上。
一旦“准备象限”完成，“消防象限”事件发生的概率就会变小。 如果一家公司大部分时间都花在救火上，通常意味着两个象限之间的时间分配不平衡或颠倒，需要重点投资于长期重要但不紧急的事情。
对于软件研发来说，“准备象限”最重要的部分是研发效率。
最后我用一个比较形象的例子来比喻。 相信大家都听过鹅下金蛋的故事。 是不是鹅下的金蛋越多，效率就越高呢？ 其实不然，一味地让鹅昼夜不停地生金蛋，迟早会把鹅累死的。 这不是一个可持续的长期战略。 真正的功效应该是让鹅生鹅，让鹅生鹅，让更多的鹅一起下金蛋。
腾讯在TEG内快速发展的智慧科研平台、阿里巴巴走向产品化的云效率平台、百度基于工程效率白皮书的效率云等都是研发效率领域的标杆。 但这些天你有没有想过为什么？ 过去几年，各大行业的龙头企业都开始在研发效率领域发力，而且步伐是那么一致。 我认为其背后的原因如下：
就像“中平台”的概念一样，现在很多大公司的产品线非常广泛，而且有很多重复的轮子。 如果我们聚焦于业务的重复轮子，那么它就是业务中平台； 如果关注数据建设中的重复轮子，那就是数据中台； 如果我们关注研发效率建设中的重复轮子，那就是科研效率平台。 事实上，科研效率平台在一定程度上也可以称为“研发效率中台”。 其目标是实现企业目标跨产品、跨项目的研发能力的复用，导致每个产品线都无法做研发效率所必需的“0到1”，没有人有精力专注于更有价值的“1到1”。 n”。 将整合现有的研究效能平台，打造组织层面通用研发能力的最佳实践平台。 从商业角度来看，toC产品现在已经趋于饱和。 大量空闲时间等待APP来填补的红利时代已经一去不复返了。 过去，业务发展速度极快，所以采用烧钱的方式（大量研发，最好的选择就是“人海战术”）来换取更快的市场份额，实现赢家通吃。本来就靠软件产品的产出，研发的效率可以塞满钱，现在toC已经逐渐走向红海，研发的规模也比以前更大了，是时候了。勒紧裤腰带。当开源（开源和减少开支）遇到瓶颈时，开支的减少应该起到一定的作用，这样可以节省同样的资源和时间。从组织架构上看，很多企业都存在“谷仓困境”，研发的各个环节可能内部都已经优化，但光靠协作就可能导致大量的人员流动。和沟通成本，从而影响整体效率。 基于流程优化，打破各个环节的隐形墙，消除不必要的等待，提高价值流动的速度，是研发效率正在努力解决的一类问题。
本页幻灯片从软件开发、测试和发布的角度列出了各个阶段需要注意的问题，以提高研发效率。 主线是围绕CI/CD的一系列实践。 由于篇幅原因，这里就不一一赘述了，只是举几个例子，让大家有个感性的认识。
一体化的开发环境可以减少每个开发人员准备开发环境的时间成本，同时保证开发环境的一致性。 更高级的方法是使用云IDE，只要有浏览器就可以改代码。 您可以使用基于AI的代码提示插件，大大提高IDE中的代码开发效率。 不使用AI代码提示插件输入相同的代码需要敲击200次按键。 启用该插件可能只需要敲击 50 次按键。 代码提交后无需等待CI中Sonar进程发起对代码的静态检查。 到时候再发现问题并解决就为时已晚了。 您可以使用Sonar Lint插件结合IDE来实时启动本地代码检查。 如果有问题，直接进入IDE，如果有提示，直接修复。 单元测试比较耗时，可以使用EvoSuite等工具来减少单元测试的开发工作量。 对于较大的项目，每次修改后编译时间会更长。 可以使用增量编译甚至分布式编译（Distcc和CCache）来提高效率。 前端开发可以使用JRebel、Nodemon等工具，让前端开发预览体验更加流畅。 选择适合您项目的代码分支策略也可以大大提高效率。 构建高度自动化的CI和CD管道将大大提高价值转移的速度。 选择合适的发布策略还可以对性能和风险之间的平衡产生积极影响。 例如，如果架构比较简单，但集群规模较大，则首选 Canary。 如果架构比较复杂，但集群规模又不太大，蓝绿发布可能更有优势。 ……
从上面的描述我们可以看出，研发效率的提升涉及面很广，既有技术层面的，也有流程层面的。 那么在实际工程实践中，我们应该如何实施研发效率提升呢？ 我主张的观点是“用MVP（Minimum Viable Product）的思想来提高研发效率”。
MVP的概念来源于Eric Rise的《精益创业》一书。 核心理念是指以最低的成本尽可能展示核心理念的产品策略，即指用最快、最简洁的方式构建可用的产品原型。 这个原型应该表达你产品的最终效果，然后通过迭代完善细节。
这个想法特别适用于研究效率平台的建设。 确定了要解决的研究效率问题后，首先要给出最简单的解决方案，然后在后续实践中不断优化迭代。 如果我们试图关起门来搭建一个研究和效能平台，期望等到所有功能完善后再推给业务线团队使用，那将是一条死路。
还需要特别指出MVP的常见误解。 实现了某个功能，但暂时对客户没有实际价值，必须等到以后的功能发布后才能对客户有用，这不是 MVP。 MVP追求的是“麻雀虽小，五脏俱全”，即实现的功能点可以很小或者比较简单，但一定要对客户有价值。 用上图中的两个三角形来说，“横切”不是MVP，“竖切”才是MVP。
因此，在研发效率领域，我们必须保证我们打造的研发效率工具必须能够解决实际的痛点，尽管最初的方法可能比较粗糙。 从产品角度来看，研发平台本身与一般软件产品没有本质区别，需要不断迭代、持续改进。
下面开始本次分享最核心的部分，也是我自己对如何提升研发效率的阶段性总结。
经常有人问我，你以前领导的研究效率提升项目都成功了。 如果邀请你过来，这个项目需要多少年才能完成？ 这其实是一个无解的问题。 在一定程度上，投入大，周期就会短。 但实施周期不会因为投资无限而无限缩短。 我们可以避免很多踩过的坑，尽量少走弯路。 不过，我们还是要自己去寻找适合自己的路。 试图鼓励别人只会损害长远利益。 如果你买了一辆跑车，你就能成为一名赛车手吗？ 鉴于此，我根据自己所缴纳的学费和遇到的坑，总结了上图中的8条建议，供大家参考。 接下来我将一一解释。
第一点是“从痛点入手”。 很多时候，当我们手里拿着锤子时，一切看起来都像钉子。 但研发效率的提升却恰恰相反。 我们首先要找出哪些钉子最烦人，然后用系统的方法论来打造一把合适的锤子。
因此，在提升研发效率的初期，我们通常采取自下而上的策略，从每个工程实践中的实际痛点（钉子）出发，从解决问题的角度打造研发效率提升的亮点。 这时，我们奉行“短、平、快”的原则，将问题点一一解决。 例如以下场景：
第二个是“看大局”。 很多时候我们试图优化某个特定的环节而忽略了全局优化的可能性。
比如我们去医院看病，通常要排队半个小时才能挂号。 实际挂号可能只需要两分钟，然后就排长队等待看病。 好不容易进去后，不到五分钟可能就会要求我们去考试。 血…。 整个过程实际有效时间很小。 如果此时我们还试图优化注册时间本身，而不注重优化各个环节的等待时间，显然是错误的方向。 因此，效率的提升不仅要注重单个步骤的优化，还要注重减少步骤之间的时间。 等待是没有用的。 在这方面，体检中心比公立医院做得要好得多。 你很少会看到体检中心各个科室门口排起长队，因为体检中心会出于经济利益而注重吞吐量，通盘大局。 队列调度优化，实现更高的盈利能力。
回到软件研发领域，你会发现医院里类似上述的不合理排队现象比比皆是，比如软件缺陷的流转、软件需求的实现和交付、软件发布的等待等。软件产品包等，这些也是提升研发效率需要重点关注的领域。 需要从整体角度理清整个流程，识别浪费的等待时间，通过流程再造和优化实现整体效率提升。
第三项是“用户福利”。 关于提升研发效率，我们必须牢记的一件事是，成功的标准不是研发效率平台的成功，而是客户的成功。 只有客户利益才是检验一个研究项目是否成功的唯一标准。 这里我谈以下三点：
伪需求：伪需求是指研发团队本身的想象。 是典型的“手里拿着锤子，看什么都是钉子”的案例。 那么如何识别虚假需求呢？ 鉴别标准其实很简单。 这取决于客户是否愿意与你分担费用。 如果业务线已经开始做了，或者想要开始做，就说明这是业务线的刚需。 如果科研效率平台能够帮助提供解决方案，那么接入燕校平台就是水到渠成的事情。 这种迫切需求的例子我见过很多，比如微服务架构下集成测试环境的搭建，就是一个典型的例子。
结构性问题：著名企业咨询师刘润曾说过，“结构错了，一切都将是错误的”。 比如，大家一定都听过两个和尚分享粥的故事。 一碗粥需要两个和尚平分，但分享粥的和尚总是想喝更多的粥。 那么没有监督怎么能做到公平呢？ 教育分粥的和尚是否告诉家人“少吃点”？ 显然一旦没有监督，他就会给自己更多。 解决这个问题最好的办法就是让一个和尚分粥，另一个和尚选粥，这样的制度就决定了粥分配的均匀性。 所以一个好的策略就是承认每个人都是自私的，但是你的策略能够在每个人都是自私的基础上实现整体利益的最大化。 如果你的整体利益最大化是建立在要求每个人都无私的基础上的，是的，那就是一个失败的设计，因为这必然会导致失败。 回到提高研究效率的问题，我们必须定位“不是我们的研究效率平台有多好，而是使用它后业务线会如何改善”，才能获得成功的结构性杠杆。
服务意识：了解了以上几点，自然就了解了服务意识。 在科研效率平台落地过程中，我们需要与业务线合作，实现共赢。 业务线可以收获即用型解决方案，研效平台可以收获最佳实践的沉淀。 这些最佳实践的沉淀至关重要，为后期批量生产提供基础。 成功的复制提供了技术基础。
还有一点小经验可以跟大家分享。 有时候为了让科研效率平台能尽快在业务线落地，让业务线愿意成为我们科研效率平台的实验田，我们有时候就必须能够主动采取行动。责备。 ，如果有兴趣软件测试方法和技术 第三版 朱少民软件测试方法和技术 第三版 朱少民，也可以私聊我。
持续改进是研究平台自身发展的必由之路。 在解决很多问题时，一开始我们关注的是如何快速、简单地解决问题，但随着规模的增长，我们也需要更加关注解决方案的普适性和通用性。 如果你从一开始就试图找到一个完美的解决方案，你最终肯定会得不偿失。
这是一个具体的例子。 比如我们需要通过Jenkins中的hook机制来触发一些操作（比如代码静态扫描、单元测试等）。 最简单的方式就是在钩子中实现操作的具体步骤。 这种实现方式在一开始是非常高效的，也非常容易实现，但是它并不是最优方案，因为钩子里的代码只会被执行一次，而且随着钩子越来越多，各种实现方式就分散在各处，使其难以维护。 每当有新的需求（比如添加慢速SQL扫描）时，就需要修改钩子实现，这种做法也违反了IaC（基础设施即代码）原则。
更好的方法是引入具有研发能力的消息中心（MQ），通过下游操作的订阅模型来实现未来的可扩展性。 但如果从头开始构建MQ，实施难度和成本都会大大增加。 业务线可能等不到你的解决方案，因此研究效率的提升不会如期实施。 因此，我的观点是，研究成果的落地可以遵循“先圈地、后改善”的策略。
本页的幻灯片讲述了如何提高研发效率。 单独自下而上或自上而下都行不通。 相反，双管齐下，从中间挤压两边，是一个可行的解决方案。 由于篇幅原因，这里不再详细讨论。
这里我提出两个概念：“唱歌的人”和“搭台的人”。 当我们刚开始致力于研发效率时，我们既是平台游戏者，又是表演者。 我们以研发效率平台（建设者）为基础，为各业务线（执行者）提供解决方案。 然而，随着业务线接入规模不断扩大，此时各个垂直领域的需求也越来越多元化。 这个时候我们很难应对每个公司个性化、非通用的需求（每个公司都有不同的玩法），所以这个时候研效平台的开放能力就成了关键。 研究效率平台的建设必须能够应对这种多样性。 研究效率平台的职责转变为构建标准化平台，让业务线在这个平台上实现自己的个性化需求。 因此，研究效率平台本身的技术架构设计必须考虑可扩展性和灵活性。
比如平台是Jenkins，灵活性就是上面的各种插件。
捂耳朵偷铃是我们在研发过程中经常犯的错误。 上图展示了研发效率的“最差实践”。 你可以在心里数数错误的数量。
欺骗的另一个例子是广泛使用虚荣指标来衡量有效性。 那么虚荣指标到底是什么？ 虚荣指标是指那些不能直接用来指导后续行动的指标。 我们需要的是可以指导我们行动的可执行指标。 还是比较抽象，我举几个例子大家就很容易理解了。
我们需要的是在需要的时候提供帮助，而不是锦上添花。
最后一点大家都很容易理解：“做自己研发平台的第一个用户”。 研发平台本身的研发一定要通过自己的平台来进行，这样才能站在用户的角度看待自己的解决方案，与业务线用户进行交流。 共情”。
最后对研发效率行业未来的发展方向进行了展望。 由于篇幅原因，我就不一一阐述了。 我后续计划会专门写一篇文章来谈谈这个内容，敬请期待！
推荐一些衍生读物。 其中，我分别在2019年和2020年撰写的书籍中，“测试工程师的全栈技术进步和实践”和“有效的自动化测试平台设计与开发实践”。 他们主要专注于提高软件测试效率。 我还推荐朱·肖明教授的“完整软件测试（第三版）”。
让我对我和我正在写作的“提高软件研发效率的美的美感”的热身。 如果一切顺利，我将在2021年与您见面。
用关键字[GIAC]回复私人消息，以获取本次会议的来宾PPT
