按需求构建架构才是正确之举，过度工程只会“劳民伤财” | 独家专访 Thoughtworks 全球 CTO

Thoughtworks 成立于 1993 年，目前已在近 20 个国家开设办事处，拥有 1 万多名员工。多年来，Thoughtworks 一直在为敏捷软件开发、持续集成、持续交付、微服务、演进架构和数据网格等方面提供服务，最早为复杂软件项目开发敏捷的公司之一。

多年来，Thoughtworks 技术雷达峰会一直是业界知名的“技术风向标”。峰会由一群资深技术领导组成的技术顾问委员会创建，他们定期开会讨论 Thoughtworks 的全球技术战略以及对行业有重大影响的技术趋势。

借此技术雷达峰会之际，InfoQ 有幸采访到了Thoughtworks 全球 CTO Rebecca Parsons，请她来跟我们聊一聊技术雷达发布这么多年，它希望给大家带来什么样的价值？未来有哪些技术趋势值得关注，以及一名技术人应该如何保持技术前瞻性等话题。

在 1999 年加入 Thoughtworks 之前，Rebecca是一名计算机科学研究员和大学讲师。完成硕士和博士学位后，她主要从事编译器、程序优化、分布式计算、程序设计语言、计算理论、机器学习和计算生物学等方面的研究。

2007 年，她成为了 Thoughtworks 的首席技术官。除了深度技术，她还倡导行业的多样性和包容性，特别是增加编码和 STEM 领域的女性数量。

以下为访谈实录，InfoQ 在不改变原意的基础上做了编辑。

InfoQ：很高兴能有机会采访您，能先向 InfoQ 的读者介绍下您自己吗？

Rebecca：我是 Thoughtworks 公司的首席技术官，虽然不想承认，但我从事计算技术行业确实很久了。但我一直很享受这个过程，我觉得自己是那种典型的极客。

我的技术关注方向很广，博士论文研究的是编程语言和编译器优化，在并发和分布式系统以及进化计算、特别是遗传算法方面也做过很多工作。另外还有计算生物学，总之我对计算有着广泛的兴趣。

我是 1999 年 12 月加入 Thoughtworks 的，从 2000 年正式开始了我的工作。最近，我参与撰写了名为《Building Evolutionary Architectures》的新书，目前正在做第二版修订。

InfoQ：技术雷达峰会持续发布了多年，您希望技术雷达给大家带来什么样的价值？

Rebecca：其实技术雷达是大家合作的成果。最早是有内部销售人员问我们，目前哪些技术最酷。我们就这个话题认真讨论了一番。实际上，当时担任技术顾问委员会技术助理的 Darren Smith 才应该是“技术雷达”这个概念的提出者。但大家不会分那么细，基本就是群策群力的结果。当时有位委员会成员在跟一位英国朋友交谈，对方说“我很好奇 Thoughtworks 在雷达里盯着什么”，这句话给了我们最大的启发。

于是技术雷达就这么诞生了。我觉得它给大家带来的价值主要分三点。首先，技术雷达覆盖全世界，所以这里汇聚了来自印度、中国、巴西、北美乃至欧洲的技术资讯，世界各地的技术人都有机会做出贡献。但我们也发现，有时候大家对同一种技术的观点会大相径庭。我还记得，有次一个英国小组想叫停某项技术，但另一个印度小组则觉得应该大力推广。在深入研究之后，我们发现双方面向的客户完全不同，所以对技术的使用方式也差异巨大。所以我才觉得，必须要始终保持这样的全球视角。

第二点，我觉得是扎实的实践经验。这种经验不可能单靠跟供应商或者分析师聊天就得到。说明文档里呈现的当然也是经验，也可以很好用，但它还没有真正转化成你自己的财富、你也不一定能够用得得心应手。

第三就是，我们会明确表达自己的态度。总体上，技术雷达是更支持开源技术、相对弱化商业产品的，而且都是用实实在在的安全性和数据说话。毕竟如果没有好的隐私保护手段和鲜明的架构系统设计思路，就不可能建立起优秀的架构方案。

这就是我们在技术雷达中的一贯坚持。

InfoQ：您从 1999 年就加入了 Thoughtworks，这么多年的工作经历中，您感受最深的技术变革是什么？

Rebecca：我感受最深的技术变革有两次，而且区别很大。

刚开始接触商业技术工作时，我发现如果不借助数据库，我们甚至没法把任何一条数据写进磁盘里。当时，大家都觉得一切数据都是彼此相关的，所以会把数据全都“塞进”关系数据库。后来那些互联网巨头，谷歌啦、Netflix 啦，他们的出现才真正打破了这种心态，让人们开始相信，并不是所有数据之间都有关联。

比方说，我们也可以把图存在传统数据库里，但这并不能体现图属性。而在产品目录这类新技术中，所容纳的属性就丰富得多了，也能被轻松放进文档数据库当中。所以对我来说，这标志着我们对计算的观点有了根本性的转变。就是说在有了关系数据库之后，我们又遇到了新的问题：我们需要保留什么样的数据？要如何查询这些数据？哪种持久性技术更适用？这些问题的提出，代表着真正的思维转变。

至于第二个变革，就是当我们有了持续交付的基础之后，就会立足整个部署管道、测试自动化体系尝试推广自动化。这也让我们闯出了一条新的，以往根本无法想象的试验性构建道路。以前，没人敢想象微服务架构这种东西——手动录入几十上百项微服务的部署脚本，根本就不可能也不安全。过多服务代表着我们向架构中引入了过多风险，所以没人这么干。也正是系统部署的难度太大，才让我们没法在系统组织方面做出天马行空的探索。

但现在这些限制都被打破了，只要遵循持续交付原则，就能把系统拆分成一个个模块。哪怕面对几百个模块，自动化技术也能把部署难度始终维持在很低的水平。毕竟计算机可不在乎自己要干一件事，还是一百件事。于是乎，我们不用再考虑约束条件，可以纯粹从部署和运营的角度选择最适合的架构解决方案。

所以对我来说，这就是计算技术领域出现的两次根本性转变。有了这些质变，其他的量变也会接踵而来。

按需求构建架构，过度工程只会“劳民伤财”

InfoQ：在数字化转型大背景下，除了基础软件一些热门话题外，人们也比较关注可进化的架构，您认为构建“可进化的”、可面向未来（十年）发展的架构的关键是什么？

Rebecca：要说可进化架构，我觉得最重要的一点就是,关注自己想通过架构实现怎样的结果。具体实现永远是为结果服务的。

作为一名企业架构师，我的工作就是确定到底需要把可扩展性、安全性或者弹性做到什么程度。我不会具体指定必须使用哪种负载均衡器，只会定下合理的负载强度目标。所以如果大家能把注意力从具体实现转向规范性目标时，最终成果反而会更好，因为这样系统构建团队既有灵活空间、又有明确方向，他们自己知道怎么做选择。弹性啦、可扩展性啦，这些都是客观的衡量标准。

有了这样的指引，系统团队就能权衡不同的架构选择会给结果造成怎样的影响。而且面对新技术，大家还是会以结果倒推方案 — 符合架构需求，那就用；如果不符合，那再新的技术也没有意义。所以这样我们的架构会更灵活，我们可以专注于需要实现的目标，不再纠结于特定时间、特定位置到底要用哪些特定方案。

这就是构建可进化架构时，必须完成的心态转变——以结果为导向。我不在乎你具体怎么做，但它必须能达成特定的正常运行时间或者可扩展性。要求明确之后，身处一线的团队更了解该怎么做取舍。他们可以自由选择技术，决定自己怎么把目标变成现实。

InfoQ：所以您的意思是，一定要防止过度工程，对吧？

Rebecca：没错，但很遗憾，我经常见到过度工程、过度设计的系统。不是每套系统都需要 99.999%的可靠性，也不是每套系统都需要应付谷歌那样的负载规模。我们构建的系统能满足自身需求和合理预期就够了，干嘛非要做得跟 Netflix 一样夸张？

InfoQ：那您能不能分享几个过度工程、产出又不高的案例？

Rebecca：在关于可进化架构的演讲中，我最爱举的例子，就是我们当初在英国开设办事处的故事。我们当时有家英国客户，他们运行着一套三明治外卖系统。每天早上，食客可以在系统上下单，再由他们负责送货，客户的信用卡信息也不会被存储到他们的系统里。

我们的办公室就在伦敦中心区，所以只要这套系统出了问题，我们下楼看看门口那些三明治店，就能马上发现端倪。这根本就不涉及保密的问题。我每天早上都会下单点个三明治加鸡蛋，订单里没有个人身份信息、也没有信用卡信息，所以完全不需要加密。即使系统停机维护，我也只需要下楼亲自去趟门店就行，根本没啥影响。对于这么简单的系统，用 rails 之类的开发就够了。客户创建的订单会留存一段时间，再到当周末集中删除。总之，这天然就是一套最最简单的系统，没必要硬塞一些复杂的功能进去。

我还经常提及另一个案例。当时我们为客户构建了一套交易系统——一听到交易系统，很多人首先就会想到“高频交易”，就是频率超高、延迟极低之类的。但大部分交易系统其实没那么复杂，每天只需要处理 100 次左右追踪交易。所以性能并不是大问题，反倒是交易成功率才是重点，毕竟每笔交易的金额都高达数十亿美元。

所以情况就跟第一印象完全不同了，这类交易系统跟高频交易系统根本不在一个次元。所以我们还是要回归眼前的现实问题，思考怎么解决、为系统引入哪些特性，这才是根本。

InfoQ：面对当前的数字化转型潮流，传统和金融企业在数字化过程中往往对分布式架构或微服务架构望而生畏，您给他们的建议是什么？

Rebecca：我经常引用 Martin Fowler 写过的一篇文章，谈的就是微服务架构的适用门槛。对，微服务架构相当复杂，是有适用门槛的。

我自己也在一篇文章中，解释过为什么我们永远不会在技术雷达上使用微服务。虽然微服务确实能解决某些特定问题，但架构本身的复杂性却大大增加了。就像你提到的分布式架构，它们真的非常复杂。如果采用结构更简单的其他高质量模式，很多故障压根就不会发生。

所以组织得先明确自己能从微服务架构中得到哪些好处。这些分布式架构或者说微服务架构当然很有价值，但你得证明由此带来的额外复杂性物有所值。各个微服务可以独立扩展、功能灵活，这些都是真实的优点，但同时也会给 IT 部门带来更大的运营负担。

我之前也提到过，持续交付才是真正的核心，所以如果保证不了这一点，微不微服务根本没有意义。所以如果 IT 部门已经非常成熟，那不妨放心大胆地去用微服务架构；但如果原本的模式就已经完全够用，何必还要自寻烦恼呢？万一 IT 部门根本搞不定微服务模式，那只会把本来好好的业务弄得一团糟。

所以还是认真想想微服务架构到底有什么好处，在组织里到底能不能发挥不可替代的价值。把收益和成本权衡一下，相信大家自有答案。

构建负责任的技术迫在眉睫

InfoQ：您在技术雷达峰会上谈到要构建负责任的技术，怎么理解您这个演讲主题？“危险技术”不是近几年才出现的，之前也有，那么为什么会选择在这样的时期谈这样的话题？

Rebecca：对我来说，技术的最大意义在于,它能给人们的生活带来怎样的改变。我倒是没有被技术所累，最多也就是根据亚马逊上的推荐买东西，而且我还是挺喜欢那些推荐的。真的没什么大问题。但其他一些关键领域，比如医疗决策、刑事司法系统、信用评分、欺诈检测、人脸识别等等，与此相关的错误会造成严重后果，我们自然不能对相应的技术掉以轻心。

作为技术人员，我们需要考虑一旦自己犯了错，最终会造成怎样的影响。我们能承担后果吗？我们真的了解系统训练中所使用的各种数据吗？关于偏见，我经常会举这样一个例子。虽然偏见并不一定就有恶意，但影响仍然不容忽视。一家医院打算训练一套模型，指导医学生们如何设计患者的术后恢复方案，特别是需不需要将患者送入重症监护室（ICU）。结果，数据集中的素材对哮喘患者存在偏见，所以会自动将所有哮喘患者都送进 ICU。

事实证明，这套数据集里根本就没有关于哮喘患者的信息，这些患者是在不同的医疗系统下接受诊疗的。但院方在训练模型时并没有考虑到这一点，所以模型对哮喘症状一无所知。随着时间推移，如果有医院真的直接使用这种模型，那么肯定会引发很多“药不对症”的问题。这套模型对哮喘病人当然没有恶意偏见，只是院方没有认真筛查模型训练所使用的数据集。我们在实际工作中，接触过很多出现类似问题的系统，所以我才觉得负责任技术是个非常重要的议题。

好在现在的我们还拥有关于理性决策的集体记忆，及时纠正未为晚矣。

InfoQ：在这个话题下，您认为有哪些有负面效应的技术应该着重关注和探讨？

Rebecca：其实万事万物都有负面效应。我觉得最大的负面效应，其实来自因为对底层数据的不理解而做出的错误决策。不单是做出错误决策，甚至会强化这些错误、让下一次做出错误决策的可能性提高。毕竟强化学习的基本原理就在于此。

而从另一个方面出发，随着自动化水平越来越高，很多系统当中发生问题的速度也越来越快。如果整个循环中还有人的要素，那至少要等他们按下“确认”按钮、或者输入某些指令。但如果是机器对机器交互，这些延迟就将不复存在。这样我们得到的就是快速升级的反馈循环，错误会令交易业务的公司在几分钟内就宣告破产。这就是算法出错造成的危害，整个组合将会瞬间灰飞烟灭。而如果其中有人的参与，这些问题就不会发生。

所以我们必须要建立起这样一种更可靠的自动化循环，否则早晚会发生意想不到的情况、那种我们根本无法预测自动化系统会作何反应的情况。自动驾驶就是典型的例子。目标似乎很简单：让汽车沿着高速公路行驶，躲避其他汽车并保持在车道中央。这事很难吗？但行驶过程中往往会出现一些意外状况，比如一只鹿突然窜上马路，或者有人破坏了行驶标识、导致系统无法正常识别。对于这类全自动化系统，我们必须全面思考它们犯错的可能性，并在系统中设置断路器，确保能在意外后果发生前将其关停。

InfoQ：技术带来的负面效应常常是不可预测的，那么您认为对于一般企业来说可以采取哪些管理措施或框架、工具让技术变得更加负责？

Rebecca：确实，所以我们才发布了《负责任技术手册》，大家可以在我们的网站上看到。其中包含一系列促进技术，能帮助开发团队有效打破自己的固有观点，从其他不同技术人员的视角看待问题。是的，在讨论负责任的技术时，我们会从问题出发。

我们会先搞清楚问题是什么，再看看问题会影响到哪些人，也就是我们需要帮助的对象。我们还会站在受影响者的立场上思考，比如他们可能需要什么？他们可能有哪些顾虑？这份手册中的方法并不全是我们自己想出来的，我们只是收集了这些思路并整合起来，同时注明相应来源。有了如此丰富的促进技术，我们就能更全面地审视自己的技术选择、考虑这些选择可能产生的影响。毕竟技术本身没有立场，所以无法预判实施之后会带来哪些意外后果。

这就是负责任技术理念的意义所在。作为技术人员，我们至少有责任想得远一些，预测技术实施可能引发哪些意外后果。也许没什么后果，也许能改善产品并扩大目标市场，这些都是比较好的结果。但某些意外后果也可能伤害到其他人，也许有办法可以提前预防或者缓解，这就是我们身为技术人的责任。

“对技术的热爱，让我走到了今天”

InfoQ：看到您从高中开始接触编程，最早接触编程的契机是什么？

Rebecca：当时我在学代数，我们的高中数学老师正好在当地大学里学习编程。他买了本教科书，记得当时是 1974 年，我正好在读高中。他也送给我一本教材。那时候学校里有一台键盘穿孔机。不知道为什么，我们学校从来没开过这门课，但我可以用这台机器编写程序再录入到打孔卡里。之后，代数老师会把我的卡片带到大学，在上课的时候试着跑一跑，我就这么学会了编程。靠着代数老师学编程的这本教材，我第一次接触到了编程。

InfoQ：那你第一次编程的时候感觉怎么样，喜欢吗？

Rebecca：喜欢啊。我很少回忆过去，但我还清楚记得那种能用电脑解决问题的感觉。这是一种截然不同的问题思考方式，真的很令人着迷。顺着这种方式，我们就得到了程序，我特别喜欢这种感觉。

InfoQ：那个时候，你认为数据会改变世界吗？

Rebecca：与其说是数据，不如说是技术可以改变世界，当时的我倒是相信编程和技术可以改变世界。

因为这些是实实在在的工作，能让事情变得更好。我们可以用程序处理账户、应收账款、工资单之类的工作。对于这些简单的结构化任务，当时的人们还没法直接编写公式统一解决。但程序可以，所以这是种革命性的飞跃、能够让这个世界变得更美好。听起来有点幼稚，但那时候我们确实是这么认为的。

InfoQ：您所关注的技术范畴也很全面，您是如何保持学习的热情以及维持住技术“前瞻性”的？

主要是因为我身边总有一群同样热爱技术的伙伴。现在我还主持着一档播客节目，我特别喜欢录制播客的过程，因为大家可以坐在一起，共同讨论彼此关注的某些技术话题。

在这一个小时里，我会以主持人的身份交谈、感受他人对于某些技术细节的激动之情。所以我们才会每年举行两次技术雷达大会，在这里大家可以接触到更广泛的技术工具、平台和方法。这就是我保持技术热情的方式。

InfoQ：要保持技术前瞻性，我猜唯一的诀窍就是保持学习、永不止步，对吗？

Rebecca：没错。

InfoQ：作为 Thoughtworks 的 CTO，这个角色对您来说所面临的挑战来自哪里？

Rebecca：我刚开始从事技术工作时，CTO 的身份多少有点像记者，只需要在操作系统、编译器、数据库和应用程序当中做选择就行。但现在的技术领域太过广泛，所以记者型的CTO已经不成立了，任何特定类型的技术都会引发相应类型的问题。

比如说，当我们面对物联网系统，那有些问题就可以直接忽略；但在使用云端服务器时，同样的问题又变得至关重要。整个技术生态已经比当初复杂太多了。所以我会从思路、成效等多个角度审视这些技术，理解它的内涵。

Thoughtworks 公司体量不算太大，目前有 11000 名员工，但也已经不小了。那埃森哲呢？他们有 40 多万人。所以我们必须对自己的选择、对可能给客户带来重大影响的技术保持严谨且挑剔的态度。我一直在担心自己的某些技术判断会不会出错。我最怕自己做的决定搞得客户们怨声载道，绝对不能出现这样的事情。

总之，随着技术环境变得愈发复杂，客户使用技术的方式也越来越广泛。多年以来，大家已经习惯了在特定类型的应用场景中部署传感器网络，但以往这些系统只适用于某些特定问题，现在却需要朝着普遍适用的方向发展。身为 CTO，我觉得现在选择技术方案的难度确实越来越大了。

InfoQ：大部分开发者/工程师工作几年之后，都会面临是否转做技术管理的选择。很多人会对此感到迷茫，他们的问题可能包括“要不要转技术管理”“我是否适合做技术管理”或“如果不做管理，继续在一线做开发有前途吗”等等。开发者如何做出正确的选择，不同的选择分别有哪些方面需要注意，能否基于您的经验（包括您自身的经验和您所管理的团队成员的经验），给大家一些建议？

Rebecca：这个要分几点来看。首先，有些人比较像独行侠，我行我素、不爱跟团队打交道。但也有些人特别喜欢在团队中工作，却并不愿意承担管理事务。这些都很正常，但有时候却会限制一个人的发展空间。

这也是大家从事技术管理工作的最大障碍。身为开发人员的时候，我们面对的都是能够快速反馈的问题：代码编译成功了吗？测试通过了吗？一个个非常具体的指标可以清晰衡量工作成效，让我们感受到自己的进步。如果测试没能通过，我们就回头修复，也无所谓。但身为技术管理者，这种比较直接的成功开始逐渐消失，我们可能在很长一段时间里都无法确定自己做的事对不对。这对很多人来说最难适应，因为他们习惯了自己做对的事、而不是指导别人去做对的事。

我觉得这确实需要重大的心态转变，但回到之前你提到的保持技术热情的问题。我觉得大家就算走上了技术管理岗位，也仍然需要保持住技术水平，这样对工作更有帮助。也只有这样，技术管理者才能区分技术的好坏，理解团队成员有哪些不足、他们面临怎样的问题、又该如何提供帮助。

所以在我看来，不管是做纯技术还是涉足管理，对技术保持热情都是最重要的前提。

InfoQ：开发者这个行业里其实男性从业者居多，但您做到了 CTO，也有不少著作，建立了非凡成就，多年来，您是如何平衡事业和家庭的？是否能给大家一些女性成长上的指引或心得？

Rebecca：女性在科技行业的发展道路仍然很艰难。我是个铁杆极客，所以从没动过退出的念头，唯知一路奔驰。但对其他很多女性，这些阻碍确实会影响她们的感受、甚至迫使她们退出。要想坚持下来，最重要的还是对持续学习新事物的那种强烈期待吧。另外，培养起坚守自我价值、忽略噪音的能力也很有帮助。

真正让我坚持下来的，还是对技术的热爱。我喜欢学习技术，探索技术的使用方式。

我喜欢学习新技术、喜欢跟大家一起工作。对于自己热爱的事物，我们同样得做出权衡，弄清楚哪些最重要。让我感到遗憾的是，很多男性技术工作者可以出于丰厚的报酬和有趣的工作内容坚持下来，同时期待能有更大的上升空间；但对于女性，他们的评判标准又变了，似乎好工作突然就变得不那么好了。所以在技术场合下看到女性，很多人的第一反应会觉得对方是秘书，“给我来杯咖啡”这种。我就遇到过类似的情况，他们觉得出现在办公室里的中年女性，肯定不可能是搞技术。

所以如果大家对技术像我一样充满热情，那就请坚持下来，这一切都是值得的。但如果在你眼中，这单纯只是一份工作，那不如去找个项目经理之类薪酬差不多的岗位。确实，在技术行业里女性还是会多少受到一点歧视和冒犯，这个是有的。

总之，现在整个行业在多样性和包容性方面已经做得越来越好了。但如果各位女性朋友对技术没有热情、只是单纯想找份好工作，那可能还是不太适合。

InfoQ：非常感谢您接受我们的采访！

Rebecca：谢谢。

嘉宾简介：

Rebecca Parsons，Thoughtworks 全球 CTO