架构师是近几年来在国内外迅速成长并发展良好的一个职业，它对系统开发和信息化建设的重要性及给IT业所带来的影响是不言而喻的。在我国，虽然系统架构师的职业在工作内容、工作职责以及工作边界等方面还存在一定的模糊性和不确定性，但它确实是时代发展的需要，并正在实践中不断完善和成熟。
下面和大家聊一聊架构师的几个特点
架构师，听起来是如此神秘的一个称号。尤其是在开发领域刚入门不久的菜鸟级程序员眼中，架构师都是高手，都是牛人，都是如此高高在上的存在。
不过，在搞了四、五年编程之后，程序员们往往早已失去了当年对这些“高级”职位的神秘感，甚至会对自己所在项目的架构师抱怨不已，背后里称他们是一群水王。所以有江南白衣曾撰文述说：“国内的架构师到了三十岁以后很多就往理论上跑，而国外的架构师在往上发展的同时保持下面的编程体验，所以国内多水王，而国外则多大师。”
这就是我们今天这篇文章的论题：一个优秀的软件架构师，首先一定是一个出色的程序员。
这句话按照Fred
George的话来说，那就是“不编程的架构师的职业生涯是短暂的”。他说这句话的背景主要是针对有些架构师的设计与实现有断层的问题而言的，因为如果架构师不去实践，只是想当然的认为“没问题，这个想法能实现”，那么对于项目的落实而言是个很大的隐患。[支付宝架构师冯大辉]也表示过，架构师是一个比较“虚”的岗位，主要的问题都在“落地”的过程中。
而一个架构师确认一个想法究竟能不能落地的最直接的方法，就是自己编写代码，尝试“实现一个系统最难实现的一部分”（Fred
George）。看看Fred，他自己就是最好的示范：年纪一大把了，仍然每天都在编写代码。事实上，我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员。
我们可以列举出一个长长的顶级架构师的列表，你会发现他们没有一个不是顶级的程序员
不过这在逻辑上或许没有多少说服力，因为似乎这并不能证明一位资深架构师凭自己的经验感觉不能够知道一个想法能不能落实。如果你觉得上面这些只是某些西方老头儿对编程的古怪癖好，那么不妨看看eBay的架构师[Randy
Shoup先生]是如何总结架构师在项目中的职责的：
l 具备丰富的一线大中型开发项目的整体规划、方案设计及技术队伍管理经验。
l 具备软件行业工作经验，熟悉业务领域的技术应用和发展。
l 具有项目管理理论基础，并在应用系统开发平台和项目管理上有实践经验。
l 对相关的技术标准有深刻的认识，对软件工程标准规范有良好的把握。 具备C/S或B/S体系结构或特定领域软件产品开发及架构和设计的经验。
l 具有面向对象分析（Object-Oriented Analysis, OOA）、设计（OOD）、开发（OOP）能力，精通UML和XML等，熟练使用Rational Rose、PowerDesigner等CASE工具进行设计开发。
l 对相关编程技术及整个解决方案有深刻的理解及熟练的应用，并且精通架构和设计模式，并在此基础上设计产品框架。
l 精通大型数据库如Oracle、Sql Server、MySQL等的开发。l 对计算机系统、网络和安全、应用系统架构等有全面的认识。
l 良好的团队意识和写作精神，有较强的内外沟通能力。
在这个过程中，一个架构师至少有一半以上的工作是需要与开发团队一起进行的。按照Randy的描述，这是“一个架构师不能将实施细节抛之脑后”的体现。而且与开发团队一起工作，命令式的领导方式并不被推崇，一个架构师必须通过自己的个人影响力来对开发团队进行指导工作。而什么是影响力？说的直白一些，就是通过自己写代码以及和其他成员一起写代码，来指导团队成员实现每个架构细节的思路。
只要稍微思考一下，就会明白此举的重要性。如果一个架构师靠命令管理开发团队，告诉他们“要实现这个模块”，“要实现那个功能”，而团队也尝试照办。可是或许是架构师的要求太高了，或许是团队的开发实力不够，团队成员便会向架构师求助：您看这个我们不知道如何实现，您能否指导一下？架构师可能知道怎么处理，也可能没有仔细思考过这个问题，但又觉得自己做大事者不拘泥于小节也，于是一皱眉头扔下一句：这是你们的事，你们自己解决！
然后就是矛盾的开始了。架构师只觉得团队技术不够，而团队则对架构师愈发不满。项目黄了不说，开发团队中也会传出各种说法，比如说“此君其实是个一行代码也不会写的大忽悠！”
做为系统架构师，必须成为所在开发团队的技术路线引导者；具有很强的系统思维的能力；需要从大量互相冲突的系统方法和工具中区分出哪些是有效的，哪些是无效的。架构师应当是一个成熟的、丰富的、有经验的、有良好教育的、学习快捷、善沟通和决策能力强的人。丰富是指他必须具有业务领域方面的工作知识，知识来源于经验或者教育。他必须广泛了解各种技术并精通一种特定技术，至少了解计算机通用技术以便确定哪种技术最优，或组织团队开展技术评估。优秀的架构师能考虑并评估所有可能用来解决问题的总体技术方案。需要良好的书面和口头沟通技巧，一般通过可视化模型和小组讨论来沟通指导团队确保开发人员按照架构建造系统。
因此，系统架构师知识维度可以总结为“多层次+多方面”。所谓多层次，意味着系统架构师必须在体系结构、计算机软硬件与网络基础知识、信息化基础知识、信息安全与可靠性基础知识等基本功的层面上受过良好的教育和快捷的学习能力；还须在系统架构设计方法、设计模式、设计流程以及各种模型等方面有丰富的经验，广泛了解各种构件产品和技术并精通一种特定领域的架构设计；进一步，还须在系统架构设计实践层面，有自己的认识和理解，同时具有很强的表述能力；所谓多方面，意味着系统架构师在每个知识层面上必须具有即使、管理、心理和艺术等多方面的知识和能力。这和系统架构师的多角色特点是相关的。
在此我向大家推荐一个架构学习交流群。交流学习群号：
744642380，
里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良
工程化专题
（团队大于3个人之后，你需要去考虑团队合作，科学管理）
源码分析专题
（好的程序员，一行代码一个设计就能看出来,源码分析带你品味代码，感受架构）
3.高性能及分布式专题
（跟上技术节奏，扩宽技术视野,程序员要往上提升，要有自己的技术工具箱和技术认知。）
4.技术架构专题
（真实案例分享，带你领略大型项目风采）
5.性能调优
（追求高效、科学调优，不靠碰运气）
在此我向大家推荐一个架构学习交流群。交流学习群号：
744642380，
里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良