Talk is cheap, show me the code！ 但是在網際網路企業中，身處技術要職的架構師到底需不需要寫程式碼？
在我們的專業領域中有一種普遍存在的誤解：架構師的工作不需要寫程式碼。
就目前看來這似乎沒什麼問題。畢竟，寫程式碼是開發人員的工作。架構師就應該在更重要的任務上忙碌。
但是，讓架構師遠離寫程式碼會限制開發團隊的潛力。當需求和業務需要發生變化時，也可能導致架構混亂。
所以對於業界的誤解，今天我想要為架構師正名，接下來，就讓我們來看看為什麼讓你的軟體架構師參與寫程式碼的工作是一件好事。不過，在此之前，我們首先來看看架構師的日常工作。
01
架構師的工作是什麼？
01
這是一個很常見的問題。許多開發人員、產品經理、甚至連有些架構師都不確定架構師的工作是什麼。一般的定義說他們需要做出高層決策並規定標準。 但是這種說法很模糊。讓我們來深入看看。
架構師應該承擔的工作
理想情況下，架構師需要建立一個技術願景，通過該願景我們可以獲得可維護又可靠的產品。架構師需要協調不同的團隊，共同構建一個相互依存的軟體生態系統。此外，他們還需要分享高層的整合決策，傳達應用程式和元件之間協同工作的方式。除此之外，他們還需要根據常見的軟體問題審查並規定工具和框架，並通過向利益相關者和領導層傳達最終產品的目標和願景，將所有這些聯絡在一起。
所以架構師的工作聽起來很偉大。你可能想知道為什麼我把如此之多的工作都推給了忙忙碌碌的架構師。為了理解這一點，讓我們來看看我剛描述的情況與現實生活的對比。
現實
現實情況看起來因公司而異。事實上，有些公司確實讓他們的架構師在履行其他所有職責的同時也擔負了程式設計的任務。但是這些公司不是這篇文章的討論物件。我想重點討論曾經與我合作過的不參與程式設計工作的架構師在公司裡究竟做了哪些工作。
首先，這位不參與程式設計的架構師將大部分時間都花在了開會上。他還為這些會議準備大量 PPT 和 Visio 的資料。實際上，這是“PPT 架構師”一詞的來源。除此之外，他編寫了設計文件，將自己對軟體設計的看法寫成一本 50 頁的書，與開發人員共享。（可惜這個前期設計已經過了批准的日子）。後來，他還審查其他設計文件，簽署設計選擇，並重復所有這些工作，直到他忘記了 IDE 應該是什麼樣子。
02
如果架構師不參與程式設計會怎麼樣？
如果看不到產品的日常開發過程，那麼人們可能會認為一切都很順利。 時間線看起來還不錯。功能也在持續增加。我們正在朝著我們的目標前進。
首先，庫和工具無法解決問題時，架構師有可能並不知情。可能有一些架構師規定的工具在理想情況下可以正常執行，但是在複雜且常見的用例中這些工具可能會帶來很多困難。 或者恰恰相反，他們推薦了一種適用於複雜場景的工具，但是對於開發人員遇到的簡單日常問題則過於苛刻。
除非架構師使用他們自己推薦的工具，否則就無法真正意識到他們的選擇產生的影響。
設計無法滿足不斷變化的需求
在考慮軟體開發的時候，我們不能假設一個靜態的世界。架構師做的提前設計並不能考慮到所有的可變因素和極端情況。在軟體編寫工作完成之前，我們無法發現其中的細微差別。
總之，架構和設計決策經常需要做出改變。
你可能會說這不是問題。架構師可以回去重新設計系統。然而，實際情況卻並非如此。開發人員注意到有些事情不太對勁。這些事情變得越來越困難。而他們可以做的有：他們可以向架構師彙報這個問題，但是架構師不在其中無法真正掌握情況；他們可以自行重新設計系統；或者他們也可以儘可能地想辦法彌補問題，然後繼續前進。 如果架構師能夠與開發團隊近距離相處，並擔任程式設計的工作，那麼他們就可以看到變化即將到來，並實時修改設計。他也可以預先做最小的設計，並與團隊合作，隨著時間的推移改進系統的架構。
開發人員備受打擊
如果設計只能自上而下地傳達，而且架構師又不在身邊，那麼開發團隊也會在各個方面遭受困苦。首先，正如我上面提到的，情況會發生變化。
如果架構師不在身邊共同討論，那麼這些變化會導致延遲。
其次，許多開發人員都不喜歡刻板的程式設計，他們希望能夠創造設計並做出決策。 如果設計過於精細，那麼創造過程就會消失。
最後，當開發團隊注意到實際情況與架構圖上的不一致時，他們會責怪計劃。而且他們會覺得架構師沒有搞明白狀況。無論這是實情還是他們的想象，編寫軟體過程中的障礙都可以視作架構師的失職。
03
解決方案
在我們注意一些陷阱的前提下，如果架構師參與寫程式碼的工作，那麼我們可以獲得哪些好處呢？
尊重架構師
我曾經見過一些開發人員忽略了對架構師的尊重。畢竟，架構師不參與寫程式碼的工作。他們不知道如何平衡可讀性、設計和可維護性。
因此，如果架構師參與寫程式碼的工作，那麼他們就可以告訴開發團隊他們在並肩作戰。他們瞭解實際情況。而且如果有必要他們也願意攜手同行。
此外，架構師還可以更頻繁地分享設計見解。通常，開發人員看不到架構模式的需求，因為他們從來沒見過可以讓他們的日子更好過的模式。架構師可以通過傳達設計中重要部分的架構來解決這個問題。或者他們可以幫助團隊將程式碼中的混亂部分重構成優雅的東西。
更好地理解設計
如果架構師參與寫程式碼的工作，那麼他們就有機會向開發人員傳達更具影響力的設計思想和原則。看到白板上畫出來的介面卡模式是一回事，而在 IDE 中親眼看到一個介面卡模式是另一回事。
此外，架構師應該鼓勵開發人員多多思考設計。作為導師，你可以教導開發人員處理意外的變化，並找到解決問題的模式和設計。你應該公開討論解決方案的優缺點，提出問題和討論，並開展設計合作。
另一種方法是利用原型。如果架構師將他們的一些架構設計原型化，那麼就可以部分地看到該原型在實際生活中的運作方式，併為團隊提供需要構建的東西。
實時設計更新
參與寫程式碼工作的架構師可以實時地評估備選方案。過度架構的解決方案需要花費太多實現的時間，架構師可以為團隊提供有關開源或購買庫的資訊。
讓架構師與團隊在一起可以確保根據不斷變化的需求調整架構。此外，過度提前設計的工作壓力也會減少。
如果架構師每週都可以參與一點寫程式碼的工作，那麼他們就可以及時地注意到程式碼偏離了願景，從而可以及時地調整方向。此外，架構師還可以更好地處理正在建立的技術債務。而且他們能夠指導團隊何時增加技術債務，何時不能增加技術債務。
最終產品的架構所有權
如果架構師參與最前線的寫程式碼工作，那麼他們就會擁有更多產品的主動權。可以更好地瞭解他們的解決方案為企業帶來的成本。如果他們能夠親手實現自己的解決方案，那麼他們就會很快意識到哪些設計決策非常重要，而哪些設計決策可有可無。
例如，通常架構師需要針對可能發生的每種情況進行規劃。
但是在專案開始時，通常很難知道哪些問題是真實的，哪些是想象的。 或者至少哪些情況不太可能出現。如果最終我們只有 100 個客戶，那麼就沒有必要創造一個冗餘且規模巨大的迷宮。 我們應該專心提供價值。
04
潛在問題
有關為什麼架構師不應該參與寫程式碼的工作，支持者們有以下幾點理由：
-
他們會忽略長期願景或更大的問題。
-
理解原本不需要了解的應用程式的細節。
架構師參與寫程式碼的工作等於鼓勵團隊不配置架構師。
我完全明白。你們希望確保架構師只承擔自己的職責，即制定長期和高層決策。但是，我們並不是要求架構師花費所有時間來編寫程式碼。相反，我們只是他們花費少量時間來幫助他們設計的應用程式變成現實。
至於不配置架構師的觀點，我在別的地方看到過這樣的例子。我們常常會遇到有的架構師很喜歡寫程式碼，卻不願意將最基本部分之外的東西交給其他開發人員。這種架構師需要信任開發團隊來編寫程式碼。隨著時間的推移，開發人員應該能夠承擔越來越複雜的工作。
05
人人受益
最後我認為，讓軟體架構師參與寫程式碼的工作有益於整個團隊和最終產品。同時也可以鼓勵分享設計理念和快速反饋，可以幫助團隊中每個人的成長。
所以讓你的架構師參與寫程式碼的工作吧。讓開發人員參與設計的工作吧。加強團隊合作才能提供最佳解決方案。
作者：Sylvia Fronczak
來源：
原文: