雷达是这样一个文档，它列出了 ThoughtWorks 认为在当前软件开发中很有趣的那些变化——也就是 ThoughtWorks 认为你平时应该注意，并应该在项目中使用的那些正在发展中的技术。 它以我们的日常工作和经验为基础，反映了ThoughtWorks一批资深技术人的独特见解。 虽然我们认为这很有趣，但不应该被视为深度的市场分析。

雷达是由 ThoughtWorks 技术咨询委员会（简称 TAB, Technology Advisory Board）编写的。

TAB 是 ThoughtWorks 公司20多名资深技术人所组成的一个小组。 TAB 每年大概有两次线下聚会，每两周有一次电话会议。 其主要职责是为 ThoughtWorks 首席技术官 Rebecca Parsons 作顾问。 作为一个有广泛影响力的机构，TAB 可以纵观能影响ThoughtWorks技术人及其所使用的技术的那些主题。

Rebecca Parsons

Martin Fowler

(Boston)

Bharani Subramaniam

(Chennai)

Erik Dörnenburg

(Hamburg)

Evan Bottcher

(Melbourne)

Fausto de la Torre

(Quito)

Hao Xu

(Beijing)

Ian Cartwright

(Manchester)

James Lewis

(London)

Jonny LeRoy

(San Fransisco)

Ketan Padegaonkar

(Pune)

Lakshminarasimhan Sudarshan

(Bangalore)

Marco Valtas

(Porto Alegre)

Mike Mason

(Calgary)

Neal Ford

(Atlanta)

Ni Wang

(Xi'an)

Rachel Laycock

(New York)

Scott Shaw

(Melbourne)

Shangqi Liu

(Beijing)

Zhamak Dehghani

(Sydney)

我们在线下会议中构建技术雷达。 这些会议大概持续四天，其中有一天来布置雷达。 期间我们可能讨论的其他主题包括：开发人员的职业发展路径、审查开发人员的招聘流程、如何提高我们的新技术能力以及我们在微服务架构方面的经验等。

Rebecca 使用以下原则来组建 TAB，即组成一个能尽量广泛地代表 ThoughtWorks 技术领袖的小组。 该小组的成员来自全球（这使得安排电话会议变得很痛苦）。 Rebecca 通过 TAB 了解到很多人的相关建议，但最终由她做出选择。 TAB 不应该被视为 ThoughtWorks 最重要的由开发人员所组成的团队——有许多重要的开发人员并不在其中——而应视为由这些技术领袖代表所组成的团队。

TAB 的成员会随着时间的推移而不断变化，所以每期雷达都是由与前一期略有不同的人来编写的。虽然没有正式的服务期限，但通常情况下每次线下会议会有两、三个与会者发生变化。

其实雷达就是用来追踪有趣的技术，我们称之为 blip（雷达屏幕上的光点——译者注）。 我们使用两个分类元素（象限和圆环）来将 blip 组织到雷达上。 象限表示不同种类 blip 的集合，而圆环表明我们认为这些 blip 当前应该处于“技术采纳生命周期”中的哪个阶段。

条目具体指的是一种在软件开发中起作用的技术、是“运动中”的技术——也就是说，我们发现它们在雷达中的位置正在发生变化——这通常表明我们对于它们越来越有信心。

象限是一种类型的 blip 的分类：

• 编程语言和框架：以前这个象限只有编程语言，但是在2012年10月的那期雷达中，我们把框架也放到了这个象限里。
• 工具：这些可以是像数据库这样的组件，也可以是版本控制系统这样的软件开发工具，亦或是诸如混合持久化概念这样更通用的工具类别。
• 平台：指在其上构建软件的技术，诸如 Android 之类的移动技术、JVM 之类的虚拟平台或混合云之类的通用平台。
• 技术（Techniques）：包括像体验设计这样的软件开发过程中的要素，以及像微服务那样的构建软件的方式。

我们并没有把重点放在象限上——它们实际上只是将雷达分解成主题区域的一种方式。 我们并不认为一个 blip 是否该放到哪个象限会有那么重要。而与此相对照，当这个 blip 被放到不同的圆环区域时，会引起很多的讨论。

雷达是一个比喻：当一个技术条目越接近你，你就越快接触到它。像很多的比喻一样，你不能对比喻很太苛刻，而是应该理解它的比喻内涵。

我们的雷达有四个圆环，从最中间的圆环向外依次分别是

• 采纳环里的条目是我们认为你应该认真考虑采纳的。这不意味着你应该在每一个项目使用这个象限里的技术，任何工具只应该在适合的场景下被使用。但是我们确实认为处于采纳环里的技术是已被证实的、成熟可用的技术。
• 试验环里的条目是我们认为可以使用的技术，但是与采纳环里的条目相比，它们没有得到充分的证明。我们认为对大多数组织来说，可以对这些条目进行试验来决定是不是应该放在你的工具箱里。通常情况下，对于试验环里的条目，我们已具备生产环境经验，但是我们意识到大多数读者会比我们更加谨慎一些。
• 评估环里的内容是值得研究的，但尚没有试用的必要。除非你认为它们对你有特殊的益处。通常情况下，评估环里是我们认为有意思且值得留意的技术。
• 暂缓环里的内容，是那些虽然已被业界采纳，但我们认为体验并不好的技术。因此我们将它们标注出来，以提醒你可能也会遇到问题。有时是因为我们认为这些技术不够成熟，有时候我们会认为这些技术有无法弥补的缺陷，或者总是被错误的使用。我们确实会把希望行业不要使用的技术放到暂缓环里。

与象限不同，我们确实会特别热情地争论条目应该在哪个环里。我们不倾向于争吵，但是会产生激烈讨论。在雷达的制定阶段，我们会制定一些有用的规则帮助我们把条目分别放到各个环里。

我们只把我们在真实项目中使用过的条目放在试验环里。这意味着我们有时会往技术发展之后看，因为我们可能青睐于某一技术但还没有劝说客户试用它，如果我们做不到这一点，我们就不能把它放到试验环里。

对于采纳环，当我们认为在合适的上下文之下，不使用它是一个很差且可能不负责任的选择时，我们才会考虑将该条目放到采纳环当中。

我们不会花太多的精力去决定条目应该进入哪一个象限，而且也根本不会考虑象限内的角度和位置。 所以条目的角度坐标是由视觉设计师来决定的，除了美观，没有其它意义。

相比之下，我们确实要注意条目在雷达径向上的位置。 如果我们在试用环中放入一个条目，但接近采用环，这意味着我们作出了一个更广泛的建议。

这里有一些条目不在雷达里的原因：

• 没有 TAB 成员使用过这个技术。
• 有些 TAB 成员了解这个技术但对它没有足够的兴趣。
• 我们把它放到最初的列表里，但是不得不移除一些条目使之更符合雷达。这个条目在某种程度上算是受害者，但这意味着我们认为其它的条目更加重要
• 我们已经在往期的雷达中讨论过了，并且现在并没有关于这个条目的更新。如果一个技术点的状态没有变更，它就会从雷达里消失。
• 我们会从更一般和广泛的概念上去讨论条目。例如，我们在早期的雷达版本中并不会讨论一个具体的 NoSQL 数据库，但在提到”非关系型数据库“之后，我们会把这个条目标记为 NoSQL 数据库，之后，我们会为它选择一个具体的 NoSQL 数据库。

技术雷达代表我们当前观点的变化。考虑到技术进步日新月异，我们现在的默认任何技术条目都只出现在一期技术雷达上，之后便会被归档。之前的技术条目仍然可以在A-Z索引页面中被搜索到。

我们认为，在索引页面中保持这些技术条目的完整性和可见性非常重要，但请注意，我们不会再主动进行更新。在某些情况下，一些技术条目中的建议可能已经过时了。许多ThoughtWorks团队可能仍然在使用和推荐这些技术，但是只有当我们认为发生了值得注意的新变化时（无论是在技术还是我们的技术使用经验方面），才会更新这些技术条目。

我们采用了多种方式来体现条目在雷达中的变化趋势。首先我们会区分新的条目和已经在雷达中出现过的条目，另外，我们也会允许Blips在不同的环中移动。条目也有可能从一个大的分类细分为多个更为具体的元素，或者合并几个我们觉得可以看成一体的条目。

典型情况是当我们需要把这个条目的不同部分置于不同的环中时，它可能会被拆分或合并处理。

有时候，我们会将条目移动到其他象限。这表明它的分类发生了变化，象限对于条目的影响并没那么大或那么严格，所以条目所处的象限发生变化在我们看来并不那么重要，因此这些变化不会在文档中体现出来。

从根本上来说，其实就是一个或者多个TAB成员认为它很重要。我们侧重于将其解释为代表TAB成员和我们自己看法的技术雷达，我们并没有尝试去为整个行业构建一个技术雷达。我们发布技术雷达，是因为我们发现很多人对ThoughtWorks对技术的意见很感兴趣，但是我们不认为这可以代表整个行业给出意见。我们对我们已经在产品环境中使用过的技术有自己的看法，非常有必要根据这些经验去决定是否把它们放到试用和采纳环中，这确实存在一定的主观性。

TAB成员的变化会对具体条目造成影响，如果一个条目的拥护者离开了TAB团队，他/她最感兴趣的条目可能会被慢慢失去关注。

我们试着去限制雷达中条目的数量，因此如果我们觉得雷达变得过于拥挤，我们会继续讨论，然后根据投票来决定哪些会被保留或去除。最终是否决定这些条目去留的是Rebecca Parsons。

答案是否定的。

雷达只是捕捉正在发生变化的技术——因此我们在雷达上标记出那些有标志性的、在不同环中移动的技术。有许多我们很喜欢或者已经被使用了很长一段时间的技术不会出现在雷达上，因为我们认为这些技术已经趋于稳定并且在行业中拥有了他们固定的地位。

你会发现许多技术在过去的雷达中出现过，但现在已经从采用环中淡出。甚至技术雷达不是一个完整的技术清单，因为我们总是需要为新的技术腾出位置。

构建技术雷达的关键动作是我们的年度见面会。在开始这个会议之前，TAB成员通常需要和大量工程师沟通并思考哪些内容可以被放到雷达上。尽管TAB负责制定雷达，同时也会收集非TAB 的ThoughtWorks工程师的意见，了解他们对哪些东西感兴趣，我们也希望从ThoughtWorks内外的更多资源中寻求意见。

在技术雷达的见面会上，我们会花几小时时间来组织技术雷达上的具体内容。会议的主要目标是决定哪些条目会被放到雷达上相应的环中。这是最有争议的部分，所以需要TAB成员来一起完成，这是很有意义的一个环节。

我们先把这些条目用便利贴贴到墙上，并放置在被建议的象限和环中，有时候同一个条目会被不同的人放置在不同的环中。一旦所有的候选条目都被放在墙上，我们会逐个进行评估。我们每次讨论和决定一个条目是否应该被放到雷达上，如果是，应该放到哪个位置。其实这个讨论过程很有乐趣，你会在这个会议中听到很多不同的意见和这些技术的使用经验，在这个过程中可能会有争议，但是我们依然会秉承友好和相互尊重的原则来避免摩擦。

一旦这些条目被选中以及相应的位置被确定，我们需要给每个条目撰写一段介绍。我们使用Mingle来协作，它可以让我们较为容易的共同编写文本。典型的情况下，结束会议后每一个条目都会被指定一个负责人。通常TAB中会有一个主编来做催稿这种吃力不讨好的事来推进整个编辑工作。

在我们编写条目介绍的同时，会有一个设计师进行雷达图稿的设计工作。我们会告诉设计师每个条目距离雷达图中心的距离，至于角度等其他细节交由设计师决定。

最终我们的主编会把所有的条目介绍从Mingle上提取出来，然后整理成不同文档格式来发布我们的技术雷达。

由于我们希望提供给大家一个经过设计的富文本文档，所以一般来说我们的主要版本是PDF格式的。不过最近为了方便大家对雷达进行更深入全面的探索，搜寻并快速链接到雷达的条目，我们专门搭建了一个可交互的HTML版本。

是的，我们鼓励大家构建自己的雷达，这是一个将技术战略可视化的好办法，我们可以帮助你开启这个可视化进程。作为一个练习，它鼓励人们思考什么样的技术应该被研究，并帮助他们避免在技术泡沫中生活的潜在风险。

要加入雷达，就需要引起TAB成员的注意，特别是在我们的评估项目进程中。如果这个技术能让一个TAB成员感到兴奋，就可以进入评估环，但是我们需要用实际的经验来进一步确认。

我们没有正式的用于外部人员提名技术的流程，也没有安排技术展示。但ThoughtWorkers总是在寻求改进软件创建过程的方法，我们的同事活跃于众多技术社区。

主要是因为我们使用它们。通常情况下，这些项目是我们在客户场景下感觉到重做同样工作时候使用的工具。

我们经常讨论雷达。讨论内容与具体发言人密切相关，大多数人都喜欢讨论他们感兴趣的条目，当然，他们很乐意回答所有跟雷达相关的问题。通常，雷达会谈由一两个TAB成员参与，也许会与熟悉该技术的其它ThoughtWorker一起进行。

Neal还谈到了建立自己的雷达。

如果你有兴趣找某人谈论雷达，或想了解更多关于这些主题的信息， 请联系离你最近的ThoughtWorks办公室。

由于时间和空间的限制，我们不提供全面的参考清单，这会让人们更难查找。所以我们只是提到了其中一部分我们觉得这些内容特别引人注目，或者提出了不同的观点。

其实雷达的目的是帮助我们紧跟技术潮流。我们的行业特性决定了永远有新的东西出现，我们无法跟上所有这一切。你可以借助技术雷达来调整你的学习优先级。

• 从“采用”环开始，看看你是否熟悉或使用过所有的条目？如果你不熟悉一个条目，可以去看看它是否和你有关联；如果是，你就应该从现在开始研究它，尽快投入使用。如果“采用”条目与你的工作相关，而你却并没有使用过，请仔细考虑原因。
• 一旦你开始熟悉并使用“采用”环中的所有工具，那么可以开启“试验”环了。在这里，你需要查看每个条目并考虑是否和你相关。确保你熟悉这些主题 - 在网络上做一些研究，找几本书，用更有前景的项目建立一个原型。你还可以考虑在你的组织中如何进行一些尝试。
• “评估”环里面的条目是优先级最低的，一旦你了解了“试验”环中的内容，就可以开始调查了。基于你的情况，在这个环中初步了解某些事情可能比深入了解更可取。仅仅因为我们还没有使用它，并不意味着它不那么重要。但是，在优先考虑学习方面，“评估”环是一个很好的参考。
• 你可以暂时忽略在“暂缓”环中的内容，当然，这只是从优先级方面给予的建议。但至少这是一个开始。

  订阅技术雷达