如何才能真正的提高自己，成为一名出色的架构师？

Question

如何才能真正的提高自己，成为一名出色的架构师？

想成为一个出色的架构师，但是学得知识不是很系统。目前属于自学，设计模式，算法导论，编译原理，UML2.0等都在看。自学可想而知，肯定不够系统，不够全面，也不科学。身边也没什么人可以在这方面教导我，工作已经3年了，每次换工作都是呆在小公司，技术这块的基本自己来抗，很多东西都自己摸索的。去年开始到现在完成了算是从头到尾自己全权负责的项目（PHP-MYSQL-PYTHON，PHP的MVC框架自己写的），做下来发现自己有很多的不…

关注者

2,859

被浏览

211,573

56 个回答

架构师是一个充满挑战的职业，知识面的宽窄往往决定着一个架构师的架构能力，所以在这一点上我比较赞成你的学习方式，就是要阅读大量的技术书籍，但我希望你不要仅限于软件相关的书籍，经常泡技术论坛，一方面可以结交朋友，一方面可以增加自己的知识面。
公司的大小往往决定了所做的项目规模，一般的大项目不太可能直接总包给小公司去做，但这并不妨碍小公司可以分包到大项目的一部分。在做小项目的同时也可以积累丰富的经验，我自己就是一个这样的例子。
我在小公司混迹了5年多，其中也偶尔有1两个大公司，比如大唐电信，但是基本上都是小公司，从基层的程序要到公司的开发总监都做过，甚至自己还设计过包括LED显示屏，密码键盘在内的收费系统，自己联系厂家OEM，当然这些今天已经广泛应用了，当时我们的客户用上之后还是非常震撼的。
知识面的宽广对于一名出色的架构师来说是必不可少的技能，也许很多人对架构的理解还停留在设计模式，重构，SOA等等的软件层面，然而这仅仅是非常基本的东西，架构师的脑子里不光需要知道让软件如何高效的运行，还需要知道如何去结合网络，存储，甚至一些文件系统的特性，比如GFS，NFS，XFS，NTFS等等，而且架构师还需要知道一些编程语言的特性，C，C++，Java，PHP，Python，Lisp，JS等等，现在是一个混合编程的时代，只了解一种语言，即使再精通也会使你在架构系统的时候受到很大的局限性。
再有一点，架构师需要对数据库技术有深刻的认识，因为现今是一个信息时代，大量的信息都是需要存储并检索的，数据库设计的不好，将会严重影响系统的性能，而这一点往往会被我们的设计人员忽略，他们只知道遵守那些范式而不会结合数据的特性去设计数据库。
看你的编程情况，你好像做PHP开发比较多，PHP比较适合B/S结构的应用开发，这会限制一个架构师的思路，我建议你再学习一门适合做C/S开发的语言，拓宽自己的视野。
从一个程序员到架构师是一个很大的变化，架构师需要从大的方面考虑，而不只是考虑这个模块该用哪种设计模式去开发。不能急于求成，也许是我自己变化的比较慢，我用了10年的时间，这10年里，我使用超过一年的编程语言包括了delphi，C++，Java，python，使用的数据库包括了oracle，infomix，sybase，sqlserver，mysql，javadb，sqlite等等，使用过大型机，小型机，服务器。unix，linux，windows都至少做过两年以上的开发，这些使用和开发的经历会大大增强一个人在做架构师这个职业时的技术素养。
总之，想要成为架构师，需要有耐心，不断学习，拓宽自己的视野，不仅仅局限于自己眼前的项目，关注开源技术，关注热门技术社区的新动向。

发布于 2012-01-16

Accepted Answer

对于一名如何才能真正的提高自己，成为一名出色的架构师？在这有一些看法希望能帮助到有需要的朋友，同时可以关注下专栏：

java架构技术交流zhuanlan.zhihu.com

里面有大量batj面试题集锦，还有各种技术干货文章分享，大家可以同时关注下我以后会不停更新更多精选文章！

对工作多年的程序员而言，日后的职业发展无非是专精技术，转型管理，晋升架构师三种选择。成为一名优秀的架构师，是大多数技术人的追求。

想要做架构，空有一身技术是远远不够的，知识的深度和广度，往往会决定一个架构师的架构能力。而这些知识，从你踏入 IT 行业那一刻起，甚至更早就应该开始储备了。

那么到底什么是架构师？如果有一天把你丢到架构师的位置上你会怎么做？做什么呢？以下来具体阐述下一些看法和建议！

一、两种架构师

工作五年以上的童鞋，或多或少都会有这样的经历：

在小团队或者项目中承担非明确的架构师职责，我们做

项目或者产品的关键设计和实施；
负责产品基础设施；
引入新的理念，框架；
解决团队中的复杂问题；
在团队成员中享有较高的声誉；
被老板认为是团队的关键人物。

如果有一天我们决定（或者其他原因）去做一个专职架构师，那么这两者会有什么区别呢？是否只是之前的方式的延续就足够？

我把第一种状态称之为“兼职架构师”，因为处于这种状态下的同学大部分的时候担当开发人员、PM的角色，只有在小部分时间承担了架构师的部分角色。做的绝大部分事情是自己可控的，自己做架构自己做实施或者在小团队中推行。

而后一种“专职架构师”则面临的是：他们不负责具体的业务系统，而又对所有的系统负责，他们也很少直接负责项目，但是职责却要求他们必须对项目要有提前把控，他们面对的是更大的团队，更大的问题域。

当然每一个人对是否应该存在“专职架构师或团队”都有自己的想法，从阿里的历史来看单独的架构团队也是分分合合。在这里不去探讨，我们关心的是如果有，可以怎么做。

二、专职架构师的职责

首先要弄清楚的是专职架构师的职责到底是什么？

微软对架构师有一个分类：企业架构师EA(Enterprise Architect)、基础结构架构师IA(Infrastructure Architect)、特定技术架构TSA(Technology-Specific Architect)和解决方案架构师SA (Solution Architect)。这个分类是按照架构师专注的领域不同而划分。

在阿里除了EA之外的领域大家可能会同时涉及到，只是不同的时期偏重点不一样。比如前面说的“兼职架构师”可能偏重SA？专职架构师偏向IA+TSA。另外一个角度专职架构师更多考虑问题域和相应的系统架构，而“兼职架构师”更多的是产品的系统架构，具体来说我认为专职架构师重要的职责如下：

职责一：全局的技术规划

架构师第一个最重要的职责是技术规划，架构师最重要的产出是架构，架构就是蓝图，就是阿里常说的一张图。画蓝图就是做“全局的技术规划”，这张图上有什么？没有什么？什么时候有？什么时候没有？当你尝试去画图的时候一连串的问题拷打着你。对于一个架构师的心力和体力都是很大的考验。只有这张图非常清晰明确才能指引整个团队在同一个时间向同一个方向前进。

为了这张图你必须和业务紧密沟通，你必须有对应的技术深度和广度，在选型上有自己的方法论，敢于做出判断和决策。

另外一个重点是全局。全局我的理解是全面+格局，全面就是你的技术规划包含各个方面的，在所有的领域都有明确的指引，所以这张图本质是一系列的图的集合；格局上不要只关注短期利益，更多关注长期利益。不止关注团队利益，更多从公司角度出发，只有这样长期才能为团队带来更多的成长。

职责二：统一的方法&规范&机制

架构师第二个重要的职责，我们不仅仅要提供蓝图，还要提供配套的方法论&规范&机制来保障有序进行。蓝图确保整个团队在同一个时间向同一个方向前进。规范确保前进是有序的。为了有序，你必须拆解你的图，纵向、横向、功能内聚等等纬度拆解到权责清晰对等。这是一项相对复杂且繁琐的过程。

职责三：完备的基础构建

除了蓝图确保整个团队在同一个时间向同一个方向前进、规范确保前进的有序的、我们还需要提供强大的武器库，基础构建的完备程度决定你的团队装备是小米+步枪，还是飞机+大炮。完备的基础构建是否全部作为实际架构的职责，可以因情况而定，比如是否有实体的架构组。但是架构对此应当负责。

职责四：落地的规划才是架构

如果规划不能落地就是传说中的PPT架构师，我甚至觉得这是对专职架构师最大的挑战，前面的几个职责更加偏向硬实力，而这一个更多的是软实力的体现。专职的架构师如果不去关注落地的话慢慢就会架空，变成PPT架构师，那差不多就game over了。

三、专职架构师的权利

正如前面说到对架构师最大的挑战是落地层面，实际上“完备的基础构建”已经涉及到落地层面的事情，但是和完备的基础构建不同的是整体架构的落地涉及到方方面面，面临是更多影响因素：和业务的关系、组织结构、权责定义等等。

所以有人从“架构师的权利和职责”的角度出发推论谁合适做架构师。得出的结论是一个组织的领导者。因为只有他才能调动、协调组织。也有人认为架构师既不能完全负责技术团队，也不能完全游离在技术团队之外。因为负责容易屁股决定脑袋，游离就只能靠个人声望值吃饭了。

如正架构分类中EA的存在，很多领导者也确实身体力行的践行架构师的职责，然而精力终有限。实际上更多是平衡的过程。当然最高境界是影响力。

四、专职架构师的考核

针对前面的职责怎么考核？或者怎么设定自己目标？虽然说在不同的团队阶段，不同外在环境，不同的权责情况下不一样，但是在结果导向的背景下落地肯定是架构师重要的考核指标之一。

考核一：全局的技术规划

相比其他几项这一项是最重要又最难评价的，技术规划的好坏、全面性、前瞻性都是定性的描述，如何指引我们做出一个理性的评价呢？回归到本质上“技术规划”只是一个指路灯，团队中每一个人能不能看到“指路灯”就到达目的地是指路灯价值的体现。所以无论是唯价值论还是唯口碑论衡量的其实是同一个东西。

考核二：统一的方法&规范&机制

这一项的考核就相对容易多了，无论是业界还是每一个架构师本身都有自己的一套方法，所以只需关注这些东西对应的产出。

考核三：完备的基础构建

我认为在大公司，大部分重量级的基础构建已经是非常完备，对于架构师来说更难的不是从0到1，而是克制、边界和从1到2的过程。对于架构师也好、技术团队也好“从0到1”总是充满了吸引力，加上技术人的特征，大公司技术史上永远不缺少重复的轮子，创建这些轮子成就了一代一代的同学，拆除这些轮子再成就了一代的同学，所以克制尤为重要；有了克制跨团队的合作就尤为重要，对应的有两个点一是清晰边界，二是共建。

考核四：落地的规划才是架构

虽然说落地是非常不控的事情，但是考核却很容易的：做到就是做到、没有就是没有、质量好就是质量好，标准非常清晰。过程中只需要紧跟拆解的事情结合实际的组织和业务情况做出决策。

五、实施的一些想法

对现阶段团队的情况来说，我认为第一是建立“架构语言”，有了语言才有沟通协作的基础，所谓的“架构语言”并不是什么新的东西，而是产品的业务架构，用例和领域模型；研发的应用架构，组件和时序图；运维的部署架构等等。

第二是建立“认同体”，无论是通过技术能力、知识传递、领域组织等各种方式逐渐形成“认同体”，且在其中形成架构体系对应的人员体系。

第三永远做服务者，架构师对应的客户是团队的每一个成员，必须始终保持客户第一的心态。架构师存在的目的是成就研发团队每一个同学，我们提供必要的平台、服务和空间，然后彼此成就。

六、Java架构技术体系

（作为一名java学习者给出的一些学习方向，希望能帮助到那些在Java开发路上努力的朋友有个明确的方向）

以上的一切都是让你具有前沿的“架构思维”，完备的架构技术体系才能使这些具体的架构思维不仅仅是个空壳。下面这图是由前阿里架构师韩飞龙带领的团队整理出来的，现在分享给大家，以便大家有一个大的努力方向。

（更多的细小知识点模块图解分析和资源可私信我“架构导图”免费获取）

最后借用一句话：从无到有的是架构；从表到里的是抽象；从粗到细的是设计。大家对架构师有哪些看法，也欢迎在留言区留言，我们一起交流讨论。喜欢的朋友可以关注下专栏：

java架构技术交流zhuanlan.zhihu.com

里面有大量batj面试题集锦，还有各种技术干货文章分享，大家可以同时关注下我以后会不停更新更多精选文章