如何才能敲开BAT等知名互联网公司的大门？程序猿的职业生涯又是怎么样的？从码农到架构师，这期间要经历什么？以及如何才能在激烈的互联网行业中保持强大的技术竞争力？
目前架构师既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案，确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点。
在整个软件开发过程中都起着重要的作用，并随着开发进程的推进而其职责或关注点不断地变化。在需求阶段，软件架构师主要负责理解和管理非功能性系统需求。在软件设计阶段，负责对整个软件体系结构、关键构件、接口和开发政策的设计。在编码阶段，架构师则成为详细设计者和代码编写者的顾问。随着软件开始测试、集成和交付，集成和测试支持将成为软件架构师的工作重点;在软件维护开始时，软件架构师就开始为下一版本的产品是否应该增加新的功能模块进行决策。
任何架构的变革，都是为了更快的研发速度、更好的扩展性与稳定性、更精准的风险防控能力。IT架构的演变周期基本为2年，即近2年的时间需要回顾和展望当前架构存在的问题、未来2-3年需要解决什么问题等等，以适应互联网高速发展、用户与业务量逐年翻番的速度。
纵观过去几年的架构演变，中国各大IT公司从不缺乏架构创新和探索，从集中式走向自有技术的分布式架构、从分布式走向云计算架构、从云计算架构再走向更加动态化和开放化的开放架构，其中也不乏架构变革或升级比较成功的企业。通过中国系统架构师大会，能够更好的将成功经验得以传承
架构师的核心能力是连接一切的能力，架构师的 Slogan 应该是“连接创造价值”。
现在网上或者书本里，更多是在推崇一万小时定律之类的理论， 你只要相信一万小时定律，你就可以成为某个领域的专家，你在职场就可以成为骨干平步青云，可是， 为什么很多 CEO 或者公司老板既不是专业人士，也没有勤勤恳恳打磨自己的技能，却是 CEO 或者公司老板？ 因为没有人会告诉你， 除了一万小时定律， 还有“连接创造价值”的架构师之路可以选择。
图计算里的图 Node 固然突出，但离开了 Edge， 还称得上什么图， 产生得了什么价值？
电话和移动设备固然重要，但离开了电话线和光纤的连接， 也只能当摆设；
人群聚集的社区和城市固然重要， 但离开了路的连接，那也只能鸡犬相闻，闭关锁国了；
专家也好，架构师也罢，都重要，但在大多数人不能确切的理解架构师的情况下，扶墙老师我不得不为架构师代言啦 ;o)
Eager To Learn
一万小时定律本质上其实是针对同类可重复的事物进行重复性打磨和深入， 但架构师要做的更多是面对未知和新生事物， 所以就需要架构师能够持续学习，才能胜任这个职能。
做架构师不比做专家轻松， 你要持续的学习不同领域的知识， 你要不停的跨界，你要持续的沟通和思考， 只有这样，你才能“搜集足够的素材”， 然后再根据当前场景和目标来进行架构和输出。
单单只是勾画出一幅完美的架构蓝图还远远不够， 一名合格的架构师还要能够领导或者协调大家一起来将这幅架构蓝图落地， 能否落地，能落地多大的架构蓝图， 往往考验的就是一名架构师的领导能力。
在不是很复杂的架构域内， 架构师单凭谋事之心一般就可以成事了，但一旦牵扯复杂的架构域， 要谋事且成事，就需要架构师兼有谋人之心， 做到政教合一往往更是可以事半功倍。 不过， 总体上来说， 领导者不是管理者， 谋人谋事，最好是做到“心简单，脑子复杂”就可以了。如果你愿意追求更高段位，那对随之而来的痛苦和困难要有心理准备 ；）
如果起点是进入一个行业的小白，那么到成为这个行业的专家，至少经历三个阶段：
1、知识的原始获取阶段：刚进去一个行业，我们都是“学徒”，不懂的东西很多，每天只要稍微动动手、动动脑就可以感觉到不错的成长。毕业工作后开始融入一个团队，开始参与项目的开发，有师傅带、有同事学，很多时候你不想学到东西都很难。所以，在这个阶段，是自身技术的爆棚期，是一个快速成长的阶段。
2、知识的结网积累阶段：八年抗战，经历过第一个阶段以后，大家都有了自己的看家本领，技术足以应对日常的工作和研究。每天忙忙碌碌，但是感觉都是重复性的工作，“收获很小”。即使继续学习，发现每天研究和接触到的新知识很多都是重复性的内容。渴望伴随着迷惘可能是这个阶段的特点，从“灵魂深入”隐约感觉到自己应该再多学点东西，但是每次付诸行动感觉都收获颇少，所以开始怀疑和迷惘。
其实，大家忽略了这个阶段最本质的特点：由于知识的广度加快，知识的深度速度“变慢”，但是广度的知识，往往给人一个“肤浅”、“无用”的幻觉。“广”在某个程度上就是“深”，看似无关的经历经验、看似无关的知识点，其实，在经历一个长期的获取、思考、吸收之后，突然有一天，点成线成网，人有了一种“大彻大悟”的感觉，迅速进入第三个阶段。
3、知识的沉淀升级阶段：大彻大悟之后的升华，开始一段新的快速成长的阶段。
曲线只有最低点，没有最高点，所谓“心有多大、世界就有多大”。做为一名技术人员，时刻清楚自己当前的位置。另外，我觉得这个曲线除了对技术人员适用，应该同样适用于其他行业，共勉。
当一个资深开发者变得更高级时会发生什么？一般的，他们会被提拔为“架构师”。有时一个架构师不一定必须成为一个开发者，只要他们拥有更宽广的视角。“最后，总有一个人任命为“架构师”的职位，他要开发的系统和正在开发的系统做出架构上的决策。在一些更大的公司，还有“架构师议会”，每个团队指定的架构师们聚在一起决定着一些明智的事情。
但是我不认为专门设立“架构师”这样的职位是一个好的主意。架构师应该是建筑行业的一个职位，这是无可厚非的，因为不能在项目中期改变和调整原有的架构。但是软件架构是十分灵活的，会在开发的过程中需要不断的进行调整，不应该预先就严格地定义好。而且开发工作和架构设计是如此的紧密关联，所以说某个人决定“什么要做”和“什么不要做”是不科学也不严谨的。这会带来各种各样的问题，主要是因为架构师经常无法全面的考虑到具体的实现是怎么样。如果一个架构师长时间不写代码，他们更加倾向于忽略“实现细节”，转而仅仅考虑抽象设计。但是，抽象总是会造成遗漏，只考虑抽象而不考虑特定的实现这样的解决方案很少可行有效的。
我主张的第一个观点就是：如果你不知道如何详细地编写所有代码地情况下，你就无法在成为一个优秀的架构师。大多数情况下都不是“简单地编码”。如果你已经成为架构师多年，同时也多年没有写过代码了，那几乎可以肯定你不是一个优秀的架构师。
当然，好吧。你可能是一个优秀的架构师。或许在你所在的那个特别的公司里，有人坐在象牙塔中，指挥着码农去整合这个实现那个，这可能说的过去。但即使是这种情况，也有更好的方法。
架构师更应该是一种角色。每个资深的团队成员都应该扮演架构师的角色，不一定每个团队中的某个人。实际上，最好有多个人来扮演架构师。在会议中讨论架构设计和讨论功能设计类似，如果你是那个要实现所有事情的人，那么你需要带着明确的想法去参会。任何的过度设计（大部分架构师经常会犯这个错误）需要在你面前证明是合理的——“我是否愿意去写这些模板代码，或者是否有一种更简单优雅的实现方式”。
职位可以是“软件工程师”，但角色可以是“敏捷专家”、”架构师”、”持续集成官”，等等。如果公司需要一个“架构师议会”去决定系统间更宏观的整合，开发者可以提名某个人去参与这些会议，这个人有可能是对这些系统最了解的人。
我知道现在架构师在想什么——有一些更加高层次的关注点开发要么不太能理解要么不应该为此被打扰。这是大错特错！如果你的开发不理解更高层次的架构规划，那么迟早你会遇到问题的。是的，因为他们要让代码适应你正在规划的更大的蓝图，他们需要被打扰。
还有一方面，那就是团队成员的态度和互动交流。如果某个不是特别优秀或者受人尊敬的开发被提升为“架构师”，那么可能破坏团队的和谐。另一方面，某些人被提升为“架构师”以后可能会过于自信，以至于他们会想当然的去做出设计决定，而不管那些反对他们的好的争论点。
因此，理想的情况（这是我主张的第二个观点）是取消架构师的职位。确保你团队中资深的成员能够参与架构设计和决策，那样他们可能会变得更加积极主动，他们也会对他们开发的成果有一个更加清晰的规划。最重要的是，架构决策不能脱离日常的“现实世界”的开发环境，否则它们会不必要的复杂化。
最后说一句如果你想学习Java工程化、高性能及分布式、高性能、深入浅出。性能调优、Spring，MyBatis，Netty源码分析和大数据等知识点。Java大神交流群 群号为：561614305
注：加群要求
1、具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加。
2、在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加。
3、如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的，可以加。
4、觉得自己很牛B，一般需求都能搞定。但是所学的知识点没有系统化，很难在技术领域继续突破的可以加。
5.阿里Java高级大牛直播讲解知识点，分享知识，多年工作经验的梳理和总结，带着大家全面、科学地建立自己的技术体系和技术认知！
架构之路任重而道远。程序设计和架构设计是互通的，每个人都可以从设计好一个程序往设计好一个系统架构前进。如果现在还无从下手的，我推荐大家可以从领域驱动设计这个概念入手，这是由业务为导向的设计方式，可以对培养设计出落地的架构有很大的帮助。希望可以给大家一些思路和启发。最后引用“俞军”一句名言，我们作为架构师要有“怀疑精神：自我迭代”的心。