在很多程序员的大脑中,都会有这样一个打怪升级的路径:曾经,我对这个路径深信不疑,现在想想,也许是因为初出茅庐的我所看到的江湖太小。慢慢地,在江湖中久了、视野开了,就发现自己想得太简单了。第1个对“架构师”的定义十多年前,在我初入江湖的时候,首先进入了一家位于深圳的大型软件公司,研发人员的规模上千。面试我的人据说是公司中的架构师,我当时心里真的是对这个架构师充满了仰慕之情,以至于至今我都依稀能够回忆起他的容貌和声音。当时的后端主流技术是Struts+Spring+Hibernate,也就是当时业内常说的SSH;前端的主流技术是HTML+jQuery+原生JS。那时还没有管理jar包依赖的maven,也没有开箱即用的SpringBoot,如果在新的项目中要将上述技术整合起来供开发人员适用,往往需要几天甚至几周的时间,而这些工作都是架构师的职责。于是,我给架构师下了第一个定义:架构师就是把各种框架整合到一个项目中,提供通用的代码,支撑开发人员完成业务功能的开发及提供必要的技术支持的人。后来我回到了西安,此时的我,凭借自身的不断努力,已经将上述的几个技术掌握的很好了。在西安的一家规模不大的软件公司中,我也做起了架构师,同时给自己定了一个工作原则:不参与业务功能的开发,只为程序员提供通用能力和技术支持。在之后的几年中,我一直坚守自己对架构是的定义,原理业务知识,一心钻研各种炫酷的技术,也一直作为团队中面对困难的最后一道防线为开发人员提供支持。第2个对“架构师”的定义现在,我已经在江湖中摸爬滚打了12年,在架构师这个岗位上也已经有8年左右,原本简单的认为“架构师即巅峰”的我,中间有一段时间迷失了方向。在不断地与人沟通加上多次的面试经历后,似乎在每个人的心里,对“架构师”这个名词的理解都是不一样的。有一次,在参加一个架构师训练营的时候,培训教材中有一幅图给我留下了很深的印象,虽然原图我已无法找到,但表达的思想如下图所示:讲师将架构师类比为交响乐中的指挥家,在他的描述中,架构师的视角应该比别人高,关注点并非独立的一个个具体问题,而应该是用全局的视角去通盘考虑、整体规划,然后指挥别人去将规划落到实地。如果架构师过分的深入细节,只会让他因无法抬头看路而迷失方向,就像“不识庐山真面目,只缘身在此山中”一样。于是,我对“架构师”有了第二个定义:架构师就是一个站在比别人更高的角度上看待问题,凭借更高的视角而统领全局,不会拘泥于技术细节的人。但这样一个定义也让我在之后的面试中不断地被面试官挑战,在大部分的面试中,面试官对架构师的要求依然是某项技术的深度,而非整体的技术广度。第3个对“架构师”的定义在近几年的工作经历中,我又接触到了另一类架构师,他们常常被称作“解决方案架构师”、“行业架构师”、“交付架构师”和“售前架构师”等。在我最初从事这类工作的时候,我将之前给架构师下的两个定义又重新审视了一遍,似乎此时的工作内容与那两个定义都完全的不同。经过近2年在解决方案架构师这个岗位上的历练,发现这类架构师实际上是作为客户的咨询顾问存在的。工作内容几乎已经脱离编码了,而是给予某一个技术和产品体系,在客户购买前、中、后提供贴身的咨询服务,帮助客户规划技术方向、产品组合以及提供实践方案等。此时,“架构师”的第三个定义在我的心中诞生了:架构师就是站在战略的层面,对企业中信息化技术提供整体解决方案、路线图规划以及合规性监管等工作的人。后来我考取了有“架构师黄金证书”的TOGAF,也向我打开了“企业架构”的大门,这也让我更加确信我对架构师下的第三个定义。“架构师”不是这么定义的虽然我心中对架构师有了3个定义,然而它们非但没有让我对架构师地认识更加清晰,反而让我更加地迷惑。尤其是在面试架构师这个岗位时,明明自己很强,但却总觉得自己跟面试官的对话不在一个频道上。这也一度让我对自己的能力产生了怀疑,开始了自我否定。在深入的思索及阅读相关的资料后,我发现,问题的根源在于对“架构师”这个名词的滥用。Martin