雷达是这样一个文档，它列出了 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)

Birgitta Böckeler

(Berlin)

Brandon Byars

(Dallas)

Camilla Falconi Crispim

(Recife)

Cassie Shum

(New York)

Erik Dörnenburg

(Hamburg)

Evan Bottcher

(Melbourne)

Fausto de la Torre

(Quito)

Hao Xu

(Beijing)

Ian Cartwright

(Manchester)

James Lewis

(London)

Lakshminarasimhan Sudarshan

(Bangalore)

Mike Mason

(Calgary)

Neal Ford

(Atlanta)

Perla Villarreal

(Houston)

Rachel Laycock

(New York)

Scott Shaw

(Melbourne)

Shangqi Liu

(Beijing)

Zhamak Dehghani

(Sydney)

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

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

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

技术雷达涵盖了前沿的技术，我们称之为条目。我们按照象限和圆环对条目进行分类。象限代表条目的不同种类。圆环显示出我们认为的条目目前所处在的生命周期。

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

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

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

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

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

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

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

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

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

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

条目会分布在不同的象限，这一点不用担心。相反值得注意的是条目的横向位置。如果一个条目处在试验栏并且靠近采纳栏，那么意味着我们对这一条目的发展潜力很有信心。

一些技术没有出现可能有以下原因：

• TAB成员对这项技术没有印象。
• 部分TAB成员知道这项技术，但是并没有发现其中的兴趣点。
• 某项技术放在了候选条目中，但是由于条目数量有限不得不放弃。这项技术成为被舍弃的对象说明它并不像其他技术一样关键。
• 这项技术在我们之前的技术雷达中谈论过，并且现在没有更新。 如果其所在条目没有移除，那么这项技术就将不会体现在最新一期中。
• 我们将更加通用的技术加入条目，以讨论更广泛的概念。例如，我们在第一版技术雷达中没有讨论特定的NoSQL数据库，而是提到了“非关系数据库”。后来版本中，我们为NoSQL数据库创建了新的条目。

技术雷达代表了我们目前认知到的新技术。考虑到技术的发展速度，默认的规则是某一条目仅出现在单期技术雷达中，除非这一条目有了新的发展。当某一条目取得了值得关注的进展，需要刷新旧版内容时，Thoughtworks技术顾问委员会（TAB）的成员将会建议保留。在完整的A-Z索引下也可以搜索到旧的条目。

我们认为将旧的条目保留在索引中以确保完整性和可见性十分重要，但是请注意我们不会对其进行更新。在某些情况下，Thoughtworks团队可能会继续使用并推荐这些技术。否则旧版条目涉及内容可能已经过时，当您在存档中查看这些条目时请注意这一点。

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

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

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

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

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

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

答案是否定的。

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

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

理想情况下，我们每年会有两次面对面会议讨论技术雷达的内容。在每次会议前，Thoughtworks技术顾问委员会（TAB）的成员会和领域内人士进行沟通并思考将要列入技术雷达的条目。非Thoughtworks技术顾问委员会的成员也会提供感兴趣的内容。尽管技术雷达是TAB的产物，但是我们同样会通过内部和外部的众多声音中征求意见。

在技术雷达会议中，TAB成员会用几小时来讨论。我们的主要目标是确定将要列入的条目、条目所在的位置和如何阐述这些条目的内容。

我们首先会将候选条目放在建议的象限和圆环中展示在墙上。经常发生的情况是不同人会推荐相同的条目，有时这些条目会在不同的圆环中。随后我们会对候选条目进行长时间的评估。每一个条目都会讨论，以确定这一条目能否被列入技术雷达，以及如果可以那么它对应的位置是哪里。讨论过程是愉快的，尽管参与讨论的人都有自己的见解和经验，但是友好和互相尊重的原则使氛围并不像其他讨论可能的那样令人烦恼。

注意：请查看这一播客了解疫情之下的会议解决方案。

当我们确定了选定条目和它们在技术雷达中的位置后，下一步就是为这些条目书写文本。在讨论会议结束后，每一个条目都会分配给一个负责人进行内容编写。TAB中会有一个总产品负责人来确认每个条目的编写进度。编写完成后将会启动Thoughtworks内部反馈流程并和各个区域合作开展翻译工作，与此同时设计团队也会着手于技术雷达图表的交付。

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

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

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

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

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

在每期技术雷达发布前几周，我们会邀请两位TAB成员举行网络研讨会。

除此之外，我们还会定期在各个Thoughtworks地区进行有关技术雷达的讨论。讨论内容由每场的主讲人确定，主讲人们倾向于聚焦在自己感兴趣的条目上，但是他们也很乐于回答各种问题。通常情况下，这样的讨论会会有1-2位TAB成员参加，同时也有可能邀请到Thoughtworks相关领域的专家。

如果你希望哪个主讲人参加技术雷达讨论会，或者想要了解更多详情，可以联系离你最近的Thoughtworks 办公室。

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

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

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

  订阅技术雷达