怎样才能成为架构师
— 扫描二维码 —加入架构集结群
对技术感兴趣的同学可进群（备注:Java）
我们研发人员发展的技术路径(仅供参考)：
一、高级程序员（管理自己）
1、负责核心复杂功能的实现方案设计、编码实现
2、负责疑难BUG分析诊断、攻关解决
二、研发Leader（管理一个团队）
1、团队任务管理：开发工作量评估、开发任务分配
2、团队生产质量提升：代码审核、开发风险识别/报告/协调解决
3、团队生产力提升：代码模板研发与推广、最佳实践规范总结与推广、自动化研发生产工具研发与推广
4、团队专业力提升：招聘面试、新人指导、领导复盘总结改进
三、技术总监（管理多个团队leader）
1、组建平台研发部，搭建公共技术平台，方便上面各条产品线开发。
2、通过技术平台、通过高一层的职权，管理和协调各个产品线组。现在每个产品线都应该有合格的研发Leader和高级程序员了。
四、架构师（专注某个平台的技术架构规划）
需要分离管理族和专业族。整个研发团队可能已经超过100来人了，需要有人专注来做架构规划、设计、日常维护。不能让研发总监和研发Leader又做管理又做技术一股脑都扔给他们。
1、架构分析：从功能性需求中识别出需要增加的非功能性需求，好满足性能、可扩展、解耦/集成、安全、可运维、高可用、易部署、易更新。并且识别完非功能型需求，还要做技术选型、技术架构风险识别、技术实现工作量评估
2、架构设计与实现：非功能性模块的架构设计、接口设计、代码实现。所以需要的是有代码实现能力还要有架构思维的工程师，不需要画PPT的工程师
3、业务架构设计与实现：需要对跨系统的接口进行识别、实现、维护，需要对能写成公共代码类库的进行分析、识别、接口设计、实现、变更维护。
4、重构：架构师需要经常做Bug分析、非模板性和公共类库代码检查，以发现代码腐烂程度，以发现还有哪些代码没有做很好的架构与精心的代码设计。所以重构是经常性维护发生的，不是攒到某一刻动大手术，甚至推翻重做，那就不叫重构了。
五、CTO (软件产品和技术是统一管理的.是商业、产品、技术、管理、团队相平衡的综合统管)
1、业绩达成：洞察客户需求，捕捉商业机会，规划技术产品，通过技术产品领导业务增长，有清晰的战略规划、主攻方向，带领团队实现组织目标
2、前沿与平台：到这个研发规模规模级别了，一定要有专门的团队做技术应用创新探索和前沿技术预研。而且要和技术平台团队、应用研发团队形成很好的联动作用，让创新原型试点能够很平滑的融入商业平台再让应用研发线规模化的使用起来。大量的前沿探索都死在了内部，做完试点就停滞了，这就需要CTO做好整体的衔接推动工作。
3、研发过程管理：站在全局立场来端到端改进业务流程，为业务增长提供方便
4、组织与人才建设：公司文化和价值观的传承；研发专业族团队梯队建制建设、研发管理族团队梯队建制建设；创建创新激发机制，激发研发人创新向前发展，激发黑马人脱颖而出
===============================================
架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。总结构架师自我培养过程大致如下（仅供参考）:
1、架构师胚胎( 程序员:初级工程师)
学习的知识是语言基础、计算机基础理论、网络基础，操作系统等相关基础知识等，应该在大学完成。
2、架构师萌芽(高级程序员)
工作几年后，熟悉分布式系统、高性能系统搭建。精通某种开发语言，掌握架构设计能力和业务理解能力。熟练掌握各种设计模式以及具备一定运维能力。
3、架构师幼苗(资深工程师)
高级工程师是在技术深度上精通，资深需要在广度上扩大知识面，熟悉多种开发语言。同时具备团队管理经验。
4、 软件架构师的正式成型在于机遇、个人努力和天赋 软件构架师其实是一种职位，但一个 程序员在充分掌握软构架师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理构架、如何不断的抽象和归纳自己的构架模式、如何深入行业成为能够胜任分析、构架为
一体的精英人才这可不是每个人都能够遇上的馅饼。
我们找好路径以后，看看我们如何做??
1、走正确的路
如果想成为一个架构师，就必须走正确的路，否则离目标越来越远，正在辛苦工作的程序员们，你们有没有下面几种感觉？
一、我的工作就是按时完成领导交给我的任务，至于代码写的怎样，知道有改进空间，但没时间去改进，关键是领导也不给时间啊。
二、我发现我的水平总是跟不上技术的进步，有太多想学的东西要学，Jquery用的人最近比较多啊，听说最近MVC比较火，还有LINQ，听说微软又有Silverlight了……
三、 我发现虽然我工作几年了，除了不停的coding，Ctrl+c和Ctrl+V更熟练了，但编码水平并没有提高，还是一个普通程序员，但有人已经做到架构师了。
四、工作好几年了，想跳槽换个工作，结果面试的考官都问了一些什么数据结构，什么垃圾回收，什么设计模式之类的东西，虽然看过，但是平时用不着，看了也忘记了，回答不上来，结果考官说我基础太差。。。
有没有，如果没有，接下来就不用看了，你一定是大拿了，或者已经明白其中之道了，呵呵。
如果有，恭喜你，你进入学习误区了，如果想在技术上前进的话，就不能一直的coding，为了完成需求而工作，必须在coding的同时，让我们的思维，水平也在不停的提高。
写代码要经历下面几个阶段：
一 、你必须学习面向对象的基础知识，如果连这个都忘了，那你的编程之路注定是在做原始初级的重复！
很多程序员都知道类、方法、抽象类、接口等概念，但是为什么要面向对象，好处在哪里，要解决什么问题？只是明白概念，就是表达不清楚，然后在实际工作中也用不上，过了一段时间，面向对象的东西又模糊了，结果是大多数程序员用着面向对象的语言做着面向过程的工作，因此要学习面向对象，首先应该明白面向对象的目的是什么？
面向对象的目的是什么？
开发语言在不断发展，从机器语言，到汇编，到高级语言，再到第四代语言;软件开发方法在不断发展，从面向过程，面向对象，到面向方面等。虽然这些都在不断发展，但其所追求的目标却一直没变，这些目标就是：
1.降低软件开发的复杂度
2.提高软件开发的效率
3.提高软件质量：可维护性，可扩展性，可重用性等。
其中语言的发展，开发方法的发展在1,2两条上面取得了极大的进步，但对于第3条，我们不能光指望开发方法本身来解决。
提高软件质量：可维护性，可扩展性，可重用性等，再具体点，就是高内聚、低耦合，面向对象就是为了解决第3条的问题。因此要成为一个好的程序员，最绕不开的就是面向对象了。
二、 要想学好面向对象，就必须学习设计模式。
假定我们了解了面向对象的目的，概念了，但是我们coding过程中却发现，我们的面向对象的知识似乎一直派不上用场，其实道理很简单，是因为我们不知道怎么去用，就像游泳一样，我们已经明白了游泳的好处，以及游泳的几种姿势，狗刨、仰泳、蛙泳、自由泳，但是我们依然不会游泳。。。。
因此有了这些基本原则是不行的，我们必须有一些更细的原则去知道我们的设计，这就有了更基础的面向对象的五大原则，而把这几种原则更详细的应用到实际中来，解决实际的问题，这就是设计模式，因此要学好OO，必须要学习设计模式，学习设计模式，按大师的话说，就是在人类努力解决的许多领域的成功方案都来源于各种模式，教育的一个重要目标就是把知识的模式一代一代传下去。
因此学习设计模式，就像我们在看世界顶级的游泳比赛，我们为之疯狂，为之着迷。
三 学习设计模式
正像我们并不想只是看别人表演，我们要自己学会游泳，这才是我们的目的所在。
当我们看完几篇设计模式后，我们为之精神振奋，在新的coding的时候，我们总是想努力的用上学到的设计模式，但是经常在误用模式，折腾半天发现是在脱裤子抓痒。。。
当学完设计模式之后，我们又很困惑，感觉这些模式简直太像了，很多时候我们分不清这些模式之间到底有什么区别，而且明白了设计过程中的一个致命的东西--过度设计，因为设计模式要求我们高扩展性，高重用性，但是在需求提出之初，我们都不是神，除了依靠过去的经验来判断外，我们不知道哪些地方要扩展，哪些地方要重用，而且过去的经验就一定是正确的吗？所以我们甚至不敢再轻易用设计模式，而是还一直在用面向过程的方法在实现需求。
四 学习重构
精彩的代码是怎么想出来的，比看到精彩的代码更加令人期待，于是我们开始思考，这些大师们莫非不用工作，需求来了没有领导规定完成时间，只以设计精彩的代码为标准来开展工作？这样的工作太爽了，也不可能，老板不愿意啊。就算这些理想的条件他都有，他就一开始就设计出完美的代码来了？也不可能啊，除非他是神，一开始就预料到未来的所有需求，那既然这些条件都没有，他们如何写出的精彩代码？
Joshua Kerievsky在那篇著名的《模式与XP》〔收录于《极限编程研究》一书）中明白地指出：在设计前期使用模式常常导致过度工程（over-engineering)。这是一个残酷的现实，单凭对完美的追求无法写出实用的代码，而「实用」是软件压倒一切的要素。
在《重构-改善既有的代码的设计》一书中提到，通过重构（refactoring），你可以找出改变的平衡点。你会发现所谓设计不再是一切动作的前提，而是在整个开发过程中逐渐浮现出来。在系统构筑过程中，你可以学习如何强化设计；其间带来的互动可以让一个程序在开发过程中持续保有良好的设计。
总结起来就是说，我们在设计前期就使用设计模式，往往导致设计过度，因此应该在整个开发过程，整个需求变更过程中不断的重构现在的代码，才能让程序一直保持良好的设计，由此可见，开发过程中需要一直重构，否则无论当初设计多么的好，随着需求的改变，都会变成一堆烂代码，难以维护，难以扩展。所谓重构是这样一个过程：「在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构」。重构的目标，就是设计模式，更本质的讲就是使程序的架构更趋合理，从而提高软件的可维护性，可扩展性，可重用性。
《重构-改善既有的代码的设计》一书也是Martin Fowler等大师的作品，软件工程领域的超级经典巨著，与另一巨著《设计模式》并称"软工双雄"，不可不读啊。
五 开始通往优秀软件设计师的路上
通过设计模式和重构，我们的所学和我们工作的coding终于结合上了，我们可以在工作中用面向对象的思维去考虑问题，并开始学习重构了，这就像游泳一样，我们看完了各种顶级的游泳比赛，明白各种规则，名人使用的方法和技巧，现在是时候回家去村旁边的小河里练练了，练习也是需要有教练的，推荐另一本经典书叫《重构与模式》，引用他开篇的介绍，本书开创性地深入揭示了重构与模式这两种软件开发关键技术之间的联系，说明了通过重构实现模式改善既有的设计，往往优于在新的设计早期使用模式。本书不仅展示了一种应用模式和重构的创新方法，而且有助于读者结合实战深入理解重构和模式。
这本书正是我们需要的教练，值得一读。
六 没有终点，只有坚持不懈的专研和努力。
经过了几年的坚持，终于学会了灵活的运用各种模式，我们不需要去刻意的想用什么模式，怎么重构。程序的目标，就是可维护性，可扩展性，可重用性，都已经成了一种编程习惯，一种思维习惯，就像我们联系了几年游泳之后，我们不用再刻意的去考虑，如何让自己能在水上漂起来，仰泳和蛙泳的区别..... 而是跳进水里，就自然的游了起来，朝对岸游去。但是要和大师比起来，嘿嘿，我们还有很长的路要走，最终也可能成不了大师，但无论能不能成为大师，我们已经走在了成为大师的正确的路上，我们和别的程序员已经开始不一样，因为他们无论再过多少年，他们的水平不会变，只是在重复造轮子，唯一比你快的，就是ctrl+c和ctrl+v。
正确的路上，只要坚持，就离目标越来越近，未来就一定会是一个优秀的架构师，和优秀架构师的区别，可能只是时间问题。
相关阅读
架构师是什么
点好看的同学，今年加薪^-^↓