2015.1 技术雷达 | 技术篇

许多项目都存在外部代码依赖，这些依赖中很大一部分是由开源项目提供的。为了确保构建过程可被重现，我们总是与固定版本的外部依赖进行集成。但这就意味着我们与这些类库的新版本集成并不及时，这将导致后面大量的合并工作。我们见到的避免这个问题的方式之一是夜间的Canary Build，它会尝试使用所有外部依赖的最新版本进行构建。如果成功，就代表我们可以将外部依赖修改为相应的版本。

数据紧缩（Datensparsamkeit, martinfowler.com/bliki/Datensparsamkeit.html）来自于德国隐私法规，它表述了一种观点：仅保存在业务上或者合法性上绝对必要的个人信息。客户隐私依然是一个热门话题。像 Uber 这样的企业正在收集高度个人化的客户数据，然而他们的安全措施却非常糟糕（washingtonpost.com/blogs/the-switch/wp/2014/12/01/is-ubers-rider- database-a-sitting-duck-for-hackers）。这是一场注定要发生的灾难。即便是在尚无法律规定的地区，我们也应该尽量遵循数据紧缩的原则，或者使用“去身份识别技术”（en.wikipedia.org/wiki/De-identification）来减少所存储的信息——如果你根本就不保存这些信息，你也就用不着担心有谁会盗取它。

作为一种集成方式，通过HTTP使用ATOM风格的事件摘要(feed)最近受到了很多关注。大多数情况下我们并不需要维持一个实时更新的服务，使用旧式计划批处理进程来创建和发布摘要就够了。在和云技术结合后，比如Amazon的S3文件存储和超媒体链接，可以创建一个高度可用、简单而又可测试的解决方案。我们团队已经开始把这个新旧交替的方法叫做‘Hipster batch’。

当我们实现单页应用（single-page applications）时，“离线使用”这个问题迟早都会浮出水面。鉴于很难正确的将离线模式加入一个现有的应用中，“离线优先”的思想已经成为了开发单页应用的一种趋势。本地存储同步（local storage sync）就是一种我们曾经成功运用过的重要实现技术。使用这种技术，面向用户的代码将不再发送请求到后端系统，而是仅仅从本地存储（local storage）中获取数据。并由一个后台服务对本地存储和后端系统进行同步，通常，会调用某种形式的REST API。

NoPSD (thoughtworks.github.io/p2/issue02/continuous- design) 运动，旨在将设计活动整合进“迭代-反馈”循环中，以构建出优秀的软件。取这个名字，不是在讽刺Adobe的软件，而是要去除“PSD文件”这个“终极权威设计图”。团队不应在项目一开始就制定一个完美的像素级设计规范，而是要开始拥抱持续设计（Continuous Design）：把设计师加入到交付团队中，使用低保真技术来做原型设计，并使用目标产品实际用到的UI技术（通常是HTML和CSS）来共同细化设计。

这种方法提高了对真实用户反馈的响应速度，支持横跨多种设备及其不同形态对设计进行测试，积极拥抱数码产品和产品创作过程的灵动本性。

依据团队边界分隔基础设施

我们的很多客户与负责构建、部署、支持他们的应用和服务的交付团队合作，在组织中实现了DevOps（技术运维）。然而不幸的是，在交付团队实施DevOps的道路上，经常会受困于生产环境中超级用户权限的归属问题。

在大多数组织中，生产环境是被共享的，因此提供宽泛的权限有很大的风险。一个行之有效的措施是将基础设施按照团队边界进行分隔，于是每个团队通过安全又相互隔离的访问进行工作，而不会影响到其他系统。如果是使用云环境，只需要对齐账户结构与团队边界，这种方式就更容易实现。

Middleman和Jekyll这样的静态网站生成器已经被广泛用于简单网站或博客的创建，同时我们也越来越多的看到它们成为更复杂技术栈的一部分。随着越来越多的团队开始尝试使用静态的预生成内容，认为“HTTP回复的内容只能根据请求来动态创建”的默认假设正在改变。

因为有像Clojure这样的函数式编程语言的默认支持，不可变数据结构（Immutable data structures）开始变得越来越流行。“不可变性”使得代码更容易被写、读和理解。使用“只追加”式的数据存储（append-only data store）同样带给数据库层面一些这方面的优点，同时也使得审计和历史查询更加简单。实现方式有很多种，从专门使用Datomic (datomic.com) 这样的“只追加”数据库，到简单以“只追加，不更新”的方式来使用传统数据库。

尽管比特币和其他各种密码货币（cryptocurrencies）现在备受关注，但让我们同样激动的是，Blockchain很有可能代替比特币和财务交易。Blockchain是一种不依赖于中央服务就能验证共享账簿的机制。我们已经看到Blockchain（不管是底层技术或是公开的比特币Blockchina）被用在身份验证、所有权、记录、投票、云存储甚至管理智能设备网络等各种系统的核心部分。如果你正在构建的系统需要在去中心化的网络中建立信任，那么Blockchain是一项值得尝试的技术。

一个企业级数据湖（Data Lake）是对大量原始格式的数据进行的不可变数据存储，它不仅作为其它处理流的资源，还可以为大量使用高效处理引擎的内部技术消费者（Consumer）—— 例如HDFS或基于Hadoop的HBase，Spark或Storm处理框架 —— 提供直接访问通道。与典型系统相比，这些系统会将原始格式的数据收集到严格受限的空间中，而且只会把严格受控的ETL过程生成的结果提供给这些消费者使用。

拥抱“数据湖”的理念就是要去除因缺少ETL开发人员或是堆积了太多前台数据模型设计而造成的瓶颈。它旨在帮助开发人员以敏捷的模式，基于他们需要数据的时机和方式（在合理的限度内），来创建他们自己的数据处理管道。这也与我们评价很高的另一模型——技术运维（DevOps）模型有很多相同点。

Gitflow是基于Git的一个严格的分支发布模式。虽然不是一个糟糕透顶的模式，但我们经常看到它被滥用。如果特性(feature)分支和开发(develop)分支是短暂并且频繁合并的，那么你确实是在发挥git的威力，它让团队合作变得更容易。然而，我们经常看到的一个问题是，这些“长寿分支”导致可怕的合并冲突，很多人重新开始使用git来避开这个问题。合并就是合并！无论你使用代码控制工具还是使用模式都不会改变这一点。如果你等一天或两天以上再合并，你就很有可能会遇到一个大的合并冲突。如果你在一个更大的团队中，这将成为一个真正的“问题”。如果你有更多的人在等待合并，这将进一步成为一个严重的瓶颈。成功引入像Gitflow这样的模式需要团队遵守“频繁合并、成功合并”的纪律。所以，当然可以使用这个模式，然而必须严格遵守“防止出现长寿分支”的纪律。

我们依然深信，在提高团队自主权和应对更加快速频繁的变更方面，微服务能给组织提供显著的优势。然而分布式系统所带来的额外的复杂性，需要更多的成熟度和投入。要做好微服务，就必须了解微服务给开发、测试和运维带来的变化。我们担心的是，一些团队在还没有弄清楚这些变化之前，就仓促地采用了微服务的方式。我们的建议非常简单，不要迷信微服务，在一股脑地开发更多微服务之前，从一个或两个服务开始，让你的团队有时间来调整并探索合理的微服务粒度。

我们仍然看到，一些团队会直接把复杂的多行命令插入到CI或CD工具的配置中。通常，这些内嵌的命令也包含了一些只在构建环境起作用的步骤，包括CI相关的环境变量，一些只会在CI环境创建、修改文件和模板的步骤，等等。这让构建环境变成了一头“怪兽”——其结果在开发人员的本地机器上是无法复现的。

这个问题之所以非常严重，是因为 — CI/CD工具本应该去暴露你代码中的问题，然而它自己却成为一个“复杂性怪兽”，其行为难以调试，结果也难以复现。

我们可以将复杂的构建过程提取成一个简单的脚本，这个脚本能通过一行命令来调用，这样就避免了在CI/CD工具中编程。它能够在任何一台开发者的机器上执行，这样也就消除了构建环境本身的独特性超。

把敏捷实践扩大到企业级，是一项持续的挑战。SAFe™在相关的众多方案中脱颖而出。虽然SAFe™为一些需要关注的方面提供了一份很有用的检查单，然而因为囊括了像“发布火车（release train）”和“门控流程（gated control processes）”这样已不再被敏捷社区认可的大型发布策略，此类方案往往容易被误用。企业倾向于寻找的具有一定程度通用性、可横跨多方努力的方案，看起来，这正是SAFe™所提供的，它所具有的某种程度的可定制性使它更具价值。事实上，其他的精益方案，比如像“改进道场（Improvement Katas）”这样，主张边试验、边持续改进的实践，为不断扩大敏捷实践的规模提供了一个更好的模型。

对于安全，传统的方式依赖于前期的规范以及最后阶段的验证。这种“安全三明治”的方式很难应用于敏捷团队，因为大部分设计都贯穿于整个过程，而且也没有利用到持续交付所提供的自动化便利。公司或组织应着眼于如何在整个敏捷开发周期中注入安全实践。这包括：正确评估威胁模型以做前期设计；考虑何时将安全问题划分为独立的故事（Story）、验收标准或全局的非功能需求；在构建流水线(Build Pipeline)中引入静态或动态的自动化安全测试；考虑如何将更深层的测试，如渗透测试，引入到持续交付的发布过程中。正如DevOps的出现使得过去相互博弈的团队能够重新合作一样，同样的事情也正发生在安全人员和开发人员身上。