作者：Ahmad Nassri文章來源：Medium
這幾年來，我發現自己常常做著“軟件架構師”的工作，這讓我意識到，公司很少了解軟件團隊的真正需求，反而傾向於依賴所謂“軟件架構師”來解決問題。
隨之而來的，就是因交付前產品不符合商業預期、而導致的產品架構大規模修改，但這甚至不會影響產品交付日期。畢竟，軟件架構師的責任正如其名：建立宏大而優美的軟件架構。軟件架構師並不需要對架構實現過程負責，他們也並不想參與代碼編寫工作。
我記得有一回，我在團隊中作為開發者，著手實現一個大型、複雜的架構。我是在開發已開始後加入團隊的，並沒有參與架構設計，所以沒過多久，我對整個架構的設計就產生了一系列疑問，比如軟件架構師打算用MySQL 作為數據庫，配合一套複雜的前端緩存程序、一些自製的庫和函數，完成軟件的國際化和本土化。
產品是個簡單的應用程序，作用是將譯文字符串用多種目標語言展示，我認為軟件架構師明顯殺雞用牛刀了。
團隊討論這個問題時，我建議我們用免費輕量的現成替代品，比如gettext，它支持幾乎所有系統和主流編程語言。不幸的是，我的建議被否決了，因為軟件架構師的話是神聖不可侵犯的。我意識到：
- 這位軟件架構師沒有聽過gettext，也沒有任何興趣去了解它。
- 他喜歡用“自己的方式”解決問題，就算其他方案更簡單，他也不喜歡改變。開發成本、產品效率什麼的，統統與他無關。
- 如果他要去寫代碼，實現自己的架構設計，他肯定會意識到這個方案將問題複雜化了，堅持這麼做會浪費非常多時間，然後也許會考慮修改架構。
一個不寫代碼的軟件架構師，對於軟件開發團隊、產品甚至公司，會有什麼影響？
不寫代碼的軟件架構師，有時被稱為“PPT架構師”、“宇航員架構師”、“象牙塔架構師”，他們有特殊的說服技巧，能讓不懂技術的股東們覺得他們很厲害，同時把真正困難而待解決的問題交給開發者，這個現象屢見不鮮。（編註：這些名稱指不寫代碼的軟件架構師指不接地氣，“特殊的說服技巧”原文為 archibabble and talkitechture，分別取前後兩端為talkybabble，“誇誇其談的架構師”之意）
準確的說，如果想要對“軟件架構師是否應該寫代碼”得出確切結論，必須討論這些前提：
- 項目屬於哪個行業？銀行、科技、電信、廣播……？
- 公司規模多大？
- 有現成開發團隊嗎？還是正在打造開發團隊？
- 開發團隊規模如何？
- 預期產出是什麼？（應用程序、服務還是創新？）
咱們一個個來看——
行業
軟件本身和行業無關，難道不是這樣？
我為不少互聯網公司服務過，它們所屬行業包括在線發布、廣告和社交媒體，這些行業相似且相關，這讓我了解了這些行業中的先進技術、行業間有何联系、一些變化會造成什麼影響以及跨行業的創新情況。
如果對當前工作行業的相關行業不能深入了解，軟件架構師就不能成為這個行業的專家。我會花上一定時間了解相關行業，嘗試新的東西：比如去化工行業的公司考察後，我就能思考，如果到時候需要為他們設計軟件，會遇到什麼問題。
但我十年的網頁和移動程序開發經驗有什麼用呢？在設計化學流程模擬器架構時，我怎麼樣才能比那些有過化學行業開發經驗的人做得更好？此外，化工公司大多甚至不需要軟件架構師b，而是需要有計算機科學背景的化學家、化學工程師，他們更適合做這類軟件開發的領頭人。
同樣的，音樂行業也不需要軟件架構師，他們需要的是音樂家（亦是有計算機科學背景的）和軟件開發商，後者並不用懂得音樂理論。Spotify 和iTunes 並不算意外情況，它們甚至不屬於音樂行業，具體業務與音樂本身無關，它們更像是科技和娛樂項目，用於傳播音樂。
讓我們將範圍限製到科技產業，簡化討論。
公司規模
一個開發團隊，需要兩名軟件架構師嗎？你聽過成功的小規模創業公司有專業的軟件架構師嗎？
這不是“是否需要這個角色”的問題。創業公司根本無力承擔專業軟件架構師的成本，每個人都身兼數職，分擔不同任務，就連創始人、CEO 和CTO 有時候都要擼起袖子來頂工。
如果說不考慮創業公司，你的公司規模有多大？幾百、幾千、幾萬人？他們都專攻同一領域嗎？工作都與科技有關嗎？實際上，就連Google、Apple 和Facebook 這樣的巨頭，都會有一部分工作人員職責完全不與科技相關。
我們再縮小討論範圍至“軟件開發部門”，這個部門完全專注於業務的技術部分。那麼，這個部門真有必要雇傭專人，來協助部門之間的溝通、收集需求、最終把握項目方向嗎？
歸根到底，軟件架構師在大公司軟件開發部門到底有什麼職責呢？或者這麼問：“專業的軟件架構師，對於這個部門有什麼貢獻呢？”
下面我從團隊規模的角度來為你解答。
團隊規模
你的軟件開發部門像小團隊一樣整體運轉嗎？還是被分割成幾個團隊，分別專注於不同的項目？
根據我的經歷，如果任務和責任明確，軟件架構師在任何軟件開發團隊中都會成為累贅。
“這和我的職責無關！”、“這就是我的職責，我來決定我們應該怎麼做！”我已經聽厭倦了這兩種論調，這些論調持有者都是團隊蛀蟲，影響團隊協作。
通常“象牙塔架構”由一名或多名架構師設計而成，他們與真正的開發團隊和流程相對生疏。這些貌似大牛的架構師們，會給出一系列模型用於描述架構，不明覺厲的開發者就只能乖乖就範了，因為架構師永遠偉大光榮正確。
由多個小規模團隊（大約15 人或以下）組成的大型軟件開發部門，與多個小規模團隊並沒有什麼區別，每個團隊都要面對待解決的問題、項目完成期限和隨之而來的壓力。
那麼誰來為這些小團隊的軟件架構負責？
安布勒寫道：
每個人都參與了設計，所以每個人都會更進一步了解和接受架構，而且這樣做還能提高架構靈活性，當發現缺陷和問題時，開發者們會更加願意讓它作出改變。當軟件架構師一人設計出“成果”時，他會將其視為“自己的孩子”，沒有人願意聽到別人批評自己的孩子，同理，架構師會抵觸任何批評。而若由團隊設計架構，成員們更多時候會考慮團隊因素，“這不是一個人的事情”，從而樂於反思。
當軟件開發部門就是一個整體時，這個策略就無效了。
團隊很大，或成員地理位置很分散，這兩個敏捷調整模型（Agile Scaling Model，ASM）中的因素能夠影響“所有人共同設計架構”的策略，此時你應該把整體打散成幾個小團隊，因為“共同設計”策略要求整體協作。
有時候軟件開發部門需要某種形式的整體方向和指導，以確保部門生產力用在了正確方向、以及與其他部門能夠順利溝通和協作。
在我看來，這就是少數需要軟件架構師的時刻。然而，軟件架構師應該代表軟件團隊與其他團隊進行什麼互動呢？或者它僅僅是個單向輸送信息的角色？並非如此，軟件架構師的職能不因環境而變：除了設計架構外，還要承擔起促進溝通、攢寫文檔的責任，統一認識並作記錄，起指導作用。
終於為軟件架構師找到一處用武之地了！
預期產出
你的團隊在設計應用程序，還是寫網頁？/
我們已經討論了行業、公司和團隊規模，但最終我們要做的是項目本身。如果你團隊唯一的“項目”僅僅是製作簡單網頁，只需要一點HTML/CSS 技能，還討論架構的話……
現成開發團隊vs. 打造開發團隊
你現在的開發團隊結構存在缺陷嗎？你是否打算僱傭軟件工程師來解決問題？
如果你目標是擴大團隊，那很有可能你已經有了軟件架構師的候選人，他/她是領域專家，而團隊其他成員需要加強合作跟上他的步伐，領會並實現架構。“軟件架構師”的名分並不重要，如果某個員工為這名分斤斤計較、 特別想成為“軟件架構師”時，我會考慮這個人是否適合繼續留在團隊中。
當項目遇到問題、項目管理者問責時，軟件架構師可以把原因歸咎於程序員，“嘿，我早說了，要你們應該用BOJOX 和NADA 2.0 ，現在出bug 了吧。”項目管理者有了這些“原因”，就能把開發報告寫得冠冕堂皇，證明團隊需要一年來重寫這個項目。然後管理者大可以趁著“不做就不犯錯”的這段時間，將期權變現後跳槽。
有時候這些聰明的思想家不知道什麼時候應該止步，他們能創造荒誕、無所不包的宇宙，但，那毫無意義。
如果你正在打造一個開發團隊，那麼請專注於項目本身。
“自下而上”的打造團隊，聰明、勤奮、有強烈學習慾望的程序員是一切的基礎，讓每個人對項目架構有同等發言權，不要遏制創新，“軟件架構師”的名分並不重要。這樣你的隊伍就會變得樂觀而高效率。
總結
不是所有行業都需要軟件架構師，一般能遇到的大多問題都已經有解決方案了，你需要的是執行者，全棧工程師（Full stack software developer）才能完成公司目標，保證產品質量和客戶體驗。
不管一個人有多聰明，他都很難完全掌控項目架構。
當項目架構由整個團隊設計和完善時，團隊成員們會更有協作意識：樂於承擔責任，接受意見和進行修改。
關注最終目標：如果團隊預期產出是軟件上的創新，那你應該考慮僱傭軟件架構師，讓他來寫解決方案、指導團隊。如果你公司是B2C 平台，不要浪費時間考慮這個問題，專心做好業務。
看到這裡，希望你對軟件架構師的職責、價值和僱傭時機有了清晰認知，那麼回到最初的問題：“軟件架構師應該寫代碼嗎？”我想用一段話來回答——
幾個世紀以來，熟練的石匠、建築熟練工、細木工、半吊子、有天賦的外行，和專業建築師（architects）之間的界限已經越來越模糊。以文藝復興時期的建築為例，很多就不是由建築師設計：布魯內勒斯基（Brunelleschi）曾是一名畫家和金匠，米開朗基羅（Michelangelo）是雕塑者，達·芬奇（Leonardo da Vinci）是畫家，阿爾貝蒂（Alberti）是律師，只有布拉曼特（Bramante），作為畫家，曾專業地學習過建築學。這些人之所以被成為建築師，僅僅是因為他們設計了著名建築，就是這麼簡單。——《世界上最漂亮的房子》，加拿大建築設計師維托爾德·雷布津斯基（Witold Rybczynski）
