作者丨王一男
今天我给大家带来的题目是《百度工程能力提升之道》，总结百度在工程能力提升方面所做的工作，分享内容主要包括百度提升研发工程能力的策略和工程实践这两部分。
我们做工程能力工作的同学经常被问到这个问题：提升工程能力的目标是什么？为什么要做工程能力提升？提升了以后会带来什么效果？
提升工程能力的总体目标是助力业务的成功，提升业务前进中的研发能力，让业务更快速、更高效的发展。
但是当我们在做工程能力提升的工作时，会发现所做的工作与业务的成功往往并不能很好对接。当业务做得风生水起时，我们可以认为是工程能力提升带来的结果。但当业务发展平平淡淡或寸步难移时，工程能力的提升的工作就会被认为是没有什么用处的。因此，我们应该如何衡量工程能力的提升以及它的影响范畴呢？
这是工程能力提升的影响力模型，我们也称为洋葱模型。最内圈是工程能力建设的一些直接贡献，比如方法、工具、以及许多工程实践。我们做了这些工程实践后能够直接影响到哪里呢？就是中间的这一圈，就是影响客户团队效率和质量的提升、浪费减少、工程师素养提升、治理有序等。中间的这一圈能更间接的影响到商业成功，因为能够影响商业成功的因素还有许多。
所以工程能力的提升最直接的影响就是研发的速度和质量。
百度提升工程能力的策略模型可以用“人”、“技”、“法”、“数据”来概括。下面我给大家详细介绍一下围绕着这四个方面我们具体做了哪些实践。
首先，我们来看一下人的方面，工程能力提升的根本还是人（工程师）本身的工程素养提升。即使我们有好的流程、方法和开发工具，如果开发者本身的能力和工程素养不够的话，工程效率也会非常低。
为了提升工程师的工程素养和工程能力，我们做了一些实践。例如招聘时，我们一定招优秀的工程师。新人入职之后，我们会为新同学提供工程师能力培养和文化建设的工作坊，这也我们一直在做的事情。工程师入职后，会有“码神训练营”，这个训练营除了介绍编码的规范及开发流程、工程实践之外，还会让大家在工具平台上实际操作，自主开发一个示例产品，促进大家在短时间内了解百度工程开发的流程和规范，建立工程规范意识。除此之外，公司内还有很多培养工程师文化的项目，比如 Hackathon ，还有 Good coder、Excellent Coder 认证等。
这是一个百度工程师的任务模型，作为一个百度的工程师，能够得到技术规划、技术传播、产品研发等方面的培训。入职后，我们会给每位工程师发一份《百度工程师手册》，手册里面包括一些优秀的工程实践介绍以及优秀工程平台的介绍。它可以让大家快速的了解百度工程规范、工程工具、并应用到自己的实际工作中去。
第二部分是技术，重点是工程工具平台。我们开发了自己的 DevOps 工具和管理协同工具，并且把它们连接成为一个从需求管理工具（iCafe）到代码管理工具（iCode）再到持续交付工具（iPipe）的完整研发工具链。使研发过程自动化起来，提高效率和质量。
但工程能力的保持与提升，只依赖于研发工具是不够的，如果每一个产品、每一个平台都要从零开始开发，或者为了服务于自身产品，而建造了许多功能重复的平台，那么公司整体的研发效能会受到很大影响。为了提高整体的工程效能，我们还需要做平台的建设与治理。
平台建设包括平台复用和源码复用这两方面。在平台复用方面，我们梳理出公司内部的几百个平台，将这些平台划分成若干个类别，每个类别都成立一个 TOC 组织来负责规划这类平台未来的发展。发展的目标就是让这类平台可用性加强、复用度提高，让平台本身的能力增强，以便让每个业务方能够更快速地使用平台去搭建自己的业务，提高工程效能。
上面介绍平台复用会带来一个问题：如果多数平台逐渐收敛成少数平台后，许多需求都会涌向这些平台，会导致平台研发团队不能按时、高质量完成所有的需求，从而使研发效率下降。那么我们怎么在平台化的基础上去做更好的工程复用呢？
那就是源码复用。在代码管理平台（iCode）上，我们做了内部开源功能。在平台化治理的过程中，平台是否能够达标，有一个考察点是它能不能实现内部开源。如果一个平台的 API 已经对外开放，并且又做到了内部开源能够让其他团队贡献代码协作开发，我们才认为它是一个优秀的内部平台。
上面这两个截图，一个是百度内部平台化管理工具“河图”，在“河图”工具中大家能够查到百度内部所有的开放平台，进而能查询到每一个平台具备的能力、对外开放的 API，并找到这个平台开源的代码。例如一个开发团队想要使用数据库，在“河图”上可以找到 1 到 2 个对应平台，然后根据他们的需求直接对接 API 就可以。如果他们认为这个数据库服务还需要一些新功能，那他们可以去 iCode 中贡献这个代码。
工程复用的优势，使每个团队能够站在巨人的肩膀上做开发，使速度和质量得到更好的提升。
第三部分是方法，主要是研发方法和流程的整理及运用。团队使用一致的方法和流程进行开发，并不断地迭代优化，他们的工作效率会越来越高。我们把管理实践和工程实践做了细化。
管理实践部分，我们总结了“百度方法 +”课程体系，把敏捷软件开发、精益创业思想等先进方法，经过百度实际产品线和团队的充分实践，提炼出了融合"方法 + 工具 + 案例 + 场景"的标准化知识体系，并进行了全面落地。
工程实践部分，我们也总结了一套完整的从需求到上线的各阶段优秀实践的集合，并对外发布。这就是《百度工程能力白皮书 - 工程标准 V1.0》中详细的介绍了每个研发阶段可能使用到的工程实践，以及每个工程实践具体的操作步骤。研发团队可以按照这样的标准去实践开发，促进优秀工程实践更快速落地。
举个例子，图中需求和开发阶段之后有一个代码准入阶段。在开发者提交自己的代码到百度的代码库之前，要做很严格的代码质量保证工作，这里有一个优秀实践叫做 Unit Test，单元测试。
这只是在百度许多优秀工程实践中的一个例子。上图中的每一个工程实践都有三级标准，以及详细的定义。我们把各个团队在实践中打磨好的工程实践整理成集合并发布，每个研发团队都可以参考这个实践标准去开发，就相当于把开发流程 10 倍速，让其更标准化、更规范化、更快速地落地。
人，通过学习方法（法）来使用工具（技），这会产生很多的数据。如何更好的使用这些数据，让这些数据帮助工程能力的进一步提升呢？我们也做了一些尝试。
通过统一的研发平台 — 百度效率云（iCafe、iCode、iPipe），我们可以收集大量的研发数据。然后我们尝试把每个团队的工程能力或工程实践达到的程度可视化出来。上图是“工程能力地图”页面，在这个页面上，研发团队可以方便地看到工程能力的变化。例如，图中灰色代表没有做这个实践，黄色代表已经做了但和平均水平有差距，绿色表示已达到平均水平，绿色越深就代表达到的工程标准越高。用这种可视化的方法能够让团队自主改进工程实践，提升工程能力。
为了帮助研发团队更好地确定下个阶段的目标，我们还做了一个工程能力分数的换算，这个分数里面包括项目管理能力、质量保证能力和持续部署能力，每个团队不同的角色可以根据自己的现状去设定工程能力改进的目标。通过这种尝试，团队可以清楚地知道自己需要做什么，做到何种程度。在做的时候，你只需要使用公司统一的研发工具平台，找到工具插件，就能得到相应的工程能力。这样一来，在很短的时间内，整个公司优秀的工程实践的数量和工程能力都得到了很好的提升。
下面我给大家简单介绍两个实践。
第一个实践是如何让研发工具更好的帮助工程师工作。
在国内，大部分企业内部会试用开源工具搭建研发工具链，之后由各个研发团队通过写脚本，把这些开源的工具组合成适合自己业务的 DevOps 工具平台，研发团队需要在不同的工具之间切换，这样工作浪费的时间是比较多的。
2017 年我去硅谷交流，硅谷互联网公司正在逐渐淡化开发工具的概念，同时在不断强化研发基础设施的概念，研发工具逐渐的下沉和基础设施，如资源、环境绑在一起，开发工程师的工作焦点从如何建设和完善 DevOps 平台转移到更加专注在自己的代码和业务实现上。
DevTools 和 DevInfra 的区别是什么？这好比你想住进一所房子，DevTools 能够帮你把房子修好，然后你才能住进去。这就像使用 Jenkins 工具，你需要在 Jenkins 上面写很多的脚本，或者用 Jenkins 连各种各样的测试工具、测试平台，把它搭成一个自动化基础设施之后，你的业务开发才能在上面自动化执行起来，这是工具、DevTools 的特点。而基础设施 DevInfra 就是这个房子本身，而且也不用修理，你只要搬进去，就这么简单。这是从工具到基础设施最直观的变化。
那么，我们具体是怎么实践的呢？为了让研发团队快而有序地开发，就要贯彻质量风险前移的思想，即在代码合入代码库之前就进行代码检查，如果检测到问题则不能合入。
目前流行的开源 Git 代码库产品，如 GitHub/GitLab, 它们的代码提交模式叫做 PullRequest 或 MergeRequest，开发者先在自己的分支上开发，当向目标分支合入代码时，会生成一个 Pull Requst。代码库负责人觉得你的代码 OK 就可以合进来，如果不 OK 就合不进来。这种 GitLab 和 GitHub 的代码提交模式由于是代码分支合并，所以 Diff 相对较多，许多实践中会试用自动化的工具来检查要合入的代码是否有问题，有问题就不允许合入，没有问题就可以合入。但对人工评审来说代码量越多，看的时间越长，这种代码提交模式在没有明显的时间要求的开源社区里面比较流行。
按照质量风险前移的原则，在 GitHub/GitLab 提交模式的基础上，我们还可以把代码检测、代码评审再往前移到代码上传至代码库前。百度一直使用 Change Requst 的提交模式，当开发者提交代码到 iCode 平台上时，iCode 平台就形成一个评审单，在这个评审单中，iCode 会自动进行代码的冲突检查、规范检查、缺陷检查、重复代码检查、可维护性检查以及持续集成，如编译 + 单元测试。然后再必须经过人工评审。如果前面的自动化检查发现了问题，iCode 平台不允许将代码合入，只能对代码进行修改后再次提交并上传。
Change Requst 还有一个优势在于评审单中代码的 diff 量相对较少，评审人能够更高效地 Review 这些代码，并且能够快速的把这些代码评审完，给予判定是否通过，提高了人工评审的效率和质量。
我们把代码托管、代码查看、代码评审、以及代码扫描或者说代码质量检测都集成到了 iCode 平台中，使 iCode 成为一个研发基础设施，落地质量风险是前移的实践。
质量风险还能不能再往前移呢？还是可以的，我们正在研发本地工具，使开发者在本地开发的时候还可以去做代码检查等工程实践。
第二个实践就是数据驱动工程能力的提升。
我们统一制定工程规范，用研发基础设施快速地落地。上面介绍的代码准入环节的若干工程实践就是把工程实践用自动化工具落地的一个具体的示例。当开发者使用研发工具进行工程实践活动以后，我们收集了许多工具使用的数据，并将数据可视化，让大家能够更直观了解工程能力的变化。有了数据之后我们再去做一些工程能力提升的事情，就有了更准确的反馈信息。把一些优秀的工程实践一步一步做起来，逐渐提高整个组织的工程能力。
刚才说了工程能力的提高有助于速度和质量的变化，做了这么多工程的实践和提升到底有什么样的变化呢？我这里做了一些数据的分析。
上图中 8 个颜色代表了 8 个团队，横坐标中有 4 个团队在这一段时间之内依然按照原来的方法去做，没有做工程能力改进。颜色高亮的这 4 个团队则按照工程能力标准去做工程实践及自动化的改进。
图中每个点代表一个发布版本。纵坐标是这个版本的代码从第一次提交到版本发布的时间差，当我们把这些散点用移动平均画出来以后会看到一个明显的趋势：高亮的、做工程能力改进的团队在这一段时间内，随着工程能力不断的深入，版本平均的开发周期越来越短，从原来 120 多个小时降到了 80 多个小时；阴影部分是没有做工程能力改进的团队，他们的开发周期越来越长，因为他们的技术债越来越多，这是我们从数据方面能够直观地证明工程能力的建设和开发速度的一个强相关性。那么，对于研发模式不同的团队，工程实践是否也可以提升速度呢？
我们分析了 6 个月内百度所有研发团队的数据，结论就是团队采用的工程实践数量越多，其开发周期就越短；工程实践做得深入的团队开发周期也越短；团队的人数越多，实施工程实践对缩短开发周期的作用就越大。这是第一次从数据方面证明工具的效果。
我们积累了很多的编程大数据，正在做很多的尝试，比如，在微观上，我们做代码搜索、代码补全和缺陷预测。在中观方面，我们做工程师画像，工程能力地图和 DevOptics。在宏观方面，我们会做企业研发效能的提升，也希望有相关兴趣的同学加入我们一起来做这方面的研究。
欢迎关注公众号：前端工匠，你的成长我们一起见证！
点个在看少个 bug ?