百度技术沙龙第 56 期 代码重构与灵活交付

本文做者：HelloDeveloper

2014 年 11 月 15 日，由@百度主办、@InfoQ负责策划组织和实施的第 56 期百度技术沙龙活动上，来自的百度资深敏捷技术教练马波、冯上以及资深敏捷教练蔡晓鸥，敏捷教练、软件开发顾问申健这四位老师给你们分享了代码重构以及灵活快速交付的故事。其中，马波和冯上以对口相声的方式参与本次分享，看点十足。本文将对“ 网页搜索核心模块架构重构”、 “ 商业变现创业产品快速交付的故事”、“银行中的跨国研发团队如何快速交付”这三个主题分享作下简单的回顾，同时提供相关资料的下载。

 

主题一：网页搜索核心模块架构重构（下载讲稿）

 

重构的是什么？

 

首先来了解一下百度要重构的东西是什么。冯上和马波提到：它简称 C 模块，是百度搜索引擎诞生以来核心的模块。前先后后有九年的历史，每一年几乎有两百名工程师在上面修修补补。是各类服务搜索的结果聚集点，它跟全部的模块几乎都有交互。因此也致使它的逻辑很是复杂。

 

它还有一个比较显著的特色，就是开发很是密集，最近一年半有 206 我的贡献过代码，它处在快速开发的模块，这种模块咱们说要改变软件的代码结构有两种方法，一种方法是干脆扔掉从新写，另一种方法是慢慢重构，这种模块在这种开发的密度下不可能说从新扔掉另起炉灶，由于它在不停的迭代。因此最终采起的是一个渐进的过程，即真正重构的过程。

 

重构的项目背景

 

你们知道重构是在不改变产品功能的前提下，改变它内部的设计。百度最近几年来也在逐渐的沿用工做人才，他们有很好的意识，这种部门和工程效率部进行头脑风暴，咱们发现有不少状况，八次是有六次是代码逻辑错误，是由于写差了，这样把内部的质量问题曝露成外部的质量问题。

 

好比说这个模块是 C++ 和 C 语言混的模块，内存、指针这样的问题，不少错误是由于代码，固然业务逻辑自己不复杂，可是在问题本质复杂程度之上，重构的目的就是把它的随意性下降到业务自己就能够了。

项目成果展现

冯上提到：“上图是咱们前几个月作的东西，下面咱们会逐渐根据分析交互这部分的重构，讲讲具体是怎么作的。咱们只改了其中 1/4 到 1/5 的代码。还移除了不少无用的代码。指导思想就是小步快跑、演进式设计、SOLID 原则。实现细节就是设计层面、编码层面、工具层面，咱们在重构的时候也不知道它的理论模型是什么样的，看代码已经看不到它的运行模型，因此没有一个大的架构设计的过程，直接进到代码里面。好比说直接放到该放的类里面，这样慢慢的它的架构反而会清晰起来。”

在设计层面上，如何经过演进的过程使架构由混乱变成清晰。主要是作好词性分析，词性分析模块的交互，咱们把这部分功能单独提出来作了一个单独的类。作两种通讯平台进行通讯，把原来的代码揉在一块儿，通讯平台 A 一个类，通讯平台 B 的用另外一个类，原来的类干掉了。在这个过程中，两个通讯平台的行为很是像，等数据包回来之后，这部分代码和概念彻底是重用的。

还有一部分，在看代码的过程当中，你会发现规定很是复杂的函数在各个阶段都出现过。由于有同步查、异步查的，还有分阶段查的。经过不断的运用代码的方法，抽出单独的类，而后把他们放进去，通过这个过程以后，你会发现的很复杂的逻辑会变成一个很简单的东西。

在重构的过程当中很依赖自动化的测试，若是没有自动化测试很容易出错误，一开始咱们现有的测试是很慢的，大概跑一次到边缘和单测进行完须要三十分钟左右，对于咱们成天想运行不少次重构根本是没法接受的。因此咱们第一件事情不只仅代码的重构，还要帮他们升级测试工具，怎么样用一些工具和方法提升单测运行时间。咱们经过各类不一样的手段大概提升到四分钟就能够跑完，这样咱们能够快速得到反馈。

另外，还增长了质量监控，包括代码的复杂度和重复度，由于这个事情是要持续关注的，为了防止代码腐化的太快、太严重，之后也要关注。咱们想让产品线的同窗更多的用集成开发，尤为是作代码搬移，若是你不用这个是很是痛苦的。

主题二：商业变现创业产品快速交付的故事

蔡晓鸥首先介绍了凤巢的背景，随着 4G 时代的到来，视频广告在手机上播放是很常见的，百度也在尝试这种新的方式，在爱奇艺和百度视频上投放广告，依托的是凤巢的广告主，如今上线已经有三个月时间了，积累的广告主用户已经超过了十万，收入天天是三百万左右。据蔡晓鸥介绍这个项目挑战比较大，是跨团队项目，横跨三个事业部，内外部依赖是 15 个，还要串联一个子公司。这种创意产品在百度是很是少见的，初期开发的人数是 2500 人左右，时间比较紧，变动频繁。

首先分析一下研发模型，一共分三个子团队，第一个团队是业务端作的是给广告主用的系统，这个系统广告主会在上面制定一些广告的投放策略和性价。第二个是检索端，检索端是要匹配的用户，哪些用户是什么 ID，这些 ID 跟大数据进行匹配，分析用户的行为，给他分配想看的广告。看看具体是怎么操做的。

如图，把检索当中的业务端要作的事情拆分红 Story，一边是业务端，另外一边是检索端。绿色表明之前端为主的开发，右边这个内部的依赖。找出 Story 之后，根据这些 story，把内部和外部的依赖一块儿找出来，排出关键路径和总体的项目计划，制定合理测试方案。

以后，蔡晓鸥介绍了百度的研发工具链和 CI 的流水线，作集体的回归测试，部署测试环境。若是编译或者单测失败了，就在这个上面作了 API 测试，它会进入到下一个位置。剩下的就是在百度交付经理常规的工做，总体进度的推动。

主题三：银行中的跨国研发团队如何快速交付

区别于互联网企业，银行中的跨国研发团队快速交付又是什么样的？申健提到：

首先是要统一产品体验。你们知道，任何一家银行面临的市场都是不一样的国家，每一个国家有本身的法律法规、业务情况等，致使带来很大的维护性问题，而且不一样团队之间要进行交叉协做就很困难。

当时咱们的作法是引入灵活性，同时要兼顾可以定期的进行交付，之间作一个取舍。以后下降已有项目的维护成本，在软件开发阶段，你所投入的成本只是一部分，更大的成本在后面在维护阶段，可是咱们每每作计划的时候有意或者是无心的忽略了这点。

主要是如下三个策略来完成整个快速交付的过程：

第一个策略是涌现式设计，涌现是大天然里广泛存在的一种现象，不要像传统同样预先的定义一些流程，而是不断的在当下的状况下，涌现出新的你可能想不到的状况和场景、作法，为了下一个迭代你能作的更好，你可以进化。

第二个是基于主干的开发，主干上面随时能够进行部署和交付，这是咱们的方向和策略。今后没有项目的分支，只有我的临时的分支，咱们将尽快的提交到主分支上。这是一个很重要的策略，须要进行沟通和配合。

第三个叫持续集成，首先有静态的语法检查，咱们提取不一样模块之间的代码，咱们浅淡产品作的不是简单的手机界面，也是单页面的 Web APP，你打开手机网页之后一次性几乎把全部的资源加载好了，不一样的页码跳转是不会进行刷新的，这是咱们在技术上进行的尝试。由于前段的须要压缩，进行一些代码的混淆，防止被认错代码。

最后，申健总结到：咱们经过三大部分策略、架构和团队，咱们最后达到效果是显而易见的。须要改的代码越少，交付速度越高。经过不断的重构和调整，每次加新的项目越多，收益越大，须要改的代码也越少。敏捷就是这样迭代不断添加的过程，为了保证新的改动不影响前面已经好的功能，你的单元测试持续集成必定要跟上。

圆桌讨论环节：

为了促进参会者与咱们每期的嘉宾以及讲师近距离交流，深刻探讨在演讲过程当中的疑问，本次活动设置了圆桌讨论环节。在此环节中，在重构、交付、敏捷方法论、团队建设等方面的探讨比较多，四位老师分别对参会者提出的问题给出了详细的解答。

会后，一些参会者也经过微信分享了他们的参会感觉：

@雷魁：敏捷方法简单，如何让团队真正敏捷起来才是最关键的。

@建生：重构就是尽可能解耦，产品的快捷交付就须要回归小团队，模糊各模块团队的职责，重在沟通。

@灰太狼：任何一个团队都须要“打鸡血”的热情。尤为一种“正能量的鸡血”，可以提升工做效率，激发你们热情，团队全员工做目标明确，充实而且知足。

@倪建龙：刚刚查百度，的确有 ember js 刚刚看屏幕代码，我觉得是 angularjs，感受挺像的，学习应该是免费的，商用好像是要付费的。

原文连接地址：https://developer.baidu.com/topic/show/290166