為什么我認為架構師需要堅持寫代碼？

最近在高可用架構群、EGO會員群等多個場合，大家都在討論架構師的能力的問題，架構師應該具備哪些能力？在面試時如何合適的評估一個架構師的能力？

架構師的兩種類型

第一種是可以將業務實現的人，他可能需要整合公司不同部門的資源、解決不同技術模塊整合、解決不同版本之間的兼容性、解決各個模塊的技術選型等，解決任務的分解及分配，解決進度上出現的問題。當上面所有這些問題都完成后，架構師順利幫助公司完成了項目目標。

第二種是在第一種的基礎上，利用技術的力量，改進了一個領域的效率或提升了生產力。比如一個在現有技術基礎上提升20%效率的視頻解碼模塊、或者類似美劇硅谷中的，研發出一套壓縮比很大且保持高質量信息的壓縮算法。目前的大部分互聯網創新在某種程度也是利用技術變革的力量，比如電子商務及在線教育等行業。

如果從輸出結果的角度來看，架構師有兩種類型，具備技術杠桿能力的和不具備杠桿能力的架構師。并不否認第一種架構師在戰略執行層面的作用，他們是各個軟件開發團隊的中堅力量。但從影響力的角度，其歸根結底是在一個畫好的表格里面填東西，他從事領域的最終的格局是由市場、運營或者產品主導。而一種是真正具備杠桿能力的工程師或者架構師，他可以利用技術的力量，在填寫一個格子的同時，利用技術的力量，將格子的功效放大，影響十倍或者百倍以上的結果。比如在音樂播放軟件中，推薦算法的應用徹底改變了用戶播放音樂的習慣與體驗。

很多人所說的架構師的設計能力，大多也可以歸納到第一種情況。很多所謂的架構設計，就是拿著多年一成不變的分層模式往業務上套，把業務按照功能規劃成軟件模塊填寫到架構圖，并且把上下游的調用串起來。這種設計的大多時候是起給客戶或者領導展示的作用。程序員代碼的整體構思，大多可以通過白板上或者白紙以及程序員直接的溝通很敏捷的完成，大多不需要一個專職畫圖紙的架構師來指導。

第一種架構師是可以不寫代碼的，因為他大部分所做的事情是跟人打交道、分配任務以及解決開發過程中各種進度問題。因此很多技術負責人面試時候看重協調能力等非真正的技術能力。而那些服務甲方項目型的公司，更是特別看重人際關系、溝通能力、展示能力等跟客戶打交道的能力。另外一些軟件版本歷史包袱重的企業，則看重架構師的打補丁能力。由于功能型及偏執型型的團隊偏多，因此在很大程度上造成了架構師的能力標準的偏離，在一些討論的場合，過份看重項目執行中的個別技巧型能力，比如項目管理、人際關系等能力常常還占據了主流的聲音。

但這類架構師只能勉強稱為“技術架構師”，因為大部分時候，他做的事情是填格子，而無法做到利用技術的力量，把一個格子放大到10個格子及更多。在另外一方面，這些不寫代碼進而慢慢喪失代碼能力的“架構師”，也不太可能利用技術的力量去做發揮技術杠桿的事情。當然技術架構師也可以驅動工程師去完成一個技術型的大項目，大型的項目也需要合理的組織，但并不意味不寫代碼的人就比寫代碼的人做得更好。而那些對技術體系有深入了解及一線體驗的架構師，比那些只跟人員管理打交道的人，更有機會利用技術的力量促進變革。

因此如果希望一個架構師有令人滿意的技術驅動能力，他應該具備代碼能力，對技術有直接的了解及體驗，進而能夠精通如何利用技術來改變未來生產力。

如何面試及評估架構師的能力

Tim 的面試方法是，候選人需要第一步通過電腦上完成一個小型的代碼實現，在代碼基本符合要求的情況下，才會獲得所有面試官可以接受的一個能力起點。如果不做這一點，面試時候，面試官需要費盡心思去問對方項目上更多細節問題，才可能了解一個候選人真正的開發能力。而通過考試，則可以在驗證候選人具備一定開發能力的基礎上，愉快的聊一些其他輕松的話題。

在EGO會員討論時候，一部分創業公司技術負責人擔心一些資深的候選人不能接受這種方式，國內這種現象確實也不少見。但換個角度來想，創業公司大多還在起跑階段，需要的肯定是從事大量一線開發的人。如果面試通不過機考編程，或者是不愿意做題，這種候選人也未必能完全適合創業公司需要。而那些不愿意做一線事情的架構師即使進來，他大部分時候在分派任務或者強化流程，可能讓公司的技術層級及開發環節變多、管理成本變高進而導致整體研發效率下降。

面試時候大家也認可的一些驗證架構師能力的方法，比如把當前技術開發中遇到的一些典型性技術場景讓對方來提出實現方案，以便評估對方是否具備應對類似場景的能力。在入職之后，可以讓新的架構師獨立承擔及完成一些任務，以便考察對方是否具備獨立的架構實現能力。