1、开发者和架构师之间最大的区别是什么？

架构师和开发者一样，也经常写代码，简单的说，开发者和架构师之间最大的区别就是技术领导力。

软件架构师的角色需要理解最重要的架构驱动力是什么，他提供的设计需要考虑这些因素。架构师还要控制技术风险，在需要的时候积极演化架构，并且负责技术质量保证。从根本上讲，架构师是一个技术领导者的角色，这就是最大的区别。

2、一位开发者如何才能成为一位架构师？他/她需要掌握哪些领域之外的能力？

两个字：经验。

我认识的大部分优秀软件架构师同时也是出色的软件开发者，他们都是经过时间逐渐发展成为架构师的。你需要有退后一步看代码的能力，从而理解特定软件系统背后的设计决策。退后一步才能看到“大局”，这是架构师必须掌握的核心技能。

3、你对软件架构的理解是否因为你的经历和实践而改变过？

是的。我对软件架构的理解是根据我在咨询公司工作时在各个项目中负责软件架构的经验形成的。咨询是一件好事，尤其从最近我开始从事独立咨询师这个工作之后，我可以看到很多不同的团队，不同的架构，不同的技术，以及人们不同的工作方式。世界各地的文化多样性又为工作的复杂度增加了一个维度。无论是寻找特定问题解决方案的过程，还是为各种想法去芜存菁的过程，这些经验和与我共事的人的反馈一起最终形成了我今天对软件架构的认识，这些思维也反应在了我的书中。

4、有没有什么事是架构师永远都不应该做的？

有，软件架构师永远都不应该停止编程和停止学习！

在程序员从初级走向资深的过程中，会面临两个支路，一个叫技术主管，另一个则是架构师。

总结程序员到架构师之路的忠告：

1、程序就是一切。文档是紧接其后的事情。因此，把你们的代码写成本身就是文档，而且要好用。

2、测试 测试 测试。

3、单元测试要严格。任何一个单元测试中发现的bug都负担了开发人员成本外的双重代价。你们要知道，我宁愿给你们更多的薪水也不愿找别的QA公司来测试、让你们修改bug。但如果你的程序写的很差，那我只好把这些钱由这些人平摊，你们只能得到其中很小的一块蛋糕。

4、写出好代码要能给人类阅读，给CPU使用。绝对不能向烂代码低头。

5、阅读更多的知识，不要局限于目前的工作所需。如果你只掌握今天需要的知识而不知明天需要的，你不会有发展进步。

6、回家不时的做做饭。是的，真的饭。这会让你知按照菜谱做饭和自己创造一顿饭之间的区别。前者是在做饭前已经知道了需要什么，而后者是根据你目前有的来做 … 就这一点点不同。

7、抽象的能力，抽象思考的能力怎么强调都不为过。现实的需求纷繁复杂，如果架构师不能够把这些乱无头绪的需求抽象成一些“概念”，在概念的层次进行思考，系统根本就无法设计。

8、技术领导力，要用技术的影响力来领导人，而不是威权和职位。换句大白话来说，就是要能让技术人员服你。有了技术影响力，你在团队发出的声音才会被倾听，被尊重。

以前听阿里同学说 P7 属于架构师职位，不过最近在看另一个阿里同学写的文章说：“前几年是有专职的架构师职位的，现在已经回归到工程师、技术专家、研究员这样的纯技术职位。”可见在一线互联网公司关于架构师的定义也是很模糊的。

但正因为业界和公司对架构师这个角色的职责定义很模糊，所以很多经验积累到一定程度的优秀程序员，并且在公司内被提升到一定高度的技术级别后，都会冠以架构师之名。

要找架构师来对一些技术争端和方案进行决策判断，很多情况在于程序员对架构师在技术领域内专业力和影响力的信任，而建立这种专业力和影响力是实际构建架构师非权威领导力的来源。

这里提到一个非权威领导力，这是什么？非权威是相对权威而言，管理者的权威领导力来自于公司正式任命的职位和职权，而架构师在大部分公司基本连职位职责都没定义清楚，更没有职权一说，所以实际上就不会有任何权威领导力。所以，架构师要发挥更大的作用和价值就需要去构建自己的非权威领导力，而这需要长期的专业力和影响力积累。

另一方面，架构师的组织职责除了技术主管承担的之外，架构师还承担着在技术团队和非技术团队（例如：产品设计等团队）之间的接口作用，明确产品的边界，勾勒技术蓝图，协调不同技能的技术团队协作，完成最终的软件系统交付。这时架构师的角色就像服务化架构中的 API，定义了协作规范、交互协议和方式，但并不会聚焦在具体的实现上。

所以程序员在成长到一定阶段就需要去考虑是否真要往技术主管和架构师的方向发展。而从技术主管走到架构师相对而言更有延续性，但技术主管也会 有另一条路，就是转型走上纯管理岗位，成为一名真正意义上的经理。

另外还有一点可以通过自身的学习来获取一大进步。

来自：大天空天文学

https://baijiahao.baidu.com/s?id=1563059786586050&wfr=spider&for=pc