[科技资讯] Mobvista蔡超做客QCon+案例研习社，分享优秀架构师成长攻略

你还在担心如何成为一个好的建筑师吗？近日，摩维斯塔集团副总裁兼首席工程建筑师蔡超访问qcon+案例研究学会在线会议，为我们带来了答案。

来自mobvista的图像

蔡超拥有17年的软件开发经验，包括在惠普和亚马逊等世界级公司担任软件架构师/首席架构师超过10年。他领导开发了topanalyzer、惠普(中国)移动设备管理系统、亚马逊新的外部履行平台、亚马逊物流+系统、亚马逊全球客服系统和大型灵活集群管理平台spotmax。基于多年的实践经验，蔡超总结并分享了他关于建筑师成长的八点建议，带给同行更多的思考。

右图一是蔡超，莫vista集团副总裁兼首席工程建筑师

以下是蔡超的分享内容:

到目前为止，我已经工作了17年，在此期间，我不仅在惠普和惠普、亚马逊等世界级团队中担任架构师，还在惠亮科技等快速发展的企业中担任技术领导。基于十几年建筑师的经验，我和大家分享一下这几年的成功和失败，希望能帮助大家避免我踩过的坑。

提问很难解决

作为技术人员，我们往往习惯于给出设计方案，成为问题解决者，却很少成为问题呈现者，思考设计什么。团队之间最常见的典型矛盾是产品团队和R&D团队之间的矛盾。作为R&D团队，我们经常抱怨产品团队的需求不合理，我们不懂技术。

事实上，我们可以努力推进我们的工作，不仅仅是设计满足产品需求的架构，还要满足客户的需求，甚至发现潜在的需求。

当你成为一个在设计中提问的人，你会发现提问也是需要深度思考的，设计一个好的问题有时候甚至比解决问题还要难。

即使是软件开发领域的大神小弗雷德里克. p .布鲁克斯也会有同样的感叹，设计最难的部分是决定设计什么。这句话来自他的书《设计的设计》。

决定你不想要什么比决定你想要什么更难

也许是因为人类的贪婪，我们也想要更多的软件系统:更多的功能，更好的性能，更好的可扩展性，可扩展性等等。作为一名软件架构师，你应该明白软件架构设计实际上是一种权衡或平衡。当每个人都在添加东西的时候，建筑师应该是说不的人。

在软件设计和定义的过程中，有很多权衡，比如改进功能和早期发布、可扩展性和性能之间的权衡等等。如何做好选择？著名的cap原则是一个很好的权衡指导策略。为了保持架构风格的一致性，架构师应该在一开始就根据系统的实际需求定义一些权衡原则，比如:数据一致性优先级最高，核心功能提前发布比完全发布好。

非功能性需求决定了架构

很多设计师可能认为架构是由要实现的功能需求决定的，但实际上真正决定软件架构的是非功能需求。因此，架构师需要更加关注非功能性需求，比如性能、可伸缩性、可扩展性和可维护性，甚至包括团队技术水平和发布时间需求。能达到功能性要求的设计方案很多，只有考虑到非功能性要求，才能筛选出最合适的设计。

面向模式的软件架构为不同的非功能需求提供了很好的参考和指导，多年来一直是架构师必读的经典。下面的架构模式来自本书第一卷。图中的微内核模式更注重可扩展性和可用性(错误隔离)。

简单不容易

许多建筑师经常谈论保持简单，但有时我们倾向于混淆简单和容易。简单和容易在英语中是两个不同的词:简单和容易。

Steve & middot乔布斯曾经说过，简单可能比复杂更难:你必须努力让你的思维变得清晰，让它变得简单。但最终这是值得的，因为一旦你到了那里，你就可以移山。要想真正简单，你必须深入。

真正简单的方法往往来源于对问题和技术的更深入的理解，简单可以说蕴含着深刻的独创性。我举个例子。

数据显示，在一个软件系统的生命周期中，成本消耗的最大部分往往在于维护。所以维修部分如果能简化，对整个项目来说都有全局意义。

我们为移动运营商开发了一个系统设备管理系统，移动运营商希望通过这个系统来管理移动设备。因此，系统需要实现设备自动注册、固件和软件同步等管理功能。这些功能可以通过管理系统和移动设备之间的一些预定义交互协议来实现。在这个过程中，电信专家会根据业务场景和需求来调整和添加这些交互协议。一开始我们采用了一种简单的方式，就是团队中的软件工程师按照电信专家的指示，将协议实现为相应的代码。

但是我们很快发现，这种方式不仅没有让项目变得更容易，反而让我们的工作变得更加复杂。

我相信软件项目最难的部分，也是项目失败最常见的原因，是与客户和软件用户的沟通。-马丁·福勒

正如软件开发大师martinfowler所说，沟通往往是导致软件项目失败的主要问题。这个项目最大的问题是，在系统上线后的运维阶段，电信专家和开发工程师会在新的协议上不断修改和增加持续的通信。但由于双方知识和词汇差异较大，通信效率较低，系统维护(协议修订)变得非常困难，协议更新上线缓慢。同时，由于软件工程对电信协议的理解有限，很多问题往往是实际上线后才暴露出来，导致很多交流和重复。

为了解决这个问题，我们与电信专家一起设计了一种协议设计语言(并提供了可视化工具)。这种设计语言使用电信专家熟悉的词汇，然后通过类似编译器的程序将电信专家定义的协议模型转换成内存中的java结构。因此，整个项目的运营和维护变得简单高效，消除了低效的沟通和不准确的人工转换。

不难看出，最初直接按照电信专家的指令来实现协议似乎更容易，但在整个软件生命周期中并不是一种简单高效的方法。

永不停止编码

架构师也是程序员，代码是软件实现的最终形式。停止编程会让你逐渐忘记自己作为程序员的感受，更重要的是忘记痛苦，很容易导致一些不切实际的设计。在亚马逊，高级副总裁级别的杰出工程师，如被称为java之父的詹姆斯·高斯林，每年拥有不下10万条线路。

风险第一

架构设计中的一个重要点是识别可能的风险，尤其是非功能性需求实现的风险。因为这些风险往往不像功能需求那样容易在早期被发现，修正的成本要比修正功能需求的成本高得多，严重的情况下甚至可能导致项目失败。

因此，我们应该在原型或早期迭代中识别风险，并通过合理的架构来解决它们。永远不要把风险放在最后，即使一个项目要失败了，也要让它迅速失败，这也是一种敏捷。

从问题开始，而不是技术

技术人员对新技术有着与生俱来的热情，总是愿意学习和使用新技术。这很容易导致一个常见的问题，就是当我们有锤子的时候，什么都是钉子，所以我们用一些不合适的技术去解决手头的问题，导致简单问题的复杂性。

我以前的团队也发生过类似的事情，本来是用mysql做数据存储的简单服务。但是因为当时项目负责人对新的dynamodb产生了兴趣，学习了相关知识，所以成员决定用dynamodb代替mysql。

之后发现dynamodb不能很好的支持交易。当时只有一个性能很差的客户端类库支持事务，由于客户端模式，引入了大量额外的交互，导致性能差异高达7倍。

该成员当时采用了当时nosql领域广泛流行的最终协议技术，通过一个pub-sub消息队列实现了最终协议(即当一个对象的值发生变化时，会产生一个事件，然后关注这个变化的逻辑，订阅这个通知，并将其更改为相关数据，从而实现不同数据的最终协议)。

然后，由于dynamodb不能提供像sql那样方便的查询机制，为了实现数据分析，必须引入emr/mapreducejob。

在这一点上，我们可以看到，虽然最终实现了相同的功能，但项目的复杂性大大增加，维护工作从一个人变成了一个团队。

过度忙碌会让你落后

对于it人来说，加班是家常便饭，996似乎是公司高效率的象征。但实际上，日以继夜的忙碌往往会挤压我们的学习时间，导致我们失去更新知识的意识，不自觉地变得落后，最终失去跳槽的能力和勇气。

在当今飞速发展的时代，我在工作经历中发现，太忙往往会带来以下问题。一是学习不足，难以提高工作能力，无法面对日益复杂的需求；其次，我们失去了技术和业务上的领先优势，只能被动追赶，这样会让我们更忙，最终形成恶性循环。

个人技能的成长就像健身一样。光锻炼是不够的。营养补充同样重要。当你在一个领域工作一段时间，工作主要是为你练习。随着你对这个领域的熟悉，你学到的技术会越来越少。所以每个技师都要保证足够的学习时间，否则很容易成为井底之蛙，陷入上述恶性循环。

最后，有了大诗人屈原的诗，我们可以彼此分享很长一段路，我也会走上走下。我希望我们都能不要忘记你的首创精神，保持我们的独创性！

本文来源于，由编辑整理上传。请勿转载！

本文网址:http://www ./tech/hlw/2020/0918/27083

声明:本文仅代表作者本人，是一个信息发布平台，仅提供信息存储空客房服务。