每位開發人員都應該成為架構師

要想交付最出色的成果，每位開發人員都應當身兼架構師與問題解決者這兩大角色。

有時候我的腦袋裡會突然出現像“微決議（micro-resolutions）”這樣的念頭。基本上，微決議所要探討的是我應該開始做，但在重要性方面還達不到人生高度的事物。

而在審視過程當中，我發現了一位讀者朋友提出的問題。

您提到您自己實際並不喜歡“架構師”這樣的頭銜。我對此表示贊同，因為架構師這樣的詞彙在不同企業當中有著不同的意義。

根據我的個人經歷，架構師可能需要編寫程式碼、設計UML圖表或者單純只是撰寫Word文件。

您難道不覺得開發人員本身就應該是一位身兼架構師與問題解決者兩類角色的程式設計師嗎？

就我的職業生活來講，我擔任過這裡提到的全部工作崗位，因此我的觀點可能在一定程度上存在偏差。不過換個角度來看，我們不妨將問題整理成另外的形式，即“是不是每位開發人員都應當擁有架構師頭銜”或者說“是不是每位架構師都應該承擔開發者職能”？

在對問題做出這樣的簡化之後，我給出的答案是肯定的。

是的，每位開發人員都應當是一位身兼架構師與問題解決者兩類角色的程式設計師。另外，每一位開發人員都應當冠有架構師頭銜。是的，每位開發人員都應當身負“架構師”職責。說到這裡，我不禁想對架構師與開發人員之間的差異進行探討。

下面來看程式設計師/軟體工程師與架構師之間的區別所在：

• 關注範圍：程式設計師專注於具體細節，而架構師專注於“巨集觀視角”。
• 領導關係：程式設計師處於被領導地位，架構師則扮演領導角色。
• 資歷背景：架構師的從業時間一般比程式設計師更長。
• 氣質特性：架構師是重要的夢想家，而程式設計師則是面向繁瑣任務的實幹者。
• 技術取向：架構師做出選擇，而程式設計師提供選項。
• 技能水準：架構師的技能水平高於程式設計師。
• 程式碼編寫：架構師需要編寫之程式碼平均少於開發人員。
• 組織互動：架構師所參與之“業務”會議數量遠多於程式設計師。
• 薪酬水準：架構師薪酬水平高於程式設計師。
• 自身價值：架構師的價值要高於程式設計師。

這些就是整個行業對於兩者之間區別的看待方式。架構師從業經歷更豐富、重要性更高、技術價值更為可觀，因此擁有更迫切的市場需求; 而正因為他們太過關鍵，因此主要精力往往被用於其它事務——而非編寫程式碼——身上。這顯然是種混亂的定義方式，甚至自相矛盾，而角色的內在定位模糊性也讓我們很難通過一刀切方式作為其評判標準。也正因為如此，某些企業中的架構師會負責構建UML圖表，而另一些架構師則幹著跟開發人員完全一樣的工作。

問題在於，我們往往傾向於用一種籠統的定義來概括實際上極為複雜的概念，而對細微差異的關注缺失則導致定義與實質間存在巨大錯位。

事實上，我們的生活穩步前行，每個人都經歷過年輕、缺乏經驗的起步階段，並隨著時間的推移而逐漸提高、成熟且最終獲得源自努力的回報。我們的工作環境認可這種逐步完善的趨勢，並立足於唯才是舉的制度獎勵這種成長。在這條道路上，我們會慢慢迎來屬於自己的“資深”以及“首席”等花環，而領導能力則體現為“架構師”、“經理”以及“主管”等頭銜當中。頭銜等級越高，我們身上肩負的職責與期許就越是重要。另外，在這一推進過程中，我們會不可避免地在領導及業務層面步步上升，並由原本“注重細節”及“勤奮”的青年轉型為“著眼於巨集觀”且“有遠見”的管理者。到這時，我們已經不再執行具體的任務，而更多成為“思維領袖”。

在這樣的背景之下，“架構師”角色以及“架構師”頭銜都有著確切的意義。二者皆是對大家任務執行效果的一種表彰，意味著各位已經成長為較原先更重要、更有價值且更出色的職能角色。這也意味著我們接下來要從事的是不同於以往的工作內容、扮演不同於以往的角色並承擔不同於以往的責任。

但如果我們暫時拋開這些價值判斷，那麼這兩種角色之間還有哪些其它差別？

我們可以將這種差異進一步加以具象化，那麼此類差異往往廣泛存在於各行業及學科當中。一類角色負責制定決策，即著眼於“巨集觀”而較少“親自上陣”，而另一類角色則執行更具針對性的任務，負責“親手”解決問題。說到這裡，我們可以將其比作律師事務所中的工作。事務所合夥人負責案件中的重要決策，而其它更具體、更簡單的任務則由助理完成。

但需要強調的是，炙手可熱的合夥人與看似平凡的助理所負責的工作在本質上並無區別——他們都只是整套業務體系中的執行點之一，負責完成被委以的任務。考慮到這一點，我們可以將同樣的道理引入到程式設計世界當中：經驗豐富的開發人員負責制定技術決策（並建立以其為核心的實現體系），編寫難度最高以及/或者最為關鍵的程式碼片段，同時運營團隊併為新晉開發人員們分配他們力所能及的任務。

響應文章開頭，每一位開發人員都應當在一定程度成為架構師，或者說每位開發人員都應當同時著眼於軟體的巨集觀定位與具體細節。有些開發者技能水平更高及經驗更為豐富（自然也擁有更理想的薪酬待遇），而他們同時也瞭解應當如何制定技術層面的重要決策並將任務分配給誰來完成。不過從根本角度講，其角色定義與普通開發人員並無區別——只是其信任層級更高，或者說達到了每位開發者都應達到的信任水平。

如果我構建一支隊伍以構建軟體解決方案，那麼絕對不會刻意尋求兩種截然不同的成員：一部分專門作為思維領袖執行廣義規劃與技術決策，而另一部分負責日常任務與細節工作。最理想的場景是團隊裡的每位成員都知道該如何解決問題，並通過這兩種有所區別的立場與眼光審視問題的定義與細節走向。從另一個角度講，同時擁有這兩種審視能力的開發人員也必將成為企業中的IT搖滾巨星。