产品架构师与系统架构师 一人身兼数职的路子跟咱们没什

一、什么是建筑师

在许多初创公司中，一个人同时从事多项工作仍然很常见。至少，我经历过。一个人负责所有的开发过程，我什至做了测试。这绝对是一站式的。发出来的母盘含有病毒僵尸，所以我被迫收回了已经投放市场的两万张光盘。从那以后，我的心变得无比强大，现在整个后台服务都瘫痪了。我也只是笑了笑。事实上，一个人既是架构师又是程序员，甚至兼任多个角色都没有错。这个话题将在后面讨论。这种现象不是中国的，完全符合国外的。我曾经在msn和美国的一位工程师聊过类似的话题，发现他们的做法和我们没有什么不同。在IT行业，我们离世界只有一天的路程。他们刚刚制作的新东西是我们第一个保证在 2 天内见到你。

架构师这个词不是一个随机的想法，它在国际标准中可用（ISO/IEC 42010）。架构师是软件开发活动中的众多角色之一，它可能是一个人、一个团体或微软有架构师的分类参考，我们来看看，他们把架构师分为4种类型：企业架构师EA()、基础架构架构师IA()、特定技术架构TSA(-)和解决方案架构师SA()。分类是基于建筑师的关注领域。

EA 的职责是确定整个公司的技术路线图和技术发展方向。盖茨给自己的头衔是首席软件架构师，网易丁磊喜欢这样称呼自己。其实他就是EA的角色； IA的工作是把积累和沉淀的基础的、公共的、可复用的技术提炼和优化。框架和组件，这是一家技术型公司继承的最有价值的资产之一；特定技术架构师TSA，主要从事安全架构、存储架构等特殊技术的规划设计； SA的工作是专门从事解决方案的规划和设计，“解决方案”这个词在中国已经达到了严肃的程度，大傻子最喜欢谈论它。所谓解决方案，就是不断地结合产品、技术或理论产品架构师与系统架构师，创造出满足用户需求的选项。售前工程师通常会带它给客户玩。

大公司会清楚地区分不同类型的建筑师。小公司一般不那么讲究。大多数架构师都是IA+TSA+SA。该公司生产多面手。

在实际工作中，我们经常看到另一种比较简单的分类方法，将架构师分为软件架构师和系统架构师。软件架构师基本都是TSA+IA，也是程序员最容易突破、最有可能走上的路，比如JAVA架构师、架构师、LAPM架构师等。后面我要讲的内容是和软件相关的。建筑师的相关主题。系统架构师其实是SA+TSA，更侧重于综合利用现有的产品和技术来实现客户期望的需求。系统架构师需要同时具备软件和硬件知识，因此其知识体系相对复杂。关于系统架构师的话题，我们可以稍后再谈。

二、架构师的职责

架构师需要参与项目开发的全过程，包括需求分析、架构设计、系统实施、集成、测试和部署阶段，负责指导和协调整个项目的技术活动和技术规范。

架构师有四个主要职责：

1、确认需求

在项目开发过程中，架构师是在需求规范完成后才参与进来的，需求规范必须得到架构师的认可。架构师需要与分析师反复沟通，以确保他们完全准确地了解用户需求。

2、系统分解

架构师根据用户需求，将整个系统分解成更小的子系统和组件，形成不同的逻辑层或服务。随后，架构师将确定各层的接口以及各层之间的关系。架构师不仅需要通过“垂直”分层来分解整个系统，还要将相同的逻辑层划分为块，进行“水平”分解。

软件架构师的技能基本体现在这，是一个比较复杂的工作。

3、技术选型

架构师通过对系统的一系列分解，最终形成了软件的整体架构。技术的选择主要取决于软件架构。

Web 是在 Linux 还是 Linux 上运行？数据库使用MSSql，还是Mysql？需要使用 MVC 或其他轻量级框架？前端是富客户端还是瘦客户端？在这个阶段需要提出和评估类似的工作。

架构师对产品和技术的选择只限于评估，没有决策权。最终的决策权属于项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息。项目经理会权衡项目预算、人力资源、时间进度等实际情况，最终确定。

4、制定技术规范

架构师是项目开发过程中的技术权威。他需要协调所有开发者，与开发者保持不断的沟通，并始终确保开发者根据其架构意图实现各种功能。

架构师和开发人员之间最重要的交流形式是技术规范，可以是UML视图、Word文档、Visio文件等多种表现形式。通过架构师提供的技术规范，保证开发者可以从不同的角度观察和理解自己承担的子系统或模块。

架构师不仅需要与开发人员保持沟通，还需要与项目经理、需求分析师甚至最终用户保持沟通。因此，对于架构师来说，不仅有技术要求，还有人际沟通的要求。

三、架构师的误区

1、架构师是项目经理

架构师不是项目经理。项目经理侧重于预算控制、时间进度控制、人员管理、对外联系与协调等，并具有管理职能。在一般的小型项目中，项目经理和架构师很常见。

2、架构师负责需求分析

架构师不是需求分析师。需求分析师的工作是收集和分析需求，并与最终用户、产品经理保持联系。架构师只对最终需求进行评审和确认，对需求中不明确和不完整的部分提出建议。他将随时与需求分析师保持联系。架构师是技术专家，而不是业务专家。

3、建筑师从不编码

这是一个悬而未决的问题。目前有两种观点：

观点一：架构师不写代码，写代码纯手工，架构师写代码是矫枉过正。架构师将 UML 的各种视图交给开发人员。如果有不清楚的地方，可以随时与建筑师沟通。

观点二：架构师本来就是程序员出身，但比程序员的层次更高。比程序员更重要的是经验和知识，所以架构师在写代码是不可避免的。

我个人认为这两个说法与建筑师的出身和环境有关。

架构师首先是一个技术角色，所以一定是来自技术人员的群体，比如系统架构师，多来自运维人员，可能自己写的代码不多，也可能写的不是很漂亮代码。软件架构师大多来自程序员，有着程序员的血统和情怀，所以在项目开发的过程中，可能会写一些核心代码。我们的理想是架构师不必编写代码，但现实有时过于理想。架构师是否编写代码可能取决于公司规模、文化和开发人员素质的实际情况。此外，架构师与程序员并没有那么明显的分开。根据他们的能力，也有高，高和低的水平。写不写代码并不是区分两者的基本标准。

四、建筑师的基本素质

周星驰有一部电影《喜剧之王》，里面尹天秋整天背着《演员的修养》这本书。一个好的演员不仅需要天赋，还需要一定的理论指导。人毕竟是少数。建筑师的成长过程也是如此。从普通程序员到资深程序员，再到架构师，是一个经验积累和思想升华的过程。经验积累是一方面，素质培训是另一方面，两者相辅相成，所以我觉得有必要把架构师需要具备的素质列出来作为程序员努力的方向。

沟通技巧

为了提高效率，架构师必须获得团队成员、项目经理、客户或用户的认可，这需要架构师具有很强的沟通能力。沟通能力是人类最普遍的素质要求。似乎技术人员很容易被忽视。如果你想成为一名建筑师，你不能忽视它。不要抱着这样的观念：怀孕就像怀孕一样，时间长了总会被发现的。或者天桥上卖大理丸的哥们说的对：只说不练假手，只练不说傻话。看看你周围的头脑，哪一个不是高手，千万不能轻视，认为这是阿谀奉承、投机取巧，凡事都要看到积极的一面，“沟通”确实是一种能力。我觉得自己有点内向，因为我是农村的孩子，普通话不太好产品架构师与系统架构师，以前有一点自卑感。损失少。现在，我深深明白了沟通的重要性，时不时会主动和同事、老板沟通，感觉工作顺畅多了。

我认为这是最重要的，所以它是第一位的。我什至认为以下几点可以忽略不计，唯一需要牢记并经常提醒自己的。

领导

架构师可以推动整个团队的技术进步，在压力下做出关键决策并贯彻执行。架构师如何确保执行？这需要架构师具备领导技能。

架构师无法获得与项目经理相同的领导技能。项目经理主要负责解决行政管理问题。这种能力与技术关系不大。他有人权和财权，然后披上“领导”的虎皮。 “胡萝卜加大棒”的方法基本可以保证执行。力量。建筑师在项目中可能会使用更多非正式的领导力，也就是我们常说的影响力，包括个人魅力、技术能力、知识转移等。

抽象思维和分析能力

架构师必须具备抽象思维和分析能力，这是你系统分析和系统分解的基本素质。只有具备了这种能力，架构师才能看清整个系统，掌控全局，这也是架构师全局观形成的基础。你怎么有这个能力？一个来自经验，另一个来自学习。架构师不仅需要有问题领域的经验，还需要有软件工程领域的经验。也就是说，架构师必须能够准确地理解需求，然后用软件工程的思想将需求转化和分解成可以用计算机语言实现的层次。经验的积累需要一个时间的过程，这个过程没有人能帮助你，你需要自己去体验。但是，如果你自觉修炼，不断吸取前人的经验，还是可以缩短这个周期的。这是我写这个系列的动机之一。

技术深度和广度

架构师最好精通 1-2 种技术。有了这种技术能力，他们可以更深入地了解相关架构的工作原理，也可以拉近与开发者的距离，在团队中形成影响力。

架构师的技术知识广度也很重要。有必要了解尽可能多的技术。所谓知识渊博，只有这样，才能将各种技术融合在一起，选择更适合项目的解决方案。有人说对架构师的技术广度要求高于技术深度要求，这是很合理的。

总而言之，一句话：架构师是项目组的技术权威。