架构师考核标准

   （观点仅为基于个人经验的个人观点，不代表对错，仅供参考）    

    前言

       很多公司招聘架构师不知道该怎么考核该架构师是否符合公司需要。核心来讲也确实比较难定性，技术全面就一定是好架构师吗？大厂的架构师一定能解决行业架构问题吗？行业干久了的研发能承担架构指责吗？都不一定，但有些情况是确定的，好的架构师是踏着无数失败走出来的，就像将军是踏着无数尸体爬出来的一样。产品的核心成长规则一般表现为：搭建基础框架->切分业务模块->解决关联关系及性能问题->基于对业务的深度了解及技术磨合的成熟性重构代码 ->三次重构->成功，这是一套标准流程。

       三军易得，一将难求，架构师看似简单好像给机会谁都能干，他们比普通码农貌似也没多干多少，甚至是脏活累活都甩给了别人，下面的甚至还私下暗思他水平还不如我呢。当看轻这个职位的时候说明你还不在这个档次上。另外就是领导层多数不是资深码农出身，他们信奉的思想是王者，无视代码的重要性，当产品使用繁琐、交付困难时一味对下施压，而不会提出核心解决方案，即使提出了缺乏一将也难以达成预期，这种现象也造成了行业代码的普遍拉胯，核心问题不是没好的技术人员是没真正懂架构师职责的架构师，以及懂架构师指责的领导调度资源配合架构师的方案落地。

     架构师指责

    （一）技术选型

      架构师给出方案采用springcloud alibaba成熟体系作为微服务的底座，组件采用nacos、gateway、fegin、Sentinel。数据库采用doris+mysql。方案一下大家采用该方案，似乎是认为这是抬手就能做到的事，其实是大家想当然的接受了一锅熟饭，忽略了后面的厨师规划、食材采购、加工环节。架构师只所以选择doris是它简单易用，OLAP特性明显，屏蔽了分布式计算、分表分库、性能优化等很多问题，他比对了greenplum等一众方案后，择取了最适合团队当下情况的方案。选择nacos作为注册中心顺带解决了配置管理问题且简单易用，可以为开发人员较少很多麻烦。普通程序员直面一种方案，架构师要评比、测试所有方案，也不能肯定的表示一定合理，需要时间给出答案。 

        领域不同，架构师的选型出发点也不同，比如医疗领域，它是复杂业务线、项目化的，市场普遍表现为产品难交付、个性化难以有效满足，甲乙双方矛盾深厚。架构师选型时就不得不考虑易交付性、可扩展性、个性化等问题。有公司将模块切分的很细，技术方案做的很长，就很容易导致项目难交付，开发、扩展成本重，客户今天提的问题一个月了还发布不了新版。有公司架构师缺乏经验提出的概念太理想化，数据库支持市面各种类型，一个组件可适配多种方案，其实是能基于一种数据库、一种模式开发到位就是行业的标品。想法过于先进、模块切分过细、技术线太长、精细度过高对于传统行业的交付都是致命的。

（二）深度关注业务

       互联网领域业务线直观比如订单模块、支付模块、商品模块，但并发度高，数据量大；行业领域业务线复杂，模块间的交织严重，但后者并发量数据量低。不同情景，架构师指责也有很大不同，前者重在解决并发问题、大数量问题，后者要结合业务推进解决事务问题、模块交叉问题、个性化问题、扩展问题等。这也导致了前者在技术领域处于引领者，后者在自身业务中挣扎。行业架构师就需要深度了解业务才能有效切分模块，行业的复杂性很大的原因就是架构师与业务的脱节性，想当然的把问题抛给现场，现场实施人员的技术能力本就比研发矮着很多（不是说实施人员水平不行，他们在客户沟通、业务专精方面是强者）。把系统核心封装好，个性化转移出来，提高现场的效应效率及交付成本都是架构层面要深度考虑的。这也是为啥行业架构师要随时做好失败的准备，组织二次重构，可惜的是二次重构的机构普遍公司不会有，另外架构师也阻挡不了产品的疯狂设计、领导好高骛远的要求，一次次妥协中有能力的带着失望离开了，没能力的当天和尚撞天钟。

        有行业经验的架构师不能确保一次成型，但会大大降低返工的频率跟次数，历历在目的失败教训是他们宝贵的财富，也是必然的代价。领导层一定程度上需要理解项目重构的方向、意义、协调难度，提供侧面帮助性支持。

（三）怎么评判架构师是否适合

1）是否喜欢钻研技术，并应用于实践。

2）是否有强烈的责任心

3）是否对某个行业有深度的了解，对架构理念（模块划分原则、重构策略、行业特点）有深度理解

4）经验总结能力