关于程序员和架构师的讨论很多，我想从不同的角度说下。

寻路

当我刚进入软件行业成为一名程序员时，我的理想就是成为一名架构师。架构师这个词的英文叫 Architect，原意是建筑师，因为软件行业参照借鉴了很多建筑行业的概念，所以就借用这个词。我是在学校读书时知道架构师这个名词的，当时很多软件方面的书都是翻译过来的，现在也不知道是谁最早把 Architect 翻译成架构师的了。总之从那时起，架构师这个名词对于我这个还刚准备走出校门的学生来说就特别高大遥远，自然当成了最初的一个职业目标。

可惜，我进入第一家公司后，这是一个家民营 IT 服务企业，我发现居然没有架构师这个职位。我所在的一个几十人团队里，本科刚毕业的是助理工程师，硕士刚毕业的是初级工程师，然后是中级，高级工程师。再往上就变成了项目经理、这个团队就是一个项目经理，下面有几个高工，然后一堆初级和助理工程师。让我颇为失望的是，我当时明显觉得未来我的职业发展目标并不是当时团队项目经理所处的方向。不过一想我离架构师这个目标还早，当时估计最快也要十年吧，先把程序写熟再说，我也不太可能在这里干十年，以后换个就好了。

实际，一年后我就换了个公司，入职后又失望了，发现还是没有架构师这个职位。不仅没有架构师职位，连工程师都不分初、中、高级了，全是软件工程师，再上面是组长、科长、部长，然后就是总经理。科长、部长这类职位是国营性质的，而经理这类职位更像民营公司性质的，这就是一家正在从国营向公司制转型的公司，所以职位也很奇特的混合着。我当时也是想还早，先专注好眼前的事，写好程序做好事情，至于有没有架构师这个职位将来再说。

在这里工程师虽说不分级，但团队里也有一位大家口中的牛人，姓陈，大家称呼陈总，实际并没有承担任何管理职责。工作了十多年了，专注于 IBM AIX 和 HP UX 小型机以及 Oracle 数据库调优。我们那时经常长期出差在客户现场开发、实施，支持上线等，陈总一般不出差。他出现的时候一般都是我快把数据库搞挂的时候，然后就来现场救火，分析磁阵 IO，抓 SQL 调优什么的（当时应用系统都是围绕数据库为中心的）。通过从底向上来发现性能瓶颈，再建议程序优化，当时我觉得他最符合我对架构师这一角色的一些想象，但又总觉得还差点啥，当时是说不上来。总之当时我是很期盼看到一个真正的架构师是怎样的，他们是如何工作的？

在第二家公司工作了几年后，工作了已快 5 年了，我还是没有找到答案，而且感觉走程序员技术发展道路在当前的公司碰到了瓶颈。再次跳槽后，我想之前民营和具有国营性质的公司都没有架构师职位，而且这个名词来自国外，那么外企应该会有吧？尝试去面试过几个外企，不幸的是英语口语太差都没有通过面试，而我那段时间也从广州搬回成都。老实说成都当时的程序员就业环境比广州差不少，工作找的有些郁闷，就干脆休息了半年，好好想想清楚下个五年我该何去何从？

也正是在这赋闲的半年，我突然发现原来除了国企、民营 IT 服务（外包）企业和外企之外，还有一类公司和它们很不一样。这就是互联网公司，而可惜的是成都当时几乎没有任何互联网公司在这边有研发。而正在我等待的时间里，一家新兴快速成长的互联网电商公司正好在成都设立研发中心，时机正好也就加入进去。

奔跑

进了互联网公司后，不仅有了架构师职位还有架构师团队，有了方向又可以放心的作一名程序发力狂奔。不停的写程序，优化代码，追求更优更简洁的代码，重构了一遍又一遍，解决一个又一个问题。我曾在以前的文章中将程序员具体和代码相关的工作比作剑术，修炼代码技能类似练剑的过程。很多程序员梦想着有一天能成为一代高手，面对敌人，抽刀拔剑，刹那间交击，归剑入鞘，敌人倒下。就像线上系统突然出现大问题，你打开电脑，查了几行日志，敲下几行代码，分分钟系统恢复。

好吧，实际这也就在电影里能有，随着系统规模的扩大，程序员需要解决的问题和解决问题的方式完全不同。以前看过一篇文章说，进入大规模分布式时代，局部的代码优化已不是最重要的，不像二十年前硬件制约了软件的规模。更重要的是程序之间的协作方式，沟通路径的简洁清晰性。

一个好的程序员当然能写一手好代码，在我学习写程序的前七八年里，业余时间做了一些练习性质的项目。在 Github 之前的时代，Google 还能访问，在 Google Code 上维护了应该不止十万行的业余之作。后来 Github 兴起后迁移过来，不断练习重构优化维护自己的专属工具库，删减了很多冗余代码又新增了不少，目前还剩下几万行。这个过程持续了七年，基本每年重构优化一次，在 Github 持续 commit 时间最长有 118 天（最近看到有人连击 365 天的，真心佩服）。如今过去两年再回头看曾经的代码，不能说觉得完美到不能再优化了，只是觉得继续下去于我剑术精进终究有限，而更大的价值如今已不再局部的优化上。

此时我已在团队承担总体的系统设计工作，专注于局部代码优化其实是在驱动细节而非本质。资深程序员出身的架构师，单兵作战能力都是极强的，就像《进击的巨人》中的利威尔兵长，具备单挑巨人的能力。可当你面对成群结队的巨人来袭时，个人单挑能力的作用始终有限。这时从程序员到架构师不仅仅是一个名称的变化，有时它也意味着技能和视角的转变。在地上飞奔了七八年的程序员，在面对成群的巨人袭来时，深深的感觉到，杀光巨人不应是目的，真正的目的是到达彼岸。选择合适的路径，坚定的前行，清除或绕过挡道的巨人，到达目的地。

飞行

资深的程序员，每天大部分时间和代码打交道，当需要转变为架构师时，却有一个障碍，借用一句台词来说：

汝今剑术已成 ，而道心未明，唯不能斩绝与代码之情。

开发功能，解决 bug，优化代码，这是一个资深程序员的拿手技能，也是地面作战的基本技能。而一个架构师还需要掌握其他维度的技能，也许就像一个立体机动装置，让你能在需要时飞在空中看清全局，也能落地发起凌厉一击。多了一个空中的维度，过去在地面练到精熟的剑术，飞在空中还有效么，这需要时间去学习，适应新维度的技巧。

这不是一个容易掌握的技能，这正是我曾经写过的从一个点到另一个点连成线的技能升级，需要一个升维的学习过程。所以很多讨论架构师到底还要不要写代码这事儿的，我思考后的结论是，需要拔剑时就拔剑，而无需在意如果每天不拔剑是不是剑就锈住了？当剑术精进后总觉得每次拔剑就要杀人（只处理难题），其实有时拔剑也可以只是切菜（挡路的小问题），只要有助于达到目标。就像《火星救援》里的马克为了回家便要去种土豆，只要开始，解决一个问题，解决下一个问题，解决下下个问题，等解决了足够的问题，就能回家了。飞在空中的架构师就是要在高处看清都有哪些挡在回家路上的必要问题，落地成为进击的程序员们将其一一斩杀。

如今问我，还出剑么？剑还在手，该出就出。那么还练剑么？练，练空中出剑，术还未成，但道心已明。

欢迎工作一到五年的Java工程师朋友们加入Java架构开发：878249276,群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！