【面试专题】｜技术&架构设计提升系列：面试题目及解题的正确姿势（1）

​----- 学习笔记 -----

今天是咱们第一节，我想和你聊一聊：研发工程师想提升面试竞争力，需要具备的三个技术认知是什么。

   

在我参加研发同学述职的时候，发现几乎每个人最后都会用一页 PPT 来规划自己的未来职业发展，比如：我目前处在初级研发工程师阶段，下一步要成为中高级研发工程师，最终要成为一名研发架构师。 

但是在进一步地追问后，大多数研发同学对自身技术发展的认知，仅停留在学习了哪种新的技术，掌握了哪种新的开发框架，觉得这样就能把技术做好，就能成为架构师。

可是现实情况是：你觉得技术满足应聘部门的要求，可还是面不到想要的职位。这其实与技术认知不足有很大关系，你达不到一个高级研发或者是架构师该有的思维层次，在面试时，自然很难讲出自己的技术价值与亮点，就会影响面试竞争力。

而今天这一节，我会从架构设计认知、分析问题的认知、能力边界认知三个角度出发，讲解研发工程师如何提高自己的技术认知，在面试的过程中更加体现价值和竞争力，进而获得满意的 Offer。

对架构设计的认知

在开篇词中提到，面试官通常会在考察完候选人基础技术能力之后，再问一些关于系统架构设计上的问题，这时如果你回答得比较好，很容易得到面试官的认可，也会掩盖个别技术问题上回答的不足。

但实际上，很多研发同学对架构设计的掌握和理解是欠缺经验的，系统设计问题只能回答出表层的技术名词，落地没有实际经验，拔高没有理论支撑。那你怎么回答面试中的架构设计问题呢？

关于架构设计的问题，一定要立足于点、连接成线、扩散成面，用这样的思路回答才能让面试官满意。下面就通过一个例子，来帮你理解什么是回答架构设计问题该有的认知。

例子 

我曾面试过一名研发工程师，他在介绍过往经历时，称自己在重构一个负责交易流程的系统时，将其拆分成报价系统、促销系统，以及订单系统，而当时他们只有两个人负责交易系统的开发工作。

针对他的经历，我的问题是：你们只有两个人负责这个交易系统，为什么还要做系统架构拆分？而且拆分之后会带来其他的复杂度，你是怎么考虑的？

 

系统拆分的架构设计问题，在面试中很常见，候选人给出了四个层面的回答。 

从订单系统层面来看，由于交易流程中的订单系统相对来说业务稳定，不存在很多的迭代需求，如果耦合到整个交易系统中，在其他功能发布上线的时候会影响订单系统，比如订单中心的稳定性。基于这样的考虑，需要拆分出一个独立的子系统。 

从促销系统层面来看，由于促销系统是交易流程中的非核心系统，出于保障交易流程稳定性的考虑，将促销系统单独拆分出来，在发生异常的时候能让促销系统具有可降级的能力。

从报价系统层面来看，报价是业务交易流程中最为复杂和灵活的系统，出于专业化和快速迭代的考虑，拆分出一个独立的报价系统，目的就是为了快速响应需求的变化。

从复杂度评估层面来看，系统拆分虽然会导致系统交互更加复杂，但在规范了 API 的格式定义和调用方式后，系统的复杂度可以维持在可控的范围内。

**这样的回答很好地表达了应聘者对系统设计的思考与理解。因为他说出了原有系统中关于订单、促销和报价功能耦合在一起带来的实际问题，这是立足于点，又从交易流程的角度做系统设计串联起三个系统的拆分逻辑，这是连接成线，最后从复杂度和成本考量的方向夯实了设计的原则，这是扩展成面。**

案例分析

 如果你是这名应聘者，会怎么回答呢？很多研发同学一提到架构设计就说要做拆分，将一个系统拆分成两个系统，将一个服务拆分成两个服务，甚至觉得架构就是做系统拆分，但其实并不理解拆分背后的深层原因，所以往往只能回答得比较表面，无法深入背后的底层设计逻辑，那这个问题的底层逻辑到底是什么呢？有这样四点。

• 为什么做架构拆分？通常最直接目的就是做系统之间解耦、子系统之间解耦，或模块之间的解耦。

• 为什么要做系统解耦？系统解耦后，使得原本错综复杂的调用逻辑能有序地分布到各个独立的系统中，从而使得拆封后的各个