如何开始成为一名架构师

第一步：打破僵局

架构师岗位对架构经验有要求，但不成为一名架构师的话，工作上就不会要求你去做架构。要打破这一个鸡生蛋蛋生鸡的死循环，需要我们跳出之前的固有思维，也就是传统观念认为的，只有架构师岗位上的人才能去做架构。

跳出来，你就会发现，产品研发和维护过程中的每一个岗位都可以去做架构的工作。

平时我们在做研发甚至维护工作的时候，就可以对某些特殊功能进行分析和思考，思考有没有另一种更好的办法来实现这一功能。久而久之就会形成我们自己的一些架构的想法，这样在项目调研开会的时候就可以将自己的想法公布出来，听取大家的意见。

在打破僵局这一阶段受到批评，反而是有助于你成为一名架构师的，因为批评意味着大家开始关注你的设计，讨论你的设计。也会督促你的思考，更进一步，更完善一点，更贴近于真实场景的架构。

慢慢你的设计就会被大家一点一点的接受，虽然没有坐在架构师的岗位上，但已经在做架构师的事情，那么之后一旦有这么一个岗位空缺，那大家首先想到的就会是你。

这就是观念上的打破僵局，是一种道。

第二步：转换思路

在做普通的研发工程师的时候，我们只会关心眼前的某一个点，关心这一点背后的技术深度，但却很少关心这一点，会对整个团队目标完成度的影响。团队的目标并不是完成这一个程序，而是要实现程序背后的价值。一个电商平台并不是要功能越完善越好，性能越强大越好，而是要真正能赚到钱，能吸引来用户和商家。



这时我们设计的思路，就应当从某一项技术或某一个框架中脱离开来，养成一种指挥官命令的思维，

也就是说对面有一个山头，我们的目的是拿下这个山头，至于你是坐船去，还是跑步去，甚至坐飞机去

都无所谓，只要你能拿下这个山头，你的方法就是对的。



不管黑猫白猫，抓到老鼠，它就是好猫！



架构师除了设计工作以外，还需要负责任务的分工，项目进度的管理。

在设计分工的过程中，需要搞清楚分工的边界在哪里，比如模块开发者应当交出什么样的信息给上层的调用者，服务器维护人员获得什么样的信息就足够运维整台服务器，而这些信息应当由谁提供？如果没有按时提供，会有什么样的后果？责任由谁来承担？在架构师的思维里没有什么是不言而喻的，任何安排和计划都应当有其背后的逻辑支撑。斤斤计较就是架构师的天性，咬文嚼字就是架构师的责任。



最后一名架构师是需要将整个技术项目表达给所有的项目相关方，他可能是懂技术的老板，不懂技术的老板，懂技术的客户，不懂技术的客户，只懂一点技术的业务员，懂很多技术的小队长。在有限的时间里，需要找到一种恰得其分的表达方式，来满足这些相关方的需求。



简单一点来说就是，对方刚好能听懂的表达方式，就是最好的表达方式，面对不懂技术的人，不需要展示任何银行代码，面对只懂某一点技术的人，要明确他完成任务所需要的资源以及最后要交出的成果。



总结来说，在架构师进行设计、分工、管理、沟通的过程中，需要以项目背后的价值作为唯一目标导向，以项目相关方的需求，作为协调和沟通的尺度，这就是术。



第三步：精准描述

人类的语言是有缺陷的，很难再描述复杂系统的同时，保持自身语言的简洁。这时我们需要使用uml这样的工具来描述整个项目。



在开始设计前，需要了解三方面知识：

理论基础

Uml的理论基础，尤其是元素与元素之间的差异是什么。



• 关联与依赖

关联是一种更强的依赖，一个类是另一个类的局部变量。依赖的话，是方法上的调用关系。

• 继承与接口

继承获得了父类的方法，接口只是一种声明。

• 聚合与组合

组合比聚合更强，前者的生命周期是一致的，聚合对象结束后，子对象仍然可以作为一个主体存在。



图的种类和用途

图分为两类：

• 静态图

• 用例图

• 类图

• 组件图

• 部署图

• 动态图

• 序列图

• 活动图

• 状态图



类图：负责描述类之间的关系

时序图：负责描述动态关系

活动图：负责描述业务流程，可作为流程图使用

状态图：表示状态变化关系

合作图：就是没有时序关系的时序图

组件图（难点）：负责把功能里模块拆分清楚，组件设计的粒度，应当能够让一个人，负责一个组件的开发

部署图：负责描述新系统和其它服务器之间的关系



设计工作三阶段

软件设计工作分为三大阶段：

• 需求分析

• 概要设计

• 详细设计



三个阶段所要用到的图分别为：



需求分析：用例图、状态图、时序图、活动图

概要设计：部署图、系统级时序图、系统级活动图、组件图、组件时序图、组件活动图

详细设计：类图、类时序图、状态图、方法活动图



最终目标

最终应当将下图中的信息描述清楚

架构师应当让团队中的每一个人对于整个项目的背景、需求、关键点都有充分的掌握。针对每一个受众做到恰如其分的表达，从而把控项目进度，做好团队分工。



指导思想

UML架构图表的设计，是一种技术描述。一名架构师首先需要对项目背后的业务逻辑有深入的了解，能够将这些逻辑现实抽象为理论，再将理论描述为一个个UML图表。

在技术描述的过程中，需要架构师对环节中涉及的每一项技术，每一个框架都有深入的了解，只有这样才能

充分的考虑项目运行中的各种突发情况，提前准备好应对方案。而深度是可以触类旁通的，先从一个点深入下去，那么其他点的技术原理，再理解起来也就轻松许多了。

总结来说就是，深度比广度重要，广度要靠时间来填。