学习架构师的思考方法

摘要

这是一篇架构师思考方法论的学习笔记，原文对什么是架构，什么是架构师，架构师如何定义和分析问题进行了比较深刻的探究。

一，什么是架构

架构的三要素：

• 职责明确的模块或者组件
• 组件间明确的关联关系
• 约束和指导原则

三要素是关于架构这个名词通用的定义，不局限于软件开发领域。下面具两个例子便于理解：

例1：软件架构

• 模块：模型、域
• 关系：一对一、一对多（模型）；依赖（域）
• 原则：单一职责、开闭原则、里氏替换原则等等

例2：组织架构

• 模块：部门
• 关系：管理 or 上报
• 原则：各种管理原则、财务原则

下面我们具体讨论的还是软件开发中的架构。

二，什么是架构师

架构师这个角色的职责是：识别并定义问题，创建、选择或调整架构，从而找到最优的方案，解决问题。

这其实也是架构师做事的一般套路：定义问题->确定架构->提出方案->落地拿结果。这四步中，越是前面的步骤，越是重要，越是抽象，也越是困难，越能体现架构师的功力。因此有必要探讨下如何识别定位问题。

1， 区分问题、手段和挑战

三个概念并不是相互严格区分的，它们是问题树的不同层次。

每一个问题可以向下不断展开不断细化，下一级的问题是上一级问题的具体解决手段，当你把“提升性能”当做你Owner的问题时，提升帧率、提高页面秒开率、优化启动耗时就成为了你的具体解决手段；而手段的下一级问题，就是你将面临的挑战，比如你要优化网络耗时，你要面临的挑战就有弱网环境、一些国家区域的带宽问题等等。

2，如何定义问题

亨利福特说，如果我问客户需要什么，他们会告诉我，他们需要一匹更快的马。

定义问题经常需要思考问题背后的问题，为什么客户需要一匹更快的马？可能客户想要更快的日常交通方式，上升了一个层次后，我们立刻找到了更好的解决方案：造车。

理论我们知道了，但给你个具体的问题描述你可能还是不知道如何准确定位背后问题。这里有一实操技巧：我们可以不断缩短描述问题句子，比如提炼主谓宾，如果还不能清晰的描述那么在这几个词里再找出最最最关键的词，尤其是主语或者宾语中的词汇非常重要，它有可能就是重点。

3，从哪些方面分析一个问题

可以从主要次要，紧急程度和时间维度三个角度分析。

前两个维度看着是否很眼熟，有点像很多工作效率方法说的将事情的分类。这里就不多说了。时间维度是容易被忽略的重要维度，任何一个问题的严重程度都有一个时间轴，也许过了某个时间点之后，问题便不再是个问题。

后面两节，介绍架构师工作中要弄清的概念，帮助大家在和不同职位的人沟通时提升效率。

三，架构的分类

和业务需求方、产品经理、技术设计聊天，他们都会提到架构，但他们口中的架构不是一回事。区分清楚工作中常用的架构分类，可以让你在开会时把不同职位的人口中的架构对号入座，以提升沟通效率。

名称	受众	目的	内容
产品功能架构	产品使用者，产品经理	指导用户，吸引用户	从用户角度，阐述产品功能模块
业务能力架构	研发人员，业务人员	用于理解业务内在的概念和联系,有助于我们分析和理解业务需求	业务能力，能力中的子能力
应用逻辑架构	研发人员，架构师，技术管理者	指导软件研发	阐述架构中各模块的职责：如系统模型，技术模块，技术模块的关系，技术模块的核心抽象，如何用设计模式来让架构符合软件设计原则，等等
应用物理（部署）架构	运维人员，架构师，技术管理者	指导运维部署软件	逻辑架构如何落地，比如使用何种微服务容器，逻辑架构的模块落地时应该是package，还是应用，是不是要跨机房部署等等
基础设施架构	架构师，技术管理者	–	选择什么样的中间件，存储，监控等等

四，能力和职责的区别

产品同学一般讲能力，而架构同学一般讲职责，区别如下：

能力
指一个产品能做什么，如中台本身是一个产品，对使用中台的人来说，我们应该讲中台的能力。
职责
指架构内模块的职责，用来指导开发。比如对中台的研发，应该讲架构的职责，依赖，约束。

简答来说，能力是对产品的使用者来说的，职责是对架构的实现者说的。

原文链接