目录
一、架构师的分类
技术型
综合型
业务型
理论型
二、架构师的工作
业务沟通
技术设计
实施推广
四、招聘与应聘
招聘架构师
需要了解业务真相
了解雇员
被神话了的T职级
如何应聘架构师
五、修行
在一个信息爆炸却多半无用的世界，清晰的见解就成了一种力量。在理论上讲，人人都能参与这场以“人类未来”为主题的辩论并发表高见，但想要保持清晰的认识并不容易。而通常的情形是，我们根本没有注意到这场辩论，或者根本不清楚关键问题所在。因为手边总有更紧急的事：上班、照顾孩子或者侍奉年迈的双亲。可是，历史不会因此就对你宽容，这实在太不公平了，但是，谁又能说历史是公平的呢？--摘自《人类简史》[以色列] Yuval Noah Harari
做为一名资深软件架构师(自知水平一般，承蒙公司厚爱给予此Title)。多年来曾设计过很多应用、也招聘过很多架构师，所幸接触过形形色色的人才。长久以来一直想对自己多年的架构工作进行一次总结，清晰的描述一下软件架构师这个职位，也为有志成为架构师的同学们提供一点参考。无奈每次复盘都杂乱无章，这一拖就是两年，直到看到Yuval的书才有了点清晰的概念，也就有了这篇blog。此文中所有观点只代表本人，水平有限文笔一般，如有不妥请不吝赐教，感谢！！！
一、架构师的分类
模糊的边界
很多事情需要有清晰的评判标准才能做准确的分类，简单如A级和B级轿车区分的标准之一就是轴距大于还是小于2900mm。不幸的是随着一些事务的复杂化，即使原来比较清晰的界限在现实世界中也比较难以区分，比如在电商平台的类目划分中，童装应该归属服装类还是母婴类？单从类目上很难说的清，所以现在一些电商公司不会在这个类目归属上做过多讨论，反而从童装业务的实际运营归属于事业部上做评定和业务的运营。
如何定义架构师与高级工程师的标准(薪资、title、技术水平......）以及如何划分架构师的类别，相信这个问题很多人都没有仔细思考过又或者在不同公司文化下会有不同的标准。不管最终结论如何，其员工所掌握或擅长的技能在不同的公司都是大同小异。所以笔者暂时从员工群体的维度给出以下分类，并从职业轨迹、个人技能、工作内容这三个方面加以描述，即：
技术型
一般此类架构师在大学毕业后就直接进入了IT行业，按着实习、初级、中级、高级、架构师这样的轨迹发展。多数是科班出手，中途会经历不同的公司但很少换职业。在工作3、5年后会逐渐对柔性技能感兴趣，又因处在职业生涯初期阶段，此类架构师技术思维占主导一般比较注重理性思考，这是一个优势但这种理性思维不转变也会给日后往更高高层次的发展带来很大的障碍。
做为个体如果发现此障碍难以跨越，建议早做规划，比如钻究技术达到某一领域的技术专家或是达到研究的技术水平，虽不容易但至少也是自己比较擅长的领域。可惜的是在局部地区并不存在这类人才成长的文化和土壤，但也不必沮丧，随着全球化进程加快，眼光可以放在全世界，因为从长远来看此类群体才是科技进步的中坚力量且比较容易获得自我价值。
综合型
到底综合哪些内容，这个不太好说。但架构师或高阶架构师的发展一定或多或少的融合了除技术外的知识，包括但不限于管理、沟通或其它。这里不太想说过多的柔性内容，虽然这也是做为一个架构师不可或缺的技术。
软件的设计肯定是基于业务的，随着技能和经验的增加，架构师一定会对某个领域的业务越来越精通。所以这里的综合就是技术+业务的综合。此类架构师我把它理解为真正的架构师。然对于技术型的架构师定义为技术专家会比较合适。
业务型
严格来说业务架构倾向于业务，并不属于软件技术范畴。笔者最早知道的这个名词来源于DDD(领域驱动设计)。DDD主要强调的复杂软件设计。软件的复杂即不是业务复杂也不是技术复杂，实际情况是在业务和技术脱节的背景下，业务需求的变更、规模化以及复杂化所带来的软件系统难以扩展之间的难度，进而又会导致业务和产研团队之间配合的矛盾。
此类架构师要求即精通业务又略懂技术，是业务和产研人员的中间桥梁。在国外一般由业务人员来承担，但在国内这种情况下从头培养很难，所以建议由技术人员转型。另外一点需要注意的是技术并不是懂的越多越好，即使很懂有时也要把握一下尺度，避免打击研发团队的信心。笔者在实际工作中就接触过一个此类型的同事，他在设计产品的时候会把系统的数据流同时输出，包括系统划分、数据传输对象等完全可以做为技术设计文档来使用，但研发团队认为跨界了在实际配合中经常发生矛盾，最后甚至演变成了为挑毛病而挑毛病。
理论型
这是一种时代的畸形的产物，悲哀的地这种畸形产物基本占剧了这个行业的半边天，而且比较受欢迎。其实这得益于地域性的软件文化。比如招聘时要求能发射火箭但实际工作就是拧螺丝，从性价比的角度来说也无可厚非，但如果公司没有很好的培训和成长的自由空间往往会得不偿失，
从另一个角度来讲这种现象的出现本质上是公司管理或是老板的文化导致的，相信很多人也深受其害：“劣币现象”、“PPT文件”、“内卷”......对于这一点笔者只能说存在即合理，但从事务发展规律来看任何事务都存在一个周期，好比中国上下5000年几十个朝代的兴衰轮替。软件行业也是如此可以学习、可以仿制，但最终想要占剧主导必须要创新，另外一点笔者又真正有痛其不争 怒其不幸的感慨，希望越来越好吧。
二、架构师的工作
架构师永远是乙方
从本章开始就不再按架构师的分类进行描述了，多数公司对架构师这一岗位并没有太明确的职责界线，管理、开发、项目、设计都需要涉及，此时至于类型很多时候就显得无关紧要了。从另一个角度来讲公司很多时候是个群体，个人一旦加入群体，智慧在很多时候就不再重要。此时群体表现的和原始人区别不大。正常情况下要完成以下三块工作：
业务沟通
架构师往往是一个承上启下的角色。一部分工作就是上行下达：和自己部门的业务方、其它的业务方、领导、一线研发等等。这个沟通是基于对业务的理解再加上沟通技术。
这里的一个重点是对业的理解，而且是对业务的快速理解。原因是架构师要接触很多不同的业务，有时也会受理很多救火的任务。如果缺少在短时间内或是现场听别人口述就理解业务的能力，就很难与其它人形成一种讨论或讲价的能力。
技术设计
技术设计怎么理解呢，如今技术迭代很快，围绕不同技术的生态圈也越发完整。在某个时间点上个人是没有那么多的时间和精力去追这些新技术的，必须要尽快形成自己的知识体系然后对新技术以理解的方式去学习和应用。
回到主题上来，架构师工作重中之重之一的“技术选型”的重点是对技术版本的选择，并不是对所使用的技术的选择。技术的选择在现阶段已经不是问题了，比如一个高并发的服务，基本脱离不开redis、分布式数据库这两类中间件，但选择哪个redis版本、要不要分片用多少分片、数据库分多少表这些工作并不是人人都可以做的。
所以技术造型的重点是：对不同技术版本的选择和容量的规划。
实施推广
同业务沟通不同，本节中实施推广的主要对象是研发，分两种情况：1、如果是横向工作，推广的对象就是其它的技术部门；2、如果是本部门多数是更细节的需求设计实现。
考察架构师的能力是表述能力和项目推广的能力，除了沟通技巧后，建议去学习一些类似PMP这类专业的知识，因为项目管理是门学问同时也是一门艺术。没有专业的学术是无法达到管理艺术的高度的。
四、招聘与应聘
招聘架构师
你招聘的是一个凡人，还是一个救世主？如果需要救世主请去庙里！
举一个在Boss直聘上看到的JD例子吧，为避免一些麻烦笔者就不公布具体公司了，大概招聘要求如下：
- 35岁之内，211、985硕士
- 大厂互联网经验，至少3年50人+管理经验
- 重点技术要求来了：
- 前端：精通js、html、react、vue框架
- 后端：精通java、python、c++、go++至少两种语言；
- APP端：精通IOS、安卓的App开发；
- 大数据：精通大数据、storm、hadoop等技术；
- AI：精通deeplearn、pytorch等深度学习技术；
- Devops：开发设计过全流程；
- 了解IDC设备，可以安装、调试；
看到这个JD后，笔者想想了是不是还遗漏了哪些技术点没写呢？想了半天好像也没想到其它点，最后个人结论就是请贵公司支届里试试吧，也许还有可能。
需要了解业务真相
这一点笔者从两方面来谈谈：
首先，公司在招聘架构师前一定要知道贵公司要解决的是什么问题再梳理JD内容；因为笔者看过很多JD内容都是抄的，还是那句话，痛其不争 怒其不幸，连JD都抄的话，说实话是认真的吗？
其次，负责招聘的面试官一定要了解自己公司的业务，因为架构设计没有标准，不同公司间的同类业务或是同一个业务由不同架构师来设计都会产出不同的结果。
架构师面试的考察重点大体分为两块内容：1、候选人对对往项目的理解、描述和思考，这一点主要是考察候选人的表达和总结能力，是否能形成自己的框架和思考并能完整口述让别人听的明白，让别人能听明白这很重要；2、就几个业务点同候选人深度讨论，这主要是考察候选人对一个问题的思考和架构设计功底以及一些技术点或技术框架的运用。
了解雇员
这里很强调一个概念叫群体效应，之阐述其中的一个观点就是个人加入群体的就不再具体个人冷静、理性和思考的特定，群体不会思考，它只是受外界环境的影响而频繁做出极端的行为。大概理解一下，就是一个团队的智慧水平的高低不是由团队中水平最高的人决定的，在缺少引导的情况下往往做做出很多愚蠢的决定。存在领袖的情况下会好很多，适时的引导能保证团队会往好的方向发展。
技术团队也是一样，这里举几个例子，在产研团队经常会定一些考核指标，比如bug数、bug修改时间、需求交付时间等。这些指标如果旨在考核技术人员，其实并没有好坏之分。因为很多时候最好的方法是最容易实施的那一个，而不是最完美的那一下。所以最容易实施的那一个是经不出理性的推敲的。
在公司解决不了团队问题而选择空降时，事先一定要想好几个方面的问题：1、团队到底出了什么问题；2、团队需要一个怎么样的人来解决哪些问题？3、候选人的人物画像？如果以上问题不清楚往往效果不会太好(业务储备类的招聘除外)。
被神话了的T职级
最初提出职级概念并实施的好像是GM或IBM公司，记不太清了。在90年代左右传入中国，其中HW公司据说当时花了10亿请了外国一家公司设计了现在职级体系。再后来随着互联网的快速发展，各大问部厂商也会设计了公司的职级体系。其中以阿里的T系统最为出名，甚至一度成为行业内事实上的标准。成为稳定一个技术人员水平高低的一个重要依据，直至今日也是很多公司招聘条件之一。
其实呢，笔者感觉这个T职级被过渡神话了。首先，从本质来讲，这是企业达到一定规模后再发展的一种科学管理方法，它是根据企业实际情况而定的，适用企业但同一套标准并不适用于所有企业。背后的逻辑是企业的规模和文化。
比如，在互联网公司一般会分为T技术和M管理两个序列，表像上来看M是在公司组织架构上挂名的，比如经理、总监。T在公司组织架构上不挂名，即一个部门只有一个经理，但可以有多个与经理同级别的T序列技术人员。
那么T和M是如何晋升的呢，简单来讲，一个应届生在一家公司初始入职时全是T系列，当升到高T时，就会面临一个选择，是走管理还是走技术路线。一般会在T6升T7时面临这个选择。同时序列和Title是实际关联的，Title一般只会出现在劳动合同中并不会出现在公司的组织架构软件中。
虽说序列的升级都需要评审，一般流程是员工准备10分钟左右的PPT，当场答辩最后由评委打分最终汇总结果。但不同公司的操作方法也不太一样，比如一个应届生在T1至 T3这个级别，按工作年限晋升，评审只是走个形势。有些公司则是应届生转正后就是T3级别，另外T4T6一般都是由本部门的人来当评委，多数还是以考察技术能力为主。但T6升T7或是更高职级时则是由其它部门来考核。
虽说都有特定的标准，但标准的解读有时会由评委的主观意见占主导，另外人脉、PPT展示和话术上的影响也不容忽视，尤其是在高T职级晋升时。
由于这种常态化的模式，加上很少有降级的情况发生（基本没有），导致市场上越来越多的高T员工存在，这时的高T多多少少是掺了水份的。这里不去讨论其真实性和可操作性，只是希望这只是一个参考标准不能做为评定某一招聘岗位的条件之一，可以解读但不要过分依赖。因为那是别人家的孩子。
笔者也见过太多这方面失败的案例，其实是文化和企业的影响。比如笔者见过一个CEO花大价钱招了一个T9，结果两个半月后报怨说，2个半月了连业务都没搞明白。更详细聊过发现，T9在这段时间弄了很多规划关于人力关于职责的。
笔者没回答什么，其实背后的逻辑很简单，业务不是2个月就能弄懂的，公司出现混乱的情况是管理问题并不是技术问题，最好是从内部解决，而不是寄希望于一个外部的高T在短时间内就能解决掉。所以请记住许愿请去庙里。
一个事实是要精通自己的业务，要精通领域，但只能了解你的业务。
如何应聘架构师
你取代不了团队，但你可以引导团体
了解自己、了解JD
人往高处走，但高处往往很挤很冷，还会有一些陷阱在高处等着。所以要面试之前一点要了解个人的优势，因为个人知识体系的形成是多年经验积累的结果，转变的成本很大。
所以尽量不要转行，对即将面试的公司一定要事先了解公司业务、文化、规模，甚至了解下公司的一些公告报表等。这里有一个逻辑关系：市场-->行业-->公司。如果整体市场不行，那么即使现在很火的公司也只是虚假繁荣，很大可能性不能长久。这点可以从公司融资情况、主要负责人的履历来综合思考。另一点上人们常说：人生在世，有时跟对了人也是一种幸事，对于这种事笔者认为这和中彩票的机率差不太多，不建议在面试时过多考虑。
了解面试
笔者的建议是面试者在面试前一定要了解对方。有选择的参加，甚至可以按练生找感觉、试探深入、最终目标公司这三类给对方分类。
即使这样还是不够，在实际面试过程中还会存在以下问题：1、套方案；2、公司没有标准流程，面试内容没有实质的内容。所以在面试过程中，如果候选人真的不感兴趣，建议提前中止，何必浪费时间呢。很遗憾的是很少有人会有这种判断力，都是尽力走完对方安排的全流程，把自己处在一个弱势的一方。
五、修行
谎言永远存在，先从认清自我开始
从教育说起
在当前的主流观念中，最为大众认可的观念是：教育在很大程度上能够改变一个人，使其不断完善，甚至建立起人与人之间的平等关系。本质上教育既不能使人更道德，也不能使人更幸福；即不能更改人的天性，也不能更改人天生的热情。并且，假如受到不良引导，教育的作用就会弊大于利。
唯一可确定的是教育可以提升专业能力。从小学到大学，一个人在缺少个人主动性的情况下死记硬背，其后果就是学生自我轻视、丧失主见。它使受教育的人非常厌恶自己生活的状态，一心想摆脱它。这种教育制度在社会底层创立了一支无产阶级大军，在社会顶层，培育出一群轻浮的中产阶段，他们多疑和轻信，即视国家为王道，又总忘不了表示敌意，把自己的过错推给政府，但离开政府的干预又会一事无成。
国家利用教科书创造出一批有文凭的人，可是它能用到的只是其中一小部分，因此不得不让大多数人失业。结果是农民不想当农民、工人不想当工人，多数人希望自己的后代端着国家公务员这个铁饭碗，因为公务员不需要任何自我定位或者体现出个人的主动性。
万人走独木桥，在规定的日子里，面对一组评委，在两个小时内准确回答评委提出的一切知识。但在一个月以后就不再具备这种能力。传统教育的弊端就是极度的延迟了人们接触真实社会的时间。因为生活中获得成功的条件是判断力、经验、主动性和性格，这些都不可能从教科书中得到。
了解自我
关于自我的描述已经是一个老生常谈的问题了，甚至可以升级为一个哲学问题。鸡汤告诉我们要了解自我，但人生不是虚无的，了解自我的前提还是要生存，比如世界上幸福指数最高的是一个南非的一个小国家的男人，在那里只有女人劳动供养男人。假使那些男人连饭都吃不饱的话估计也没空幸福了。
很多哲理离我们很近但似乎又很远，但有一个不容忽视的事实就是数字科技的进步并不遵循以往社会的进程和规律，有些已经发生、有些可能会很快发生，这些事实我们是不容忽视了。往往这个时间做为个体的我们来说更要多多剖析自己，不是为了生活，仅仅是为了生存。
- 电子商务；
- 在线支付；
- AI自动化；
以上这几个科技创新的例子还有很多技术的出现，无疑全是围绕工业或环境等因素展开，改变了世界的每个角落。同时也造成了大批工人失业，但同时也创造出了很多新的工作机会，所以个体经过短时间的转型还能生活的很好。
但最近以chatGPT为代表的人工智能不同以往，它在消灭的同时，并没有创造新的工作机会。而且它所真正代替的是脑力而不是体力。假使人工智能与生物科技相结合，事实上某些机构或财团已研究多年了，如果一旦成功，那么大众面临的可能不是失业而是生存的问题了。这个ISSUE听起来有点吓人，但这就是现实世界中正在发生的事实。虽说离我们有点远，
所以人家会了解的比较深入，做为个体的我们虽没有资源做那么深入的了解，但也要充实自己，了解自己。至少把技能变成自己的一部分，不至于离开所谓的公司平台就无法生存。
写在最后
如上所述，软件架构师虽不是一个很了不解的职位，但也是一个高端技术职位，也是很多技术人员追求的一个岗位。笔者希望所有奋斗在一线的IT伙伴们都能达到这个本源的高度，而不是简简单单的一为了一个title。因为越往上走意味着竞争越惨烈、通往金字塔尖的路也越来越窄。
还是那句话，编程是一门实用技术，是一门可终身受益的技能。它只生存于网络中，网络是无国界的，甚至不受现有制度、空间和时间的限制。
