技术雷达第十九期正式发布,用百余个条目更新你的技能图谱!

ThoughtWorks每年都会出品两期技术雷达,这是一份关于技术趋势的报告,由ThoughtWorks 技术战略委员会(TAB)经由多番正式讨论给出,它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议,为从程序员到CTO的利益相关者提供参考。

它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性,因为它不仅涉及到新技术大趋势,更有细致到类库和工具的推荐和评论,因此更容易落地。经过半年的追踪与沉淀,ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,为技术者产出了第十九期技术雷达,对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。

本期主题

粘性十足的云平台

云提供商知道他们正在严峻的市场中进行竞争。为了获胜,他们需要吸引用户注册并长期留住他们。因此,为了保持竞争力,他们在新增产品特性上你争我抢,使得彼此不相上下。这一点可以从本期雷达试验环中以下云提供商的排名看出: AWS、 Google Cloud Platform 和 Azure 。然而,一旦用户注册,这些云提供商就倾向于与用户建立尽可能高的粘性,以阻止他们使用其他提供商的服务。这通常表现为其云服务会与其服务和工具套件紧密集成。用户只有继续使用其云服务,才能获得更好的开发者体验。通常在用户决定是否将其部分或全部工作负载移动到另一朵云上,或发现云服务的使用和账单多到失控时,就能明显感觉到这种粘性。我们鼓励客户使用 架构适应度函数度量成本 的技术来监控运维成本,并将其作为衡量云供应商粘性的指标。或者使用Kubernetes和容器,并通过运用基础设施即代码来提升工作负载的可移植性,降低切换到另一个云提供商的成本。在本期雷达中,我们还会介绍两个新的云基础设施自动化工具:Terragrunt和Pulumi。虽然我们支持通过粘性的高低来评估云提供商的新产品,但提醒你不要落入只使用通用云服务功能的陷阱。根据我们的经验,创建和维护与云无关的抽象层的开销,会超出退出某个特定云提供商的花费。

挥之不去的企业级应用反模式

无论技术如何快速变化,一些企业仍然想方设法地重新实现过去的反模式。雷达中的许多暂缓条目都在揭穿一些“新瓶装旧酒”的老把戏。比如:用Kafka重新创建ESB的反模式、分层式微服务架构、Data-hungry packages、过度庞大的API网关、Low-code 平台和一些其他有害的旧实践。一如既往的根本问题,是如何在隔离和耦合之间取得平衡:我们隔离组件,使其在技术角度便于管理。但是我们也需要协调组件,使其有助于解决业务问题。这就产生了某种形式的耦合。因此,上述旧模式就不断重新冒出来。新的架构和工具为解决这些问题提供了适当的方法,但这需要刻意去理解如何正确地使用它们,而不仅仅是使用崭新的技术去重新实现旧模式。

持之以恒的工程实践

随着技术创新步伐加快,新技术的发展呈现出一种从爆发到沉淀不断循环的模式。每当能够颠覆我们对软件开发固有认知的新技术出现时,都会引起业界的争相追捧,容器化、响应式前端和机器学习都是很好的例子。这时技术处在爆发阶段。然而,只有在明确如何与长期以来的工程实践(持续交付、测试、协作等)相结合之后,新技术才能真正的发挥功效,并进入沉淀阶段,为下一次爆发性扩张打下坚实的基础。在沉淀阶段,我们尝试在新技术的背景下应用实践,比如进行全面的自动化测试以及创建脚本代替重复操作,通常也会创造出新的开发工具。虽然表面看来技术创新是行业发展的唯一驱动力,但事实上,创新与持之以恒的工程实践相结合才是我们不断进步的基础。

速度 = 距离 / 时间

通常,我们会选取本期雷达中部分共性条目的精彩集锦展现在雷达主题中,但本主题涉及自技术雷达诞生以来出现过的所有条目。我们发现(并通过一些调研证明)雷达条目停留在雷达上的时间正在缩减。当我们在10年前启动技术雷达时,如果某个条目在雷达上的位置不再移动,它依然会保留两期(大约一年)时间,之后才会自动移出雷达。然而正如标题中的公式所说,速度 = 距离 / 时间: 软件开发生态系统中的变化一直在持续加速。在时间保持不变(依然是每年发布两次)的前提下,雷达中技术创新所跨越的距离明显地增大了。这为精明的读者提供了显著的证据:技术变革的步伐正在不断加快。我们不仅看到雷达中的各个象限在加速变化,也看到了客户对新兴的及多样化的技术选择所表现出的兴趣。因此我们将改变传统的默认模式:雷达不再默认保留其上的条目,它们是否出现在雷达上完全取决于它们当前的价值。我们在深思熟虑后做出了这项改变,并认为只有这样才能更好地跟上技术生态系统中前所未有的狂热变化节奏。

象限亮点抢先看

Event Storming(事件风暴)

快速市场响应能力是组织进行微服务转型的主要驱动之一。然而只有沿长期业务领域边界对服务(及其支持团队)进行清晰划分时,这种期望才可能实现。否则,现实需求只有在跨组织和跨服务的通力合作才下能完成,这自然会在规划产品路线图时产生冲突。良好的领域模型设计是解决此问题的方案,事件风暴(EVENT STORMING)也迅速成为我们最喜爱的方法之一,它使我们能够迅速识别问题领域中的关键概念,并用最好的方式与各方利益相关人制定解决方案。

Microservice Envy

微服务已成为现代云计算系统中的领先的架构模式,但我们依旧认为团队在使用该架构时应谨慎。 MICROSERVICE ENVY特指那些盲目追赶微服务潮流的现象,很多团队在实践微服务时并没有简化其系统架构,大多数的实践方案只是将一些简单的服务聚合在一起而已。目前,Kubernetes等平台简化了复杂的微服务系统的部署问题,其他服务提供商们也正在推进他们的微服务治理方案,这些强大的工具都可能裹挟团队走上微服务之路。 但请千万谨记,微服务是通过开发复杂度来换取运维复杂度,并需要自动化测试、持续交付和DevOps文化提供坚实的支撑。

Observability as Code(可观测性即代码)

可观测性是运转分布式系统与微服务架构必不可少的一部分。我们依赖不同的系统输出来推断分布式组件的内部状态,比如分布式追踪、日志聚合、系统指标等,进而诊断问题所在,并找到根本原因。可观测性生态系统的一个重要方面就是监控——可视化以及分析系统的输出——并且在检测到异常时报警。传统的监控报警配置,都是通过图形界面的操作完成。这种方法导致控制面板页的配置不可重复,从而无法持续测试和调整报警,来避免报警疲劳或错过重要的报警,进而偏离组织的最佳实践。我们强烈建议使用代码来配置可观测性生态系统,称为可观测性即代码(OBSERVABILITY AS CODE),并且采取基础设施即代码的方式搭建其基础设施。因此,在选择提供可观测性的工具时,要选择支持通过代码版本控制进行配置,并能通过基础设施持续交付流水线执行API或命令行的产品。可观测性即代码,是基础设施即代码中经常被遗漏的一部分,我们认为这一点非常重要,需要明确指出。

Four key metrics(四个关键指标)

2014年首次发布的DevOps状态报告指出,高效团队创造了高效的组织。最近,该报告背后的团队编写了Accelerate一书,描述了他们在报告中使用的科学方法。两份材料的核心点都支持了软件交付性能的四个关键指标(FOUR KEY METRICS):前置时间,部署频率,平均恢复时间(MTTR)和变更失败百分比。作为帮助许多组织转型的咨询公司,反复使用这些指标测量,可以帮助组织确定他们是否在提高整体效能。每个指标都创造了一个良性循环,并使团队专注于持续改进:缩短交付周期,减少浪费的活动,从而使你可以更频繁地部署;部署频率迫使你的团队改进他们的实践和自动化流程;通过更好的实践,自动化和监控可以提高你从故障中恢复的速度,从而降低故障频率。

Run cost as architecture fitness function(架构适应度函数)

随着软件架构及其业务的演进,我们理应密切关注应用的运行成本,但发现并非所有的组织都如此。尤其是在使用无服务器架构时,开发者们认为无服务器架构会更便宜,因为他们只需按消耗的计算时间付费。然而几家主要的云服务提供商在热门的无服务器函数上定价十分精明,虽然无服务器在快速迭代上很有优势,但与专属云(或内部私有云)相比,它的开销可能随着使用量迅速增长。我们建议团队将应用的运行成本纳入架构适应度函数(RUN COST AS ARCHITECTURE FITNESS FUNCTION)来考量,这意味着:追踪并权衡应用的运行成本与交付价值;当它们之间产生较大出入时,就需要考虑改进软件架构了。

Debezium

DEBEZIUM是一个change data capture (CDC)平台,可以将数据库的变更以流的形式传入 Kafka 主题中。CDC是一种流行的技术,具有多个使用场景,包括将数据复制到其他数据库中,为分析系统提供数据,从单块系统中提取微服务,以及令缓存数据无效等。我们一直在寻找这个领域的工具或平台(包括在之前的技术雷达中讨论过的 Bottled Water),而Debezium 是一个极佳的选择。它使用了基于日志的CDC方法,意味着能以对数据库日志文件的变更进行响应的方式进行工作。Debezium使用了Kafka连接,这使得它具有高度的容量伸缩性,以及对故障的系统韧性。它拥有包括Postgres、Mysql和MongoDB在内的多个数据库的CDC连接器。目前,我们正在一些项目上使用该平台,并取得了很好的效果。

Quorum

在区块链技术领域,Ethereum(以太坊)是一个领先的开发者生态系统。我们看到了一些新兴的解决方案,它们旨在将Ethereum这项技术传播到一些企业环境中。这些企业通常需要网络权限和交易隐私管理,另外还需要更高的吞吐量和更低的延迟。 QUORUM 就是其中的一个解 决方案。Quorum最初由J.P. Morgan开发,其定位是“企业版的Ethereum”。与创建了新的以太坊虚拟机(EVM)的Hyperledger Burrow 节点不同,Quorum的代码源自以太坊官方客户端的一个分支,所以能与以太坊一起进化。在保留了以太坊账本的大多数功能的前提下,Quorum将共识协议从工作量证明机制更改为更高效的协议,并增加了私有交易支持。使用Quorum,开发人员可以使用他们的以太坊知识来构建企业级的区块链应用,这些知识包括 Solidity语言和 Truffle 合约。然而根据我们的经验,Quorum还没有为应用于企业做好充足的准备;比如:它缺乏针对私有合约的访问控制机制,无法用于负载均衡,并且只支持部分数据库。所有的这些限制都为用户的部署与设计带来显著的负担。我们建议在使用Quorum的时候保持警惕,同时密切关注它的后续发展。

IPFS

在多数情况下,区块链不适合存储 blob 文件 (例如:图像,音频),当人们开发 DApp 时,一种选择是将blob文件存放在一些链下的集中式数据存储中,这种做法通常会导致信任缺失,另一种选择是将它们存储在星际文件系统 IPFS上,这是一种内容可寻址、版本化、点对点的文件系统。它旨在高效地分发大规模数据,并能阻止任何中心化机构删除数据,文件存储在不需要相互信任的对等节点上。IPFS 保存文件的每一个版本,这样你将永远不会丢失重要文件,我们将IPFS视为区块链技术的好的补充。除了区块链应用程序外,IPFS还有一个愿景是对现有的网络基础设施进行去中心化重塑。

Resin.io

RESIN.IO 是一个物联网(IoT)平台。虽然只做把容器部署到设备中这一件事,但它做得很好。开发人员使用一个软件即服务( SaaS)的门户来管理设备,并为这些设备分发由 Dockerfile 定义的应用。该平台可以为多种硬件类型构建容器,并通过无线的方式部署容器镜像。Resin.io 使用balena 来管理容器。而balena是一个基于 Mobby 框架的容器引擎,由Docker 出品。该平台仍在开发中,有些功能尚需完善,也缺少一些特性(比如与私有容器注册服务协同工作)。但是目前的特性集(包括从 Web 门户使用 ssh 访问一 个设备上的容器)表明它的未来充满希望。

Knative

作为应用开发者,我们喜欢专心解决核心业务问题,而让底层平台来处理那些枯燥且困难的任务(如部署、容量伸缩及应用程序管理)。虽然无服务器架构往这个方向迈出了一步,然而大多数流行的产品都会与某个专有实现绑在一起。而这意味着供应商绑定。KNATIVE试图以开源无服务器平台的方式来解决此问题。它良好地集成了流行的Kubernetes生态系统。利用 Knative ,可以对随时请求的计算进行建模(其间可以从一些框架中进行选择,如 Ruby on Rails、Django和Spring 等),可以订阅、交付和管理事件,可以集成用户所熟悉的 CI和CD 工具,可以从源代码构建出容器。该平台提供一组中间件组件,来构建以源代码为中心且基于容器(能够实现资源伸缩性)的应用。这使得它成为一个颇有吸引力的平台,当有无服务器需求时,值得对其进行评估。

Apache Atlas

随着企业数据需求的不断增长和多样化,对元数据管理的需求也在不断地增长。APACHE ATLAS 是一款用于满足企业数据治理需求的元数据管理框架。Atlas支持元数据类型建模、数据资产分类、数据来源追踪和数据发现。但是,在搭建元数据管理平台的时候,我们也必须小心避免重蹈主数据管理的覆辙。

Cypress

运行端到端测试时经常会遇到一些棘手的问题,比如运行时间过长,测试过于零碎,还需要修复无头模式下运行的测试所导致的 CI 失败。我们的团队借助 CYPRESS 很好地解决了性能差、响应时间长、资源加载慢等常见问题。Cypress 是一款很有用的工具,可以帮助开发者构建端到端测试,还可以将所有测试步骤保存为 MP4 视频,便于检查错误。

VS Live Share

VISUAL STUDIO CODE 是微软推出的免费 IDE 编辑器,可以跨平台使用。我们曾用它同时进行前端 React、TypeScript 和后端 GoLang 的开发,而无需在不同的编辑器之间切换,体验很好。 Visual Studio Code 中的工具、语言支持和扩展插件数量都在迅猛增长,也越来越好用。我们要特别推荐在实时协作及远程结对编程时使用 VS Live Share 。固然微软或 Jetbrains 成熟的 IDE 对使用静态类型语言(如 Java 、 .NET 或 C++ )的复杂项目支持得更好,但我们也发现 Visual Studio Code 正逐渐成为基础设施开发组和前端开发组的首选工具。

Stanford CoreNLP

越来越多的项目需要处理非结构化的数据,而从文本中提取出有意义的业务信息是一项关键技术。 STANFORD CORENLP 是一组基于 Java 的自然语言处理(NLP)工具集,支持英语、汉语和阿拉伯语等多种语言的命名实体识别、关系抽取、情感分析与文本分类,也提供了用于标记语料库和训练模型的工具。 Stanford CoreNLP 协助我们使用NLP 领域的最新研究成果来解决各种业务问题。

LocalStack

使用云服务时面对的一个挑战是如何在本地进行开发和测试。 LOCALSTACK 为 AWS 解决了这个问题。它提供了各种 AWS 服务的本地 测试替身 实现,包括 S3 、 Kinesis 、Dynamodb 和 Lambda 等。它基于现有的最佳工具如Kinesalite 、 Dynalite 、 Moto 等构建,并增加了进程隔离与错误注入的功能。 LocalStack 的使用很简单,并附带了一个简单的 JUnit 运行器以及 JUnit 5扩展。我们在一些项目中使用过 LocalStack ,并对它印象深刻。

Bitrise

构建、测试和部署移动应用,尤其是由一条流水线从代码仓库打通到应用商店的时候,会涉及许多复杂的步骤。虽然这些步骤可以由脚本或普通 CI/CD 工具提供的流水线自动完成,但对于专注移动应用开发,而不需要与后端的构建流水线做集成的小组来说,使用专用工具可以降低复杂度和维护开销。 BITRISE 配置简单,并预置了一组完整的步骤,可以满足绝大多数移动应用开发所需。

PredictionIO

PREDICTIONIO 是开源的机器学习服务框架。无论是普通开发者还是数据科学家,都可以利用它创建用于预测的智能应用。和所有其他智能应用类似,PredictionIO 由三个部分组成:数据收集和存储、模型训练以及模型部署和服务暴露。开发者只需要基于它提供的相应接口实现数据处理逻辑、模型算法和预测逻辑,无需在诸如存储数据以及训练模型之类的事情上投入额外精力。从我们的经验来看,在不要求高并发处理的情况下,PredictionIO 能支持不同大小的数据集。大多数时候我们使用 PredictionIO 来为中小企业构建预测类智能服务,或者在构建复杂定制化预测引擎的过程中进行概念验证。

Q#

量子计算目前已经可供测试,但何时真正到来尚未明确。在硬件到位之前,我们已经可以通过语言和模拟器来实验和学习它。尽管IBM等公司已经取得了不错的进展,我们对微软在 Q# 语言及其模拟器(本地32量子比特,Azure云上40量子比特)方面的工作更加关注。如果你想开始了解这项编程的前景,请查看他们在 GitHub 上的范例。

MockK

MOCKK 是用 Kotlin 编写的模拟库。它的核心理念是像 Coroutines 和 Lambda 表达式一样,为 Kotlin 提供一等公民级别的语言特性支持。不同于 Mockito 或PowerMock 的蹩脚封装,作为原生的开发库,它能帮助开发团队在测试 Kotlin 应用时编写干净、简洁的代码。

WebFlux

Spring Framework 5 已发布一年有余,它采用了响应式流 —— 一套非阻塞背压(backpressure)式异步流式处理标准。在传统的 Spring MVC 模块之外,WEBFLUX 为在 Spring 生态下编写 Web 应用提供了一个响应式替代品。经过一系列应用的试用,WebFlux 给我们的团队留下了深刻的印象,并汇报说这种响应式(函数式)实现增强了代码的可读性和系统的吞吐量。但他们也确实注意到,采用 WebFlux 需要在思维方式上做出一些重大转变,建议在WebFlux vs. Spring MVC 的技术选型中考虑这一点。

Jepsen

随着 微服务 架构越来越多地被采用,相比以前,我们构建了更多的分布式应用程序。尽管解耦架构带来了许多好处,但证明整个系统正确性所需的工作量和复杂程度正急剧增加。 JEPSEN 提供了许多我们所需要的工具,来帮助我们验证协调任务调度程序的正确性,测试分布式数据库的最终一致性、 线性一致性 ( Linearizability)和 可串行性(Serializability)。我们在一些项目中使用了 Jepsen,令人惊喜的是,我们可以测试驱动配置,注入和修复故障,验证系统恢复后的状态。


以上是我们在最新一卷技术雷达中随机摘取的几个Blip,欲获取整版技术雷达,请点击技术雷达官方网站进行下载!

Share

ArchUnit

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(参考阅读:解读技术雷达的正确姿势

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第三篇,依然关注架构,Blip是ArchUnit

位置

2018年11月第19期技术雷达,工具象限,建议试验

目标受众:

系统架构师,技术管理者,开发人员

关注问题:

  • 如何在Java系统架构下,应用架构适应度函数(Architectural fitness function)来驱动架构演进?
  • 如何在Java系统架构下,做系统演进后架构守护,减缓系统再次腐化?

解读:

在上一期我们介绍了架构适应度函数(Architectural fitness function),也提到了ArchUnit,这期就来详细介绍一下。

ArchUnit是用来检查架构特征的Java测试库,比如包与类的依赖关系、注解、甚至是调用层级一致性。它可以附加在现有的测试方案中,以单元测试的方式运行,但目前只能用于Java架构。

ArchUnit测试套件可以合并到持续集成环境及部署流水线中,使我们可以更容易地利用架构适应度函数实现演进式架构。我们来看看ArchUnit都能做些什么:

  • Package Dependency Checks

  • Class Dependency Checks

  • Class and Package Containment Checks

  • Inheritance Checks

  • Annotation Checks

  • Layer Checks

  • Cycle Checks

想要了解更多,可以移步【官方用户指南】

最后不得不说一下,架构优劣不取决于是否遵循某一个标准,而是应该取决于能否支撑业务的需要。约束越强,灵活度越低,架构就会越加僵硬,缺少适应性,产生冗余。

所以工具本身只是赋予了我们约束架构的能力。但是能否正确地使用这种能力通过Fitness Function和演进式架构来促进架构对于业务的匹配度和适应度;还是截然相反的错误地滥用这种能力成为所谓的管理手段或是技术上的噱头,最终导致系统架构僵化,无法支撑业务需要,决定权还是在我们架构师手中。

不要过度神话工具,也不要让工具替我们背锅,工具只是工具,工具本身没有对错。

工具:

ArchUnit

延展阅读:

👇👇👇订阅最新期技术雷达

Share

Architectural fitness function,架构你好我也好

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(参考阅读:解读技术雷达的正确姿势

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第二篇,依然关注架构,Blip是Architectural fitness function

位置

2018年5月第18期技术雷达,技术象限,建议试验

目标受众:

系统架构师,技术管理者,开发人员

关注问题:

技术架构腐化带来系统响应度降低,可维护性下降,技术债缠身。而盲目优化或是单纯的技术驱动的架构优化又常常偏离初衷,容易造成过度优化,不但没有解决之前的问题,还会引入新的问题。那如何度量技术架构的好与坏?如何拿捏技术架构演进的度?如何用目标驱动的方式做技术架构的持续演进?如何衡量技术架构演进的成果?如何进行架构守护?

解决方案:

通过识别架构演进度量指标,编写Architectural fitness function(适应度函数),以此量化及可视化系统架构演进效果,并通过持续反馈不断调整技术架构演进方向,避免架构演进脱离初始目标。

解读:

Architectural fitness function(适应度函数)借鉴自进化计算,被用来衡量方案对满足目标的适合度。

当定义演进式算法时,算法设计者会寻求更优解,而适应度函数则定义了在此上下文中“更优”的含义。

将适应度函数应用于软件架构,则为系统的架构演进提供了一个度量的目标,开启了“【目标(测试)驱动架构演进】”的新时代。 记住,如果你无法为系统演进、架构升级优化定义出度量的Metrics,并通过Fitness Function写一个测试来驱动和可视化你的架构演进成果。那就表明你还没有想清楚架构演进要解决的问题,就先不要开始!

《演进式架构》一书定义了架构适应度函数的概念,为衡量架构特征提供了一个客观全面的方法,包括已有的验证标准,比如单元测试、业务指标、监控等等。

感兴趣的可以了解一下。

工具:

ArchUnit:一个可以测试Java系统架构本身的测试工具,例如所有的Service只能被Controller或是Service调用的测试如下:

延展阅读


更多精彩洞见,请关注微信公共号:思特沃克

Share

Lightweight Architecture Decision Records | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(参考阅读:解读技术雷达的正确姿势

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第一篇,Blip是Lightweight Architecture Decision Records

位置

2018年5月第18期技术雷达,技术象限,建议试验

目标受众:

  • 系统架构师,技术管理者,开发设计人员

关注问题:

  • 传统的重文档编写维护量大,随着业务发展,很难保持同步
  • 在一些敏捷项目中,随着关键文档的缺失、项目Knowledge及决策丢失导致长生命周期的项目知识传递问题

解决方案:

  • 使用“ Lightweight Architecture Decision Records”(轻量级架构决策记录)来记录项目的重要决策,并将其与代码等其他项目资产一样,纳入到版本控制系统之中。

解读:

“项目要不要写文档”一直是一个很有争议的问题。在过去,项目一般都要写众多的文档,类似于需求说明书、概要设计、详细设计、数据库设计、等balabala设计……而这些文档的作用往往只是为了【过评审】或是【招投标】,写文档的形式也更多是简单的复制粘贴。

项目拿下了,过审了,一旦开动起来,文档反而就被束之高阁,再也无人过问了。

很多人没日没夜地写着千篇一律的文档、文档、文档……终于有一天,盼来了敏捷,并看到了敏捷宣言中硕大的一句:

(敏捷宣言)

唉呀妈呀,终于见到了亲人,从此高举着敏捷的大旗,与文档势不两立。

再有人敢提起写文档,就把早已准备好的“敏捷大棒”从身后掏出来,劈头就是一棒槌……

不得不说,敏捷又一次背了口黑锅。敏捷宣言所推崇的并不是简单的不写文档,而是认为之前那种写文档的方式根本没有体现出其应有的价值。还 不如代码写的漂亮些,测试写的完备些,让代码和测试成为真正有价值的活文档。

而这,相对于简单的复制粘贴攒文档,对于团队的要求反而更高了。

世间万物,物极必反。

随着时间的推移,再好的敏捷团队也会出现知识流失的问题,尽管有着完备的测试和易读的代码,但这些毕竟过于细节,无法快速还原当时设计或重构时的所有上下文。

所以技术雷达推荐使用“ Lightweight Architecture Decision Records”来记录项目的重要决策,相比于传统文档,它最大的特点就是轻量(Lightweight),关注于创造价值而不是遵循流程。 让我们看个ADR的模板:

(ADR Template)

同时技术雷达也建议我们不要将ADR束之高阁、放到Wiki或是文档库中。而是随着代码放到Git或其他版本控制工具里,这样既可以保持最大程度与代码同步,又能跟踪Decision的变更历史。

推荐的Adr-Tools工具,可以帮助我们更容易的做到这些。

相关Blip及延展阅读:

工具:

GitHub – npryce/adr-tools: Command-line tools for working with Architecture Decision Records

Share

一个AR Tech Radar的诞生

什么是AR Tech Radar

技术雷达是ThoughtWorks每年出品两期的技术趋势报告,一般来说大家看到的雷达都是文档形式,其中有一张技术全景图,以及每个技术点的成熟度分析。而AR技术雷达就是在原始文档的基础上,利用AR技术将其立体化呈现,并在其中添加互动元素。

为什么要做AR Tech Radar

  1. 技术雷达一直以来都是文档的形式呈现,如果能通过包含在内的最新技术呈现出来,岂不是更能体现技术雷达的意义。同时也能增加技术雷达的交互和科技感。
  2. XR Community作为AR/VR等技术的探索者,AR技术雷达是我们社区内部产品的第一步尝试。
  3. 我们也不知道为什么,就是想做AR Tech Radar。

AR Tech Radar的技术选型

目前市面上能做AR的技术有很多,基本上每家大公司都有自己的AR技术。为什么我们会选择ARKit呢?(ARKit是苹果做AR软件开发的一个工具,使开发者能为iOS设备开发增强现实应用。)

之所以选择ARKit一个很重要的原因就是懒,只想选一个学习成本比较低的技术。

其实AR技术强依赖于承载它的硬件,所以选择AR技术其实就是在选择硬件平台。我们期望能使用一个广泛的平台,让AR技术雷达被更多的人接触到。目前AR硬件平台使用最广泛,也最容易让用户接触到的就是iOS,所以我们选择了ARKit。

其中还有一些其他的人气技术,比如:

  • ARCore,它是Google推出的运行在Android上的技术,但目前只有几款顶配的Android手机可以运行。
  • Hololens,它是微软的AR眼镜,购买成本较高,很难被普通用户接触到。
  • Unity,它支持iOS和Android跨平台。

那为什么我们没有选择在unity上进行AR开发,让它同时支持iOS和android呢?一个原因是ARKit和ARCore是才出来的新技术,它在unity上的兼容性和使用上肯定有很多未知的坑,我们期望使用比较稳定的平台。另外一个原因是,我们期望尝试用原生开发,以便更深刻的体验AR开发的过程。今后我们会尝试使用例如unity等工具进行开发,然后和原生开发做一个对比。

如何开发AR Tech Radar

准备

ARKit是苹果的技术,语言首选是Swift。 硬件需要支持ARKit的一台Mac和一部iOS设备。因为ARKit不支持模拟器运行,所以必须使用真机进行全程的开发调试。 开发软件是Xcode。

前期构想

做AR开发需要有两部分准备,一部分是本身的编程,另外一部分就是3D建模和空间相关的知识。编程不必多说,只要会Swift就能开始。3D建模不是我们的长项,所以前期我们做了很多调查,比如自己使用3D建模软件做一个雷达模型,或者去购买别人做好的雷达模型,或者外包给第三方公司做一个3D模型,再或者找会3D建模的同学加入我们。

但这些方案都被我们否决了,原因有很多,比如我们的经费有限,不能支持我们去找外包,也没有现成的模型给我们购买。而自己去学习3D建模的学习时间也长,同时也没找到会3D建模的同学。

因此我们决定用ARKit支持的形状来组合一个雷达。

我们曾经设想过很多次AR技术雷达应该长什么样。

比如罗马斗兽场的样子,让技术每层递进。

或者是一个圆球,人站在球里面,被周围的技术包围,大概像这样:

再或者,它应该是一个立在你面前的展台,技术雷达就摆在用户面前,大概像这样:

最终这些想法都被我们暂时搁置了,最主要的原因是我们没有能力和人手去实现那些炫酷的样子,并且我们觉得技术雷达就应该用它最朴素的样子展示给大家,应该被大家关注的是技术雷达的内容,而不是这个3D物体。所以最终我们决定用一个圆饼来展示技术雷达。

开发

首先,3D建模不是我们的长项,所以我们选用了ARKit支持的基本形状来组合出一个技术雷达的大饼。因此,我们使用了一个圆柱体和三个圆管,如下图。正中间是一个圆柱,用三个圆管把圆柱包围起来,就形成了雷达圆饼。

接着,为了让整个雷达看起来更立体,我们使用了圆球来作为每个技术的标示点,同时让标题浮在圆球的正上方。如下图。

我才不会告诉你,每个技术标示点在第一版的设计中是圆锥形的,看起来像雷达上的一坨坨屎。请看下图。

然后就是添加交互,让用户在点击某一个圆球的时候弹出它的具体阐述。就像下图一样。我们在圆球的正上方弹出一个半透明白板,并把标题和内容放在上面。 白板上的字不同于圆球上的标题,它是印在平面上的,而不像标题是3D立体的。因为大段的文字不适合全部做成3D立体的字,这对资源的消耗和3D的计算是很大的。所以我们利用3D纹理贴图,把文字描述贴到了白板上。

数据

最后就是如何添加数据,我们希望这个AR技术雷达能运用到每一年的技术雷达,这就要求我们添加进去的数据是支持更新的。

所以我们使用了一个单独的文件来存储每一期的所有技术,文件内容包含了所有技术相关的信息,比如名字、详细介绍、它所处的象限、它的分类等等。

这样的好处就是下一次的雷达技术出来之后,我们只需要更新这个独立的文件就可以看到最新的AR技术雷达了。

3D开发过程中遇到的困难与趣事

遇到的第一个奇葩事件就是,第一次我们添加了一个物体,可是在摄像头里面怎么都找不到,后来我们无意中把镜头对着天空突然发现那个物体在空中飘着。原因就是ARKit世界里面的尺寸是和现实世界一样的,单位是米,而我们的离地高度设的是3米,因此它就跑到空中去了。

另一个和这个是相似的,我们加了一个圆管放在地上,可是在地上怎么也找不到那个圆管。后来我们才发现,我们的圆管的尺寸太大了,把我们全部包在圆管里面了。

第三个有意思的事情是,我们添加了一个平面,上面写了一些东西,可是我们在镜头里面却怎么也找不到这个平面。通过各种debug和调查研究,才发现,我们在平面的背面,原来对于没有厚度的平面,只能在正面才能看得见。

还有一个比较棘手的问题就是,比如有些物体需要旋转两个90度再加上一些变换才能达到我们想要的位置。这对空间想象能力的要求就比较高,我们尝试了很多种旋转和变换,才最终找到了想要的位置。

未来的发展

我们期望AR技术雷达能发展成为每次技术雷达发布的官方AR应用,通过不同的途径和不同的体验让更多的人了解技术雷达,让人们能和技术雷达有一些有意义的互动。

所以未来我们期望能不断完善AR技术雷达,让它成为一个炫酷的、交互式很强的应用。

打开脑洞想象一下,通过使用AR技术雷达,你不仅可以看到每次更新的新技术、还能够通过一些交互直观的看到它的历史轨迹、应用场景以及具体实践,是不是一件很酷的事情?


更多精彩洞见,请关注微信公众号:思特沃克

Share