百度技术沙龙第 56 期回顾：代码重构与灵活交付（含资料下载）

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，感觉挺像的，学习应该是免费的，商用好像是要付费的。

有关百度技术沙龙的更多信息，可以通过新浪微博关注 @百度技术沙龙，或者关注 InfoQ 官方微信：infoqchina，InfoQ 上也总结了过往所有百度技术沙龙的演讲视频和资料等，感兴趣的读者可以直接浏览内容。

特别提示：第57 期百度技术沙龙将在12 月21 日在车库咖啡举行 ，欢迎关注 @InfoQ 、 @百度技术沙龙获取后续的活动信息。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。