每位開發人員都應該成為架構師
譯文要想交付最出色的成果，每位開發人員都應當身兼架構師與問題解決者這兩大角色。
有時候我的腦袋里會突然出現像“微決議”這樣的念頭。基本上，微決議所要探討的是我應該開始做，但在重要性方面還達不到人生高度的事物。
而在審視過程當中，我發現了一位讀者朋友提出的問題。
您提到您自己實際并不喜歡“架構師”這樣的頭銜。我對此表示贊同，因為架構師這樣的詞匯在不同企業當中有著不同的意義。
根據我的個人經歷，架構師可能需要編寫代碼、設計UML圖表或者單純只是撰寫Word文檔。
您難道不覺得開發人員本身就應該是一位身兼架構師與問題解決者兩類角色的程序員嗎？
就我的職業生活來講，我擔任過這里提到的全部工作崗位，因此我的觀點可能在一定程度上存在偏差。不過換個角度來看，我們不妨將問題整理成另外的形式，即“是不是每位開發人員都應當擁有架構師頭銜”或者說“是不是每位架構師都應該承擔開發者職能”？
在對問題做出這樣的簡化之后，我給出的答案是肯定的。
是的，每位開發人員都應當是一位身兼架構師與問題解決者兩類角色的程序員。另外，每一位開發人員都應當冠有架構師頭銜。是的，每位開發人員都應當身負“架構師”職責。說到這里，我不禁想對架構師與開發人員之間的差異進行探討。
下面來看程序員/軟件工程師與架構師之間的區別所在：
- 關注范圍：程序員專注于具體細節，而架構師專注于“宏觀視角”。
- 領導關系：程序員處于被領導地位，架構師則扮演領導角色。
- 資歷背景：架構師的從業時間一般比程序員更長。
- 氣質特性：架構師是重要的夢想家，而程序員則是面向繁瑣任務的實干者。
- 技術取向：架構師做出選擇，而程序員提供選項。
- 技能：架構師的技能水平高于程序員。
- 代碼：架構師需要編寫之代碼平均少于開發人員。
- 組織互動：架構師所參與之“業務”會議數量遠多于程序員。
- 薪酬：架構師薪酬水平高于程序員。
- 自身價值：架構師的價值要高于程序員。
這些就是整個行業對于兩者之間區別的看待方式。架構師從業經歷更豐富、重要性更高、技術價值更為可觀，因此擁有更迫切的市場需求; 而正因為他們太過關鍵，因此主要精力往往被用于其它事務——而非編寫代碼——身上。這顯然是種混亂的定義方式，甚至自相矛盾，而角色的內在定位模糊性也讓我們很難通過一刀切方式作為其評判標準。也正因為如此，某些企業中的架構師會負責構建UML圖表，而另一些架構師則干著跟開發人員完全一樣的工作。
問題在于，我們往往傾向于用一種籠統的定義來概括實際上極為復雜的概念，而對細微差異的關注缺失則導致定義與實質間存在巨大錯位。
事實上，我們的生活穩步前行，每個人都經歷過年輕、缺乏經驗的起步階段，并隨著時間的推移而逐漸提高、成熟且最終獲得源自努力的回報。我們的工作環境認可這種逐步完善的趨勢，并立足于唯才是舉的制度獎勵這種成長。在這條道路上，我們會慢慢迎來屬于自己的“資深”以及“首席”等花環，而領導能力則體現為“架構師”、“經理”以及“主管”等頭銜當中。頭銜等級越高，我們身上肩負的職責與期許就越是重要。另外，在這一推進過程中，我們會不可避免地在領導及業務層面步步上升，并由原本“注重細節”及“勤奮”的青年轉型為“著眼于宏觀”且“有遠見”的管理者。到這時，我們已經不再執行具體的任務，而更多成為“思維領袖”。
在這樣的背景之下，“架構師”角色以及“架構師”頭銜都有著確切的意義。二者皆是對大家任務執行效果的一種表彰，意味著各位已經成長為較原先更重要、更有價值且更出色的職能角色。這也意味著我們接下來要從事的是不同于以往的工作內容、扮演不同于以往的角色并承擔不同于以往的責任。
但如果我們暫時拋開這些價值判斷，那么這兩種角色之間還有哪些其它差別？
我們可以將這種差異進一步加以具象化，那么此類差異往往廣泛存在于各行業及學科當中。一類角色負責制定決策，即著眼于“宏觀”而較少“親自上陣”，而另一類角色則執行更具針對性的任務，負責“親手”解決問題。說到這里，我們可以將其比作律師事務所中的工作。事務所合伙人負責案件中的重要決策，而其它更具體、更簡單的任務則由助理完成。
但需要強調的是，炙手可熱的合伙人與看似平凡的助理所負責的工作在本質上并無區別——他們都只是整套業務體系中的運行點之一，負責完成被委以的任務。考慮到這一點，我們可以將同樣的道理引入到編程世界當中：經驗豐富的開發人員負責制定技術決策（并建立以其為核心的實現體系），編寫難度最高以及/或者最為關鍵的代碼片段，同時運營團隊并為新晉開發人員們分配他們力所能及的任務。
響應文章開頭，每一位開發人員都應當在一定程度成為架構師，或者說每位開發人員都應當同時著眼于軟件的宏觀定位與具體細節。有些開發者技能水平更高及經驗更為豐富（自然也擁有更理想的薪酬待遇），而他們同時也了解應當如何制定技術層面的重要決策并將任務分配給誰來完成。不過從根本角度講，其角色定義與普通開發人員并無區別——只是其信任層級更高，或者說達到了每位開發者都應達到的信任水平。
如果我構建一支隊伍以構建軟件解決方案，那么絕對不會刻意尋求兩種截然不同的成員：一部分專門作為思維領袖執行廣義規劃與技術決策，而另一部分負責日常任務與細節工作。最理想的場景是團隊里的每位成員都知道該如何解決問題，并通過這兩種有所區別的立場與眼光審視問題的定義與細節走向。從另一個角度講，同時擁有這兩種審視能力的開發人員也必將成為企業中的IT搖滾巨星。
原文標題：Every Developer Should Be an Architect
