GitHub热门：程序员的架构师封神之路，头条三面技术四面HR

GitHub 趋势榜第一的项目来自架构师 Justin Miller，他分享了自己关于「如何成为更好的软件架构师」的想法，这个 repo 现在已有 5.4k star。

几年前有人问我：「你是怎么成为一名软件架构师的？」我们就此探讨了必备技能、经验，以及储备相关知识所需的时间和精力。除此之外，我也回顾了自己走过的路、使用或尝试过的技术，以及我从那些五花八门的工作中学到的东西。

软件架构师是什么？

在进行深层次的探讨之前，我们先来看两个定义：

• 软件架构师：是指那些制定高级设计决策，并确定技术标准（包括软件编程标准、工具和平台）的软件专家。这之中的首席专家就是总架构师。（来源：Wikipedia: Software Architect）
• 软件架构：是系统的基本组织构成，这种组织主要体现在其组件、组件之间的关系、组件与环境之间的关系，以及决定系统设计与演化的原则。（来源：Wikipedia: Software Architecture）

架构的「层级」

架构主要可以抽象成以下几个「层级」。不同层级所需的技能也不同。尽管对层级的分类有很多种标准，但是我最喜欢把架构分成 3 个层级：

• 应用级：最低层级的架构。只关注单一的应用。层级低，但是很详细。这方面的交流一般是在一个开发团队内展开；
• 解决方案级：架构的中间层。关注一或多个满足业务需求的应用（也就是商业方案）。这之中有些设计是高层次的，但大部分还是低层次的设计。这种层级架构的交流就开始涉及多个团队了；
• 企业级：架构的最高层级。关注多个方案。这种架构的设计层次高且抽象，因此也需要方案级和应用级的架构师对此进行细化。这种层次的架构就需要多个组织进行沟通了。如果你想了解更多，可以参阅这个链接：https://github.com/justinamiller/EnterpriseArchitecture。

有时候，架构师也被看做不同工作组之间的粘合剂。以下是三个例子：

• 横向：在业务部和开发人员或是不同的开发团队之间架起沟通的桥梁；
• 纵向：在管理者和开发人员之间架起桥梁；
  -
  技术：将不同的技术或应用整合在一起。

软件架构师的日常

要了解架构师的必备技能，我们得先知道架构师主要做什么。我认为架构师最重要的活动包括：

• 定义和确定所需的开发技术与平台；
• 定义开发标准，如编程标准、工具、审核流程、测试方法等；
• 对确定和理解业务需求提供支持；
• 设计系统并根据需求做出决策；
• 对架构定义、设计和决策进行讨论记录；
• 检查并审核架构与代码，比如检查前期确定的模式与编程标准是否被正确实施；
• 与其他部门和架构师合作；
• 对开发人员的引导及咨询；
• 将高级设计细化，并转化为较低级的设计。

注意：架构设计是一项持续性的工作，尤其是在敏捷软件开发过程中。因此，我们会一遍又一遍地重复这些工作。

软件架构师必备技能

为了完成上面说的那些工作，架构师需要具备一些特定的技能。从我的个人经验、相关书籍和讨论中，我们可以将其总结为以下 10 项技能：设计、决策、简化、编程、记录、沟通、估算、平衡、咨询、市场。

接下来我将逐一介绍这些技能。

设计

首先最重要也最难回答的问题就是「什么是好的设计」。我将从理论和实践两个层面进行阐述。就我的经验来说，两者兼备才是最好的。那我们先说一下理论层面吧：

• 了解基本的设计模式：模式是架构师开发可维护系统所需的最重要工具之一。基于这些模式，你可以把一些已经在其他问题上奏效的方案迁移到一些模式相同的新问题上。「Gang of Four」(GoF) 所著《Design Patterns: Elements of Reusable Object-Oriented Software》是所有从事软件开发的人的必读书。尽管这些模式发布于 20 多年前，它们仍是现代软件体系结构的基础。例如书中的模型 - 视图 - 控制器（Model-View-Controller，MVC）模式就被应用于许多领域，它同时也是一些新模式（如 MVVM）的基础；
• 再挖深一点，研究一下模式与反模式（anti-pattern）：如果你对 GoF 所写的模式具备全面的了解，那么你就可以学习更多的软件设计模式了，或者深挖你感兴趣的领域。在应用集成领域，我最喜欢的一本书是 Gregor Hohpe 编写的《企业集成模式》。当两个应用需要交换数据时，无论是来自一些遗留系统的老式文件交换还是现代微服务体系结构，这本书的内容都适用；
• 了解质量度量：定义架构还不算完，还要解释为什么要定义、应用并控制这些准则和编程标准。这样做是因为需要控制质量，满足一些非功能需求。我们想要的是一个可维护、可靠、可适应、安全、可测试、可扩展、可用的系统。而实现所有这些要求的方法就是有一个好的架构设计方法。你可以在维基百科上了解更多关于质量度量的信息。理论很重要，但是如果你不想成为一名活在象牙塔里的架构师，实践也同样重要，甚至更加重要；
• 尝试并理解不同的技术栈：我认为这是你成为更好架构师之路上最重要的一步。尝试新的技术栈，并了解其发展历程。这些不同的技术具有不同的设计理念和模式。只浏览 PPT 学不到太多东西，你需要自己去尝试并感受这项技术的喜与悲。架构师不仅要有广博的知识面，还要在一些领域有深厚的积累。重点不在于掌握所有的技术栈，而是对你所在领域最重要的技术有坚实的理解。你还可以尝试一些领域外的技术，例如，如果你对 SAP R/3 有很深的了解，你应该尝试一下 JavaScript，反之亦然。尽管如此，双方都会对 SAP S/4 Hana 的最新进展感到惊讶。例如，你可以自己尝试并免费参加 openSAP 的课程。保持好奇心，多尝试新事物，也可以尝试一些几年前不喜欢的东西；
• 分析和理解应用模式：查看任意当前框架（如 Angular）。你可以在实践中学习到很多模式（如 Observables），你还应该试着理解它是如何在框架中应用的，为什么要这样做。如果你是真正的专业人士，你还需要更深入地研究代码并了解它是如何实现的；
• 保持好奇心，关注用户群。

决策

架构师需要制定决策，指引项目甚至整个公司的正确方向。

• 分清主次：不要在不重要的决策和工作上浪费时间，要学会分清主次。就我个人来说，我比较喜欢通过以下两个特征来判断一件事是否重要：
• a. 概念完整性：如果你一开始决定了一个理念，坚持下去，即使有时候用不同的方法做会更好。这样整体概念就更清晰明确，提升了可理解性，也简化了维护过程。
  完整性：如果你一开始决定了一个理念，坚持下去，即使有时候用不同的方法做会更好。这样整体概念就更清晰明确，提升了可理解性，也简化了维护过程。