怎么成为一个软件架构师

的确没想到随手写的东西有那么多的回复，不管怎样还是挺高兴的。在这里谢谢大家的关注了。其实做了这么多年的技术脑子里总会跳出很多的想法，但很少有时间静下来仔细地思考思考，写写博客也算是一种自我归纳和总结吧。

“软件架构师”这个名词也不知是什么时候进入我的脑中的，不过一直就很疑惑，总觉得和软件的Team Leader之间有些纠缠不清。不过以我的观点来看，软件架构师除了没有行政上的职责以外，与Team Leader也并无二致了，也就是一个软件团队的核心设计者和决策人。作为一个软件团队的领头人，架构师应该具备哪些能力、素质和经验呢?

我可以把一个软件研发工作者的从业经历大致划分为3个阶段

第一阶段是新手期

这个阶段的典型特征是容易被新技术的华丽外表所迷惑。当在网上看到一种新技术的介绍或者心得，立即产生了大量肾上腺素的分泌，干什么都想用一用，如果这时有人跟他说你的这项工作用这个不合适的话，要是性子急的人估计就直接开始骂娘了，性子缓些的也会想尽理由说服你使用这个新东西，实在没办法的话，吃不下东西睡不着觉也想另找个地方用一下。

新手时期的程序员对需求和应用环境的掌控能力还不强，但却往往信心爆棚地认为自己写的代码有多么优雅高效。当问题出现时，大多数人的反应就是：“怎么可能!在我的机器上运行的好好的!”。不管看了多少书，学习了多么高效的算法，实际的工作中需求和环境始终是变化万端的。其实我也很不明白为什么那么多的技术类书籍往往都带有或多或少的炒作成份，往往夸大某方面的优势，而对缺点却往往一带而过，同时，相对思想算法讲解、技术介绍类的书籍，针对具体项目研发实例进行技术选型讲解的书真的少之又少，或许这也从侧面反应了写书人很多，真正做研究的却很少吧。

新手期程序员的不成熟还体现在团队表现上，当一个问题提交给新手，当跟踪别人的代码段时，经常会丢手不管，还理直气壮地说“我这块没问题”，殊不知问题都没有查清楚，你又怎知不是你的问题呢?在团队研发中，我一向坚持入口点解决问题的原则，只要问题的入口点在你这里，就必须全程跟踪查到底，问题查出来了，再通知相关人员进行程序修正。团队的程序员虽然分工不同，但每个人必须对他人的程序和算法有清楚的认识和了解，因为大家是在同一个环境下工作，虽然代码有分工，可是操纵的却是相同的设备和资源。独善其身在团队开发中是最要不得的想法。

第二阶段是中级程序员阶段

这个阶段的程序员对技术、和工具的选择已经审慎了很多，可以根据具体的需求来选择需要采用的技术，可以写出详细的需求调研报告并提出设计方案，优点、缺点分析得清晰明了。在应用层面也有较强的全局理解力，在团队中也具有相当的协作能力，因此具备较强的解决问题的能力。

中期的程序员虽然在应用层面上已经相当严谨，但在系统层面的掌控力却并不强。应用系统也并非独善其身，她和网络环境、使用方法、硬件环境、操作系统、地点、时间等等诸多因素有着千丝万缕的联系。在少量用户的中底端研发中，如越来越多的呈几何级数增长的信息管理系统中，系统掌控力并非必须的能力。但在一个高端高并发量，被大量应用于不同环境的软件产品，系统掌控力就是不可或缺的能力。这种能力我认为大部分取决于知识面，工作越多，经验越丰富，就越能对不同的应用环境有着敏锐地感觉和判断。

大多数中阶段程序员限于行业，对语言的依赖还是很强，比如搞信息系统的和搞单片机的、搞网络、路由器交换机的，由于系统层面不同，专精和对语言的理解都不甚相同。

第三阶段是高级程序员/分析师/架构师阶段

进入这个阶段的前提是多年的工作经验，广阔的知识面和对系统底层到高层的全面认识，已经使其进入了无语言无工具的层次。也就是能任何清楚地感知每种编程语言的优劣、使用范围、编码禁忌，对一个大型工程能有最全面的了解，在选择语言和确定技术方案的时候不会被自己对语言或技术工具的偏好(或者根本已经无所偏好)所影响，真正明白了其实别管是神马语言、神马技术，归根到底咱们的对象还不是CPU、内存、硬盘和网络，该做的事情一件都不能少，所谓的技术框架是对初级程序员用的，真正高级了不研究个清楚透彻都不敢让你进来。即使对同一种语言，在不同的操作系统中，如Visual C++和Unix C、AIX XLC、GNU G++等等的区别，以及不同版本之间的区别也了如指掌。这个阶段很难达到是由于对操作系统层面的清晰了解，相信一个初级程序员一路走来，大部分工作都是在Team Leader的规范和引导下完成的，每人都必须做好自己的工作，虽然在应用层面必须顾全大局，但系统层面的问题相对就难以接触了。如果不是对技术有着强烈的渴求和一定的综合能力，系统层面的工作经验将很难与你有缘。这就好比一个当外科医生的，其实做手术并不像很多人想象中那样难，一般看个几次，基本上也就差不多了，如果得到机会实际操作一下，不单是可以积累大量的经验，自信心方面的收获也是无法估量的。但是，动手术责任重大，机会不是人人都有的。技术工作者其实还是很幸福的，毕竟工作经验的取得相对于当医生还是容易的多。

高级阶段一定需要有团队的开发和管理经验，一个软件团队好比一个乐队，每个人对曲目的理解都不同，虽然司职不同的乐器，没有指挥家也会弄得一团糟。软件团队的每个人对语言、业务、能力的理解都不一样，交流方式也有别，同时他们操作着相同的系统和资源，如果Team Leader不做好规划，后果肯定可想而知。丰富的经验和敏锐的触觉神经足以判断出团队成员的编码风格和技术选择偏好，能以足够的经验和理由说服其抛弃自己的感情偏好，从而很好地完成自己的工作。这种能力有点类似于行政的管理，但实际上却是有明显的不同的，这种管理基于的是实际的丰富经验和充足的理由，绝对不可以将行政管理中的排队观念带入，如果2个人意见相左，就必须争论，争不下去了回家想清楚理由再争，甚至直到时间来证明一切，不能说这次你听我的，下次我听你的，技术工作是绝对的，最好的、最适合需求的方案永远只有一个，如果你觉得“都可以”，只能说对行业和需求还没有吃透。

高级程序员是经常会对需求说“No”的人，对行业的深入认识和对系统及应用全局的把握能力使他具有真正指导用户的能力，规范用户的工作、思想并用计算机这个工具真正对行业产生引领作用。高级架构师能深入认识管理和技术的关系，管理上出现的问题一定要在管理上解决，工作经验不多的用户或者程序员往往会把管理上产生的问题抛给软件系统，导致系统越来越复杂，维护成本迅速增长，而管理上的问题却依然存在。但有一个现状是，往往用户提需求都直接提给负责程序的程序员，小公司估计直接就和程序员联系了，大点的也由一个其实并不怎么懂技术的所谓“客户经理”协调转发，而并非经过设计师和架构师的同意，因为他们可能现在已经在研发别的项目了。那么用户的需求是否合理，是否符合当初设计的初衷，往往初级的程序员并不知晓或有不同理解和偏好。虽然这也是实际情况所限，很难做的更好，但这也造成了很多系统的持续发展力很低，而许多用户也处于信息不对等的弱势地位，也只好将就算了。

最后，技术和社会是紧密联系在一起的。社会的进步发展决定了需求和技术的发展，一个对技术发展有着敏锐感觉的架构师必须对社会有着深刻的认识。一个良好的团队必须有新老交替才能不断进步，老人要舍得带新人。“要让一部分人先富起来，然后先富的带动后富的，最终达到共同富裕。”这是我们上学时学到的话吧，不过要是先富的尽想着向前看，根本没把后富的放在眼里，那这个团队也好、社会也好，也就没多大的持续发展力了。其实我倒是认为现在真正的大富豪还是有不少知民间疾苦的，顶层的和基层的都还能了解屁民们的生活，不了解的是中间层，他们整天生活在富庶小康的温床，经常会提及一些好高骛远、不切实际的想法，而对那些为底层人民谋福利的事情嗤之以鼻，甚至讽刺为“用先进的技术做愚蠢的事情”，目的仅仅是为了哗众取宠和彰显自己的远见卓识。

先写到这里了，其实我自己也在为成为一个真正的架构师而奋斗，一家之言，难免有所偏差，不过还是那句话，“我们一直在努力”。