要想交付最出色的成果，每位開發(fā)人員都應(yīng)當(dāng)身兼架構(gòu)師與問題解決者這兩大角色。

有時候我的腦袋里會突然出現(xiàn)像“微決議”這樣的念頭?；旧?，微決議所要探討的是我應(yīng)該開始做，但在重要性方面還達(dá)不到人生高度的事物。

而在審視過程當(dāng)中，我發(fā)現(xiàn)了一位讀者朋友提出的問題。

您提到您自己實際并不喜歡“架構(gòu)師”這樣的頭銜。我對此表示贊同，因為架構(gòu)師這樣的詞匯在不同企業(yè)當(dāng)中有著不同的意義。

根據(jù)我的個人經(jīng)歷，架構(gòu)師可能需要編寫代碼、設(shè)計UML圖表或者單純只是撰寫Word文檔。

您難道不覺得開發(fā)人員本身就應(yīng)該是一位身兼架構(gòu)師與問題解決者兩類角色的程序員嗎？

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

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

是的，每位開發(fā)人員都應(yīng)當(dāng)是一位身兼架構(gòu)師與問題解決者兩類角色的程序員。另外，每一位開發(fā)人員都應(yīng)當(dāng)冠有架構(gòu)師頭銜。是的，每位開發(fā)人員都應(yīng)當(dāng)身負(fù)“架構(gòu)師”職責(zé)。說到這里，我不禁想對架構(gòu)師與開發(fā)人員之間的差異進行探討。

下面來看程序員/軟件工程師與架構(gòu)師之間的區(qū)別所在：

• 關(guān)注范圍：程序員專注于具體細(xì)節(jié)，而架構(gòu)師專注于“宏觀視角”。
•  領(lǐng)導(dǎo)關(guān)系：程序員處于被領(lǐng)導(dǎo)地位，架構(gòu)師則扮演領(lǐng)導(dǎo)角色。
• 資歷背景：架構(gòu)師的從業(yè)時間一般比程序員更長。
• 氣質(zhì)特性：架構(gòu)師是重要的夢想家，而程序員則是面向繁瑣任務(wù)的實干者。
• 技術(shù)取向：架構(gòu)師做出選擇，而程序員提供選項。
• 技能：架構(gòu)師的技能水平高于程序員。
• 代碼：架構(gòu)師需要編寫之代碼平均少于開發(fā)人員。
• 組織互動：架構(gòu)師所參與之“業(yè)務(wù)”會議數(shù)量遠(yuǎn)多于程序員。
• 薪酬：架構(gòu)師薪酬水平高于程序員。
• 自身價值：架構(gòu)師的價值要高于程序員。

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

[[162745]]

問題在于，我們往往傾向于用一種籠統(tǒng)的定義來概括實際上極為復(fù)雜的概念，而對細(xì)微差異的關(guān)注缺失則導(dǎo)致定義與實質(zhì)間存在巨大錯位。

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

在這樣的背景之下，“架構(gòu)師”角色以及“架構(gòu)師”頭銜都有著確切的意義。二者皆是對大家任務(wù)執(zhí)行效果的一種表彰，意味著各位已經(jīng)成長為較原先更重要、更有價值且更出色的職能角色。這也意味著我們接下來要從事的是不同于以往的工作內(nèi)容、扮演不同于以往的角色并承擔(dān)不同于以往的責(zé)任。

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

我們可以將這種差異進一步加以具象化，那么此類差異往往廣泛存在于各行業(yè)及學(xué)科當(dāng)中。一類角色負(fù)責(zé)制定決策，即著眼于“宏觀”而較少“親自上陣”，而另一類角色則執(zhí)行更具針對性的任務(wù)，負(fù)責(zé)“親手”解決問題。說到這里，我們可以將其比作律師事務(wù)所中的工作。事務(wù)所合伙人負(fù)責(zé)案件中的重要決策，而其它更具體、更簡單的任務(wù)則由助理完成。

但需要強調(diào)的是，炙手可熱的合伙人與看似平凡的助理所負(fù)責(zé)的工作在本質(zhì)上并無區(qū)別——他們都只是整套業(yè)務(wù)體系中的運行點之一，負(fù)責(zé)完成被委以的任務(wù)。考慮到這一點，我們可以將同樣的道理引入到編程世界當(dāng)中：經(jīng)驗豐富的開發(fā)人員負(fù)責(zé)制定技術(shù)決策（并建立以其為核心的實現(xiàn)體系），編寫難度最高以及/或者最為關(guān)鍵的代碼片段，同時運營團隊并為新晉開發(fā)人員們分配他們力所能及的任務(wù)。

響應(yīng)文章開頭，每一位開發(fā)人員都應(yīng)當(dāng)在一定程度成為架構(gòu)師，或者說每位開發(fā)人員都應(yīng)當(dāng)同時著眼于軟件的宏觀定位與具體細(xì)節(jié)。有些開發(fā)者技能水平更高及經(jīng)驗更為豐富（自然也擁有更理想的薪酬待遇），而他們同時也了解應(yīng)當(dāng)如何制定技術(shù)層面的重要決策并將任務(wù)分配給誰來完成。不過從根本角度講，其角色定義與普通開發(fā)人員并無區(qū)別——只是其信任層級更高，或者說達(dá)到了每位開發(fā)者都應(yīng)達(dá)到的信任水平。

如果我構(gòu)建一支隊伍以構(gòu)建軟件解決方案，那么絕對不會刻意尋求兩種截然不同的成員：一部分專門作為思維領(lǐng)袖執(zhí)行廣義規(guī)劃與技術(shù)決策，而另一部分負(fù)責(zé)日常任務(wù)與細(xì)節(jié)工作。最理想的場景是團隊里的每位成員都知道該如何解決問題，并通過這兩種有所區(qū)別的立場與眼光審視問題的定義與細(xì)節(jié)走向。從另一個角度講，同時擁有這兩種審視能力的開發(fā)人員也必將成為企業(yè)中的IT搖滾巨星。

原文標(biāo)題：Every Developer Should Be an Architect