学习架构师的思考方法

冷不防 2023-06-15 06:50 41阅读 0赞

## 摘要 ##

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

## 一，什么是架构 ##

> 架构的三要素：
> 
>  *  职责明确的模块或者组件
>  *  组件间明确的关联关系
>  *  约束和指导原则

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

例1：软件架构  
![1][]

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

例2：组织架构  
![2][]

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

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

## 二，什么是架构师 ##

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

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

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

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

### 2，如何定义问题 ###

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

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

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

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

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

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

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

## 三，架构的分类 ##

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

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

## 四，能力和职责的区别 ##

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

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

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

[原文链接][Link 1]

[1]: https://img-blog.csdnimg.cn/2019112020120933.png
[2]: https://img-blog.csdnimg.cn/20191120201452162.png
[3]: https://img-blog.csdnimg.cn/2019112021365423.png
[Link 1]: https://mp.weixin.qq.com/s/I54KjGCgMfoDEdR8U3QRCw