最近在高可用架构群、EGO会员群等多个场合，大家都在讨论架构师的能力的问题，架构师应该具备哪些能力？在面试时如何合适的评估一个架构师的能力？

架构师的两种类型

   第一种是可以将业务实现的人，他可能需要整合公司不同部门的资源、解决不同技术模块整合、解决不同版本之间的兼容性、解决各个模块的技术选型等，解决任务的分解及分配，解决进度上出现的问题。当上面所有这些问题都完成后，架构师顺利帮助公司完成了项目目标。

   第二种是在第一种的基础上，利用技术的力量，改进了一个领域的效率或提升了生产力。比如一个在现有技术基础上提升20%效率的视频解码模块、或者类似美剧硅谷中的，研发出一套压缩比很大且保持高质量信息的压缩算法。目前的大部分互联网创新在某种程度也是利用技术变革的力量，比如电子商务及在线教育等行业。

   如果从输出结果的角度来看，架构师有两种类型，具备技术杠杆能力的和不具备杠杆能力的架构师。并不否认第一种架构师在战略执行层面的作用，他们是各个软件开发团队的中坚力量。但从影响力的角度，其归根结底是在一个画好的表格里面填东西，他从事领域的最终的格局是由市场、运营或者产品主导。而一种是真正具备杠杆能力的工程师或者架构师，他可以利用技术的力量，在填写一个格子的同时，利用技术的力量，将格子的功效放大，影响十倍或者百倍以上的结果。比如在音乐播放软件中，推荐算法的应用彻底改变了用户播放音乐的习惯与体验。

   很多人所说的架构师的设计能力，大多也可以归纳到第一种情况。很多所谓的架构设计，就是拿着多年一成不变的分层模式往业务上套，把业务按照功能规划成软件模块填写到架构图，并且把上下游的调用串起来。这种设计的大多时候是起给客户或者领导展示的作用。程序员代码的整体构思，大多可以通过白板上或者白纸以及程序员直接的沟通很敏捷的完成，大多不需要一个专职画图纸的架构师来指导。

   第一种架构师是可以不写代码的，因为他大部分所做的事情是跟人打交道、分配任务以及解决开发过程中各种进度问题。因此很多技术负责人面试时候看重协调能力等非真正的技术能力。而那些服务甲方项目型的公司，更是特别看重人际关系、沟通能力、展示能力等跟客户打交道的能力。另外一些软件版本历史包袱重的企业，则看重架构师的打补丁能力。由于功能型及偏执型型的团队偏多，因此在很大程度上造成了架构师的能力标准的偏离，在一些讨论的场合，过份看重项目执行中的个别技巧型能力，比如项目管理、人际关系等能力常常还占据了主流的声音。

   但这类架构师只能勉强称为“技术架构师”，因为大部分时候，他做的事情是填格子，而无法做到利用技术的力量，把一个格子放大到10个格子及更多。在另外一方面，这些不写代码进而慢慢丧失代码能力的“架构师”，也不太可能利用技术的力量去做发挥技术杠杆的事情。当然技术架构师也可以驱动工程师去完成一个技术型的大项目，大型的项目也需要合理的组织，但并不意味不写代码的人就比写代码的人做得更好。而那些对技术体系有深入了解及一线体验的架构师，比那些只跟人员管理打交道的人，更有机会利用技术的力量促进变革。

   因此如果希望一个架构师有令人满意的技术驱动能力，他应该具备代码能力，对技术有直接的了解及体验，进而能够精通如何利用技术来改变未来生产力。

如何面试及评估架构师的能力

   Tim 的面试方法是，候选人需要第一步通过电脑上完成一个小型的代码实现，在代码基本符合要求的情况下，才会获得所有面试官可以接受的一个能力起点。如果不做这一点，面试时候，面试官需要费尽心思去问对方项目上更多细节问题，才可能了解一个候选人真正的开发能力。而通过考试，则可以在验证候选人具备一定开发能力的基础上，愉快的聊一些其他轻松的话题。

   在EGO会员讨论时候，一部分创业公司技术负责人担心一些资深的候选人不能接受这种方式，国内这种现象确实也不少见。但换个角度来想，创业公司大多还在起跑阶段，需要的肯定是从事大量一线开发的人。如果面试通不过机考编程，或者是不愿意做题，这种候选人也未必能完全适合创业公司需要。而那些不愿意做一线事情的架构师即使进来，他大部分时候在分派任务或者强化流程，可能让公司的技术层级及开发环节变多、管理成本变高进而导致整体研发效率下降。

   面试时候大家也认可的一些验证架构师能力的方法，比如把当前技术开发中遇到的一些典型性技术场景让对方来提出实现方案，以便评估对方是否具备应对类似场景的能力。在入职之后，可以让新的架构师独立承担及完成一些任务，以便考察对方是否具备独立的架构实现能力。

建议继续学习：

1. 架构师的思考    (阅读：9434)
2. 从“架构师书单”讲开去    (阅读：7988)
3. 架构师给程序员的一封信    (阅读：6821)
4. 读《做人,做事,做架构师》    (阅读：5247)
5. 图解微服务架构演进    (阅读：982)