持续交付2.0

“10X”,就是“十倍速”,是Google内部流行的一种隐喻,用以说明那些具有挑战的事情必须用非常手段来解决,而不是常规性的改进。

Google X部门是谷歌内部的创新产品部门,众所周时的谷歌眼镜和自动驾驶就是这个部门的工作。该部门的负责人阿斯特罗.泰勒用下面的方式解释这一法则:

“10X is easier than 10 percent. 

如果你只是想自己的汽车达到50英里的时速,可能只要对它稍加改造即可。然而,如果想让它只有一加仑汽油跑上500英里,就要对它进行重新设计了。”

那么,这一法则与工程效能有什么关系呢?下面让我们用LinkedIn的案例来了解一下什么是“非常之目标必配之以非常手段”。

02


建立有挑战的目标

在2015年,领英公司还不到3000名工程师。那时,公司原计划每个月发布一个版本,版本计划是开发时间为三个星期,集成测试时间为一周,然后就发布,每个人都能轻松顺利地按时完成工作,如下图所示。

然而,这只是一个“理想”而已,现实却是另外一个样子。每当拉出Release Candidate分支的前两天,所有人都在加班,匆忙提交半成品的代码,以便交给测试人员开始测试。而代码质量不好,就有很多Bug等待修复。最后一分钟还可能提交一个关键功能。没有测试完成,只能延迟发布。如下图所示,在这种情况下,每个角色都不开心。

开发人员不开心,因为:

公司希望改变这一状况。于是,在启动“航海家”项目的同时,全面改变这种非常糟糕的软件交付状态。

这个“航海家”项目是重写Android和iOS客户端,以及移动端的Web网站,这个项目几乎是全新的,包括新的代码库,新的前端API服务和新的产品设计。

产品目标是:

  1. 每周发布;

  2. 快速迭代;

  3. 更容易做试验(experiments)

整个公司都聚焦于移动端。因为移动端对公司业务来说,越来越重要,必须做的更好,下图就是目标。

对,你没有看错!一周发布一次!

03


10X,需要更激进的做法

面对这一目标,工程团队的回答如下:

于是,就有了下面的这个口号:

为什么要定在3小时呢?因为,如果想在三小时内完成,团队就

部署流水线就变成了下面这个样子:

深色的部分就是要在三小时内完成的工作。

按照原来的做事方式,上面的计划根本行不通,所以必须做出重大的改变!

04


静态分析(Static Analysis)

  1. Java Checkstyle

  2. Android Lint

  3. 与后端接入层的API服务制定编译时契约

    • 使用Linkedin 自己开源的REST框架 Rest.li

    • 通过静态扫描来保证即使修改了API,生产环境上也不会发生向前兼容性问题

    • 客户端的model 类是自动代码生成,以确保其正确性

  4. 使用IntelliJ的CLI 自动对代码进行格式化

05


代码构建(Building the code)