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