筆記原文： 研發工程師想提升面試競爭力，該具備這三個技術認知

研發工程師想提升面試競爭力，需要具備的三個技術認知是什么？架構設計認知、分析問題的認知、能力邊界認知

大多數研發同學對自身技術發展的認知，僅停留在學習了哪種新的技術，掌握了哪種新的開發框架，覺得這樣就能把技術做好，就能成為架構師，

可是現實情況是：你覺得技術滿足應聘部門的要求，可還是面不到想要的職位，這其實與技術認知不足有很大關系，達不到一個高級研發或者是架構師該有的思維層次，在面試時，自然很難講出自己的技術價值與亮點，影響面試競爭力，

下文講解如何提高自己的技術認知

1、對架構設計的認知

很多同學對架構設計的掌握和理解是欠缺經驗的，系統設計問題只能回答出表層的技術名詞，落地沒有實際經驗，拔高沒有理論支撐，

回答架構問題要 立足于點、連接成線、擴散成面，

（1.1）案例-系統拆分問題

兩個人負責交易系統的開發，后續重構將其拆分成報價系統、促銷系統，以及訂單系統

只有兩個人負責這個交易系統，為什么還要做系統架構拆分？而且拆分之后會帶來其他的復雜度，你是怎么考慮的？

系統拆分的架構設計問題，在面試中很常見，候選人給出了四個層面的回答，

1、從訂單系統層面來看，由于交易流程中的訂單系統相對來說業務穩定，不存在很多的迭代需求，如果耦合到整個交易系統中，在其他功能發布上線的時候會影響訂單系統，比如訂單中心的穩定性，基于這樣的考慮，需要拆分出一個獨立的子系統，

2、從促銷系統層面來看，由于促銷系統是交易流程中的非核心系統，出于保障交易流程穩定性的考慮，將促銷系統單獨拆分出來，在發生例外的時候能讓促銷系統具有可降級的能力，

3、從報價系統層面來看，報價是業務交易流程中最為復雜和靈活的系統，出于專業化和快速迭代的考慮，拆分出一個獨立的報價系統，目的就是為了快速回應需求的變化，

4、從復雜度評估層面來看，系統拆分雖然會導致系統互動更加復雜，但在規范了 API 的格式定義和呼叫方式后，系統的復雜度可以維持在可控的范圍內，

這樣的回答很好地表達了應聘者對系統設計的思考與理解，

因為他說出了原有系統中關于訂單、促銷和報價功能耦合在一起帶來的實際問題，這是立足于點，又從交易流程的角度做系統設計串聯起三個系統的拆分邏輯，這是連接成線，最后從復雜度和成本考量的方向夯實了設計的原則，這是擴展成面，

（2）案例分析

如果你是這名應聘者，會怎么回答呢？很多研發同學一提到架構設計就說要做拆分，將一個系統拆分成兩個系統，將一個服務拆分成兩個服務，甚至覺得架構就是做系統拆分，但其實并不理解拆分背后的深層原因，所以往往只能回答得比較表面，無法深入背后的底層設計邏輯，那這個問題的底層邏輯到底是什么呢？有這樣四點，

為什么做架構拆分？

通常最直接目的就是做系統之間解耦、子系統之間解耦，或模塊之間的解耦，

為什么要做系統解耦？

系統解耦后，使得原本錯綜復雜的呼叫邏輯能有序地分布到各個獨立的系統中，從而使得拆封后的各個系統職責更單一，功能更為內聚，

為什么要做職責單一？

因為職責單一的系統功能邏輯的迭代速度會更快，會提高研發團隊回應業務需求的速度，也就是提高了團隊的開發效率，

為什么要關注開發效率？

研發迭代效率的提升是任何一家公司在業務發展期間都最為關注的問題，所以從某種程度上看，架構拆分是系統提效最直接的手段，

所以，架構拆分其實是管理在技術上提效的一種手段，認識到這一點后，就不難理解為什么很多架構師在做系統架構時，會做系統設計上的拆分，甚至認為架構的本質就是拆分了，

2、對分析問題的認知

在實際作業中，技術人員在做系統設計時需要與公司或部門的戰略定位對齊，才能讓你的技術有價值，因為對于系統技術架構升級的問題，業務方、管理者和技術人員的關注點是不同的，

業務方的訴求是在技術升級后，系統有能力迭代功能來滿足市場的要求，所以關注點在系統能力，

管理者的訴求是在技術升級后，系統研發團隊的開發效能得到提升，所以關注點在人效管理，

作為技術人員的你，需要找到自己做系統設計的立足點，來滿足不同人對技術的訴求，而這個立足點通常就是系統設計原則，

所以你應該認識到，系統的設計原則不是亂提出來的，而是針對系統現階段業務發展帶來的主要矛盾提出，才會更有價值且被認可，

（2.1）案例 -

之前我做過一個對原有老系統進行架構改造的系統設計，當時的背景是這樣的，

早期，業務發展比較簡單，團隊規模也不是很大，單體系統可以支撐業務的早期規模，但當業務不斷發展，團隊規模越來越大時，之前的一個業務團隊逐漸發展成了多個業務團隊，這時每個業務團隊都會提出自己的功能需求，

然而，系統現狀仍然是單體架構，研發同學都在同一個系統里進行開發，使得系統邏輯復雜，代碼耦合，功能迭代和交付變得非常緩慢，牽一發而動全身，研發同學都不敢輕易修改代碼，

這個時期系統的主要矛盾就變成了：多人協作進行復雜業務，導致速度緩慢，但業務需求又快速迭代，說白了，就是研發效率不能匹配業務發展的速度，并且單靠加人不能解決問題，

對于這樣的一個系統，此階段的系統架構核心原則就不能隨便定義為要保證高性能和高可用，

那么應該怎么做呢？

針對這樣的問題，我們需要對原有系統進行合理的系統邊界拆分，讓研發人員有能力提速，來快速回應需求變化，這就要求架構師對業務領域和團隊人員有足夠的了解，

類似這樣的情況也是面試中經常出現的考題，比如面試官在問你歷史專案經歷的時候，要重點關注你是如何解決系統核心問題的，所以不要一張口就是高性能、高可用，這會讓有經驗的面試官覺得你很初級，

（2.2）案例分析

面試中，研發人員在回答系統設計問題的時候，要根據系統所處階段的主要矛盾來回答架構設計問題.

在 20 世紀 60 年代，《人月神話》的作者就分析，軟體復雜性來源于兩點：本質復雜度和偶然復雜度，開發工具、開發框架、開發模式，以及高性能和高可用這些僅是偶然復雜性，架構最重要的是要解決本質復雜性，這包括人的復雜性和業務的復雜性，

技術是靜態的，業務和用戶是變化的，具體問題要從具體的業務領域出發，這時有人可能會說，我只想做技術，不想做業務，然而你會慢慢發現，在職業生涯中處理的最有價值的事情，一般都是利用技術解決了業務領域的某階段的主要問題，這也是最復雜的，

而一個優秀的應聘者，在回答中應該向面試官展現出這樣的技術認知，

3、對能力邊界的認知

我在做研發的晉升評審時，常常會問候選人一個問題：你覺得一個高級研發工程師和一個架構師的區別在哪？ 這個問題很多研發同學回答得都不是很好，有些人說需要足夠的技術經驗，懂得高性能、高可用，也有些人說需要懂得管理，帶過團隊，

這些能力固然重要，但不是作為架構師最核心的能力，下面我通過一個例子，來幫你理解一個高級研發工程師和一個架構師的本質區別在哪兒，

（3.1）案例 -

我們先來看一下互聯網一些大廠的中高級研發工程師晉升架構師的標準，如下圖所示：

可以看出，晉升架構師需要掌握架構知識體系以及互聯網的設計經驗，

那么是不是可以這么理解：想要成為架構師，需要在掌握原有技術框架原理與開發基礎之上，再懂得分布式高性能、高可用的設計知識，這樣就可以了？如果你真是這么認為的，那就存在一個技術認知的問題，

可以這樣思考，一個中級或高級研發工程師就不需要懂高性能、高可用的設計手段了嗎？這些在網上應該也不難找到通用的解決方案，那么他就可以成為架構師了嗎？

其實不然，掌味訓聯網架構設計中的高性能、高可用、高擴展這些非功能性設計方案是基礎，但還要看你是站在哪個角色上考慮的，

互聯網大廠職級體系晉升的一個很重要規則，就是你所做的事情的邊界，所能影響到的范圍，

比如，研發工程師和架構師能駕馭的邊界可以如下概括：

一個中高級研發工程師對系統的駕馭邊界至少是模塊或者子系統層面；

一個架構師對系統的駕馭邊界至少是全系統層面；

一個高級架構師對系統的駕馭邊界至少是某一領域層面，

（3.2）案例分析

我們常說，屁股決定腦袋，不在那個位置就不會真正體會到那個位置帶來的問題，

沒有觸達多系統層面的設計，就不會掌握多系統層面帶來的復雜度和解決問題的思考邏輯，但是往往研發同學意識不到這樣的問題存在，即便能碰到一個通盤考慮架構設計的機會，但價值、眼界、認知的形成，也不是一朝一夕的事兒，

那么，你要怎么做才能讓自己更快速地成長呢？你要在作業中養成歸納總結的習慣，形成自己的知識體系，沉淀自己的方法論，提高自己的認知能力，并且跳出舒適區，多爭取擴展自己能駕馭系統的邊界的機會，

在接下來的課程中，我會基于架構設計面試考題的角度，在解決方案、原理理解、實踐經驗，以及知識體系和認知能力等方面，幫你提高應對架構設計問題的能力，

4、總結

我在今天的課程中，通過三個案例為你講解了研發工程師在面試中如何提高競爭力，可以總結為三點，

首先要提高你對系統架構設計的認知能力，一個好的架構師的架構設計不是僅僅停留在技術解決方案上，

其次要提高你分析系統問題的認知能力，做架構設計要具備根據現階段的主要矛盾來分析問題的能力，

最后你要擴大自己能夠駕馭系統的邊界，因為只有這樣才能遇到之前沒經歷過的問題層次，注意我這里說的是問題層次，而不是問題數量，

本節課的思考題是：根據現在的經驗和能力，你覺得想成為一個架構師或者在面試中拿到一個好的 Offer，還有哪些困惑與不解？歡迎你把答案寫到留言區，和我一起討論，

在接下來的課程中，我會通過面試中的各種場景問題，來幫你建立面試中針對系統設計問題的知識體系，

文章結尾，送給你一句話：“同一思維層次解決不了同一思維層次上產生的問題”，

下節課，我將介紹“如何用架構師的視角進行面試”，記得來聽課！