当前位置：首页 > news >正文

架构师的角色期望

news 来源：原创 2024/5/2 15:01:45

导读：软件架构师的职责范围可以从专家级的程序员到定义公司的战略性技术方向。与其浪费时间去定义角色，不如专注于对软件架构师的期望。

对软件架构师有8项核心期望：

制定架构决策
持续分析架构
掌握最新趋势
确保决策被遵守
丰富的经历和经验
具备业务领域知识
具备人际交往能力
了解并驾驭政治

软件架构师这一角色的有效性以及是否成功的首要关键因素在于对这些期望的理解和实践。

1. 制定架构决策

架构师需要制定架构决策和设计原则，以指导团队、部门或者整个企业进行技术决策。

指导是第一个期望中的关键词。架构师应当指导而不是指定技术选择。例如，架构师可能会决定使用React.js进行前端开发，但这时，架构师做出的是技术决策，而不是可以帮助开发团队做出选择的架构决策或者设计原则。架构师应当要求开发团队选择基于响应式的前端开发框架，从而指导开发团队从Angular、Elm、React.js、Vue或者其他基于响应式的前端开发框架中进行选择。

通过架构决策和设计原则来指导技术选择并不容易。有效架构决策的关键在于，架构决策是否指导团队做出了正确的技术选择，或者是否替他们做出了技术选择。不过，架构师偶尔也需要做出特定的技术决策以维护某个架构特征（比如可伸缩性、性能或可用性）。此时，即使架构师指定了特定的技术，也仍然被视为一个架构决策。

2. 持续分析架构

架构师需要持续分析架构和当前技术环境，然后给出改进建议。

这条期望关注的是架构活力，由于业务变化和技术更迭，架构师需要对三年或者更久以前定义的架构在当下的可行性进行评估。从我们的经验来看，将精力集中在持续分析现有架构的架构师不够多。因此，在开发人员对代码或设计进行修改时，大多数架构都会出现不同程度的结构腐化。这些修改往往会影响架构特征，例如性能、可用性和可伸缩性。

在这条期望中，架构师常常忘记测试和发布环境。代码修改的敏捷性具有明显的好处，但如果团队需要花几周时间进行测试、几个月时间进行发布，那么架构师将无法在整个架构中实现敏捷性。

架构师必须从整体上分析技术和问题域的变化，以确定架构的稳健性。虽然这些考量很少出现在架构师的招聘启事中，但架构师必须满足这一期望才能保证应用程序与时俱进。

3. 掌握最新趋势

架构师需要掌握最新的技术和行业趋势。

开发人员必须时刻关注技术更新，从而保证与这些技术与时俱进。对架构师来说，掌握最新的技术和行业趋势更为关键。架构师做的决策往往更长久并且难以修改，了解并遵循一些关键趋势有助于架构师为未来做好准备，并做出正确的决策。跟踪并及时掌握趋势非常困难，特别是对于软件架构师而言。

4. 确保决策被遵守

架构师需要确保架构决策和设计原则被遵守。

确保决策被遵守意味着架构师需要不断地验证开发团队是否遵循了那些已经被定义、文档化并且交流沟通过的架构决策和设计原则。假设在一个分层架构中，架构师决定对数据库的访问进行限制，只允许业务层和服务层（而非表现层）对数据库进行访问。这意味着哪怕是最简单的数据库访问，表现层也必须经过架构中的所有层。用户界面的开发人员肯定不会同意这个决策，出于性能考虑，他们会直接从表现层访问数据库（或持久层）。然而，架构师之所以做出这样的架构决策，是出于一个特定的原因：控制变更。通过层与层之间的隔离，变更数据库就不会影响到表现层。如果不确保架构决策被遵守，此类违规情况就可能会发生，架构也就无法满足既定的架构特征，而应用程序或系统也就不会正常工作。

5. 丰富的经历和经验

架构师需要涉猎各种各样的技术、框架、平台和环境。

这条期望并不是说架构师必须是所有框架、平台和语言的专家，而是说架构师必须熟悉各种技术。如今大多数环境都是异构环境，架构师至少应该知道如何与多个系统和服务进行交互，无论它们是用什么语言、平台和技术实现的。

掌握这条期望的最佳方法之一就是不断地走出舒适区。仅仅专注于一个技术或平台是不行的，一个称职的软件架构师应当积极寻找机会通过接触多种语言、平台和技术来积累经验。掌握这条期望的一个好方法就是专注于技术广度，而不是技术深度。例如，对于一个架构师来说，熟悉10种不同的缓存产品以及每种缓存产品的利弊远比精通一种缓存产品要有价值得多。

6. 具备业务领域知识

架构师需要具备一定水平的业务领域专业知识。

一个称职的软件架构师不仅要了解技术，还要了解问题背后的业务领域。没有业务领域知识，就无法理解业务的问题、目标和需求，也就不可能设计出有效的架构。想象一下，身为一个大型金融机构的架构师却不了解平均趋向指数、射幸合同、利率反弹、非优先债务等常见的财务术语。不专业的架构师无法得到利益相关者和业务用户的信任，毫无竞争力。

最成功的架构师一定是那些具备广泛且实际的技术知识和特定领域的丰富业务知识的架构师。通过使用对方熟悉的领域知识和语言，这些架构师能够与高级别高管和业务用户进行有效的沟通。这种专业度会让高管和业务用户对架构师充满信心，如此才会有合作的可能。

7. 具备人际交往能力

架构师需要具备出色的人际交往能力，其中包括团队合作、引导和领导力。

对于大多数开发人员和架构师来说，掌握出色的领导力和人际交往能力是一项艰巨的任务。作为技术人员，开发人员和架构师喜欢解决技术问题，而不是人的问题。然而正如Gerald Weinberg所说的那样：“无论他们怎么说，总会存在人的问题。”架构师不仅要向团队提供技术指导，还要带领开发团队完成架构的实现。无论架构师扮演的角色是什么，领导力都是必不可少的。

行业内架构职位的数量有限，拥有优秀的领导力和人际交往能力能让你脱颖而出。许多架构师都是优秀的技术人员，但由于无法带领团队（包括不能辅导和引导开发人员，不能有效地就想法、架构决策和原则与开发人员沟通）而无法成为一个称职的架构师。

8. 了解并驾驭政治

架构师需要了解企业政治氛围并驾驭政治。

在一本关于软件架构的书中谈论谈判和驾驭办公室政治似乎很奇怪。为了说明谈判技巧的重要性和必要性，请考虑以下场景：一个开发人员决定利用策略模式，以降低特定复杂代码的整体循环复杂度。谁会在乎这个？人们可能会为开发人员使用了这样的设计模式而鼓掌，但大多数情况下，开发人员不应该为这类决定寻求批准。

再假设这样一个场景：有一个大型客户关系管理系统（CRM），由于有太多其他系统在使用它的数据库，这个系统的架构师在控制其他系统对CRM数据库的访问、保护某些客户数据以及对数据库结构进行修改等方面遇到了问题。因此，架构师决定创建所谓的应用程序孤岛，即每个数据库只能被拥有该数据库权限的应用程序访问。这个决策无疑可以让架构师更好地控制客户数据、安全和变更，但势必会给公司内的几乎所有人造成不便（当然，CRM团队可能除外）。其他应用程序需要客户管理数据，如果这些应用程序无法直接访问数据库，那么它们现在必须向CRM系统询问数据，因此需要通过REST、SOAP或其他远程访问协议来进行远程访问。

重点是，架构师所做的几乎每一个决策都会受到挑战。由于成本或工作量（时间）的增加，架构性决策将受到产品负责人、项目经理和业务利益相关者的挑战，也会受到认为自己有更优方案的开发人员的挑战。无论是哪种情况，架构师必须驾驭公司政治，并运用基本的谈判技巧，以使大多数决策得到批准。对于软件架构师来说，这可能会让人非常沮丧，因为作为开发人员做出的大多数决策都不需要被批准甚至不需要被审查。代码结构、类设计、设计模式选择、编程语言的选择等都是编程艺术的一部分。然而，现在终于有能力做出广泛且重要决策的架构师，却必须为几乎所有决策去辩护和斗争。

以上摘自：《软件架构：架构模式、特征及实践指南》

全面概述软件架构的方方面面

掌握软件架构的向导

推荐理由：本书是美亚广泛好评的英文原书《Fundamentals of Software Architecture》的中文版，是畅销书《卓有成效的程序员》作者Neal Ford的全新力作，NETSTARS CTO 陈斌等资深架构师鼎力推荐。本书全面概述了软件架构的方方面面，涉及架构特征、架构模式、组件识别、图表化和展示架构、演进架构，以及其他许多主题。