架構師究竟要不要寫代碼？

Talk is cheap, show me the code！

但是在互聯網企業中，身處技術要職的架構師到底需不需要寫代碼？

在我們的專業領域中有一種普遍存在的誤解：架構師的工作不需要寫代碼。

就目前看來這似乎沒什麼問題。畢竟，寫代碼是開發人員的工作。架構師就應該在更重要的任務上忙碌。

但是，讓架構師遠離寫代碼會限制開發團隊的潛力。當需求和業務需要發生變化時，也可能導致架構混亂。

所以對於業界的誤解，今天我想要為架構師正名，接下來，就讓我們來看看為什麼讓你的軟體架構師參與寫代碼的工作是一件好事。不過，在此之前，我們首先來看看架構師的日常工作。

架構師的工作是什麼？

這是一個很常見的問題。許多開發人員、產品經理、甚至連有些架構師都不確定架構師的工作是什麼。一般的定義說他們需要做出高層決策並規定標準。

但是這種說法很模糊。讓我們來深入看看。

架構師應該承擔的工作

理想情況下，架構師需要創建一個技術願景，通過該願景我們可以獲得可維護又可靠的產品。架構師需要協調不同的團隊，共同構建一個相互依存的軟體生態系統。此外，他們還需要分享高層的集成決策，傳達應用程序和組件之間協同工作的方式。除此之外，他們還需要根據常見的軟體問題審查並規定工具和框架，並通過向利益相關者和領導層傳達最終產品的目標和願景，將所有這些聯繫在一起。

所以架構師的工作聽起來很偉大。你可能想知道為什麼我把如此之多的工作都推給了忙忙碌碌的架構師。為了理解這一點，讓我們來看看我剛描述的情況與現實生活的對比。

現實

現實情況看起來因公司而異。事實上，有些公司確實讓他們的架構師在履行其他所有職責的同時也擔負了編程的任務。但是這些公司不是這篇文章的討論對象。我想重點討論曾經與我合作過的不參與編程工作的架構師在公司里究竟做了哪些工作。

首先，這位不參與編程的架構師將大部分時間都花在了開會上。她還為這些會議準備大量 PPT 和 Visio 的資料。實際上，這正是「PPT 架構師」一詞的來源。除此之外，她編寫了設計文檔，將自己對軟體設計的看法寫成一本 50 頁的書，與開發人員共享。（可惜這個前期設計已經過了批准的日子）。後來，她還審查其他設計文檔，簽署設計選擇，並重複所有這些工作，直到她忘記了 IDE 應該是什麼樣子。

如果架構師不參與編程會怎麼樣？

如果看不到產品的日常開發過程，那麼人們可能會認為一切都很順利。 時間線看起來還不錯。功能也在持續增加。我們正在朝著我們的目標前進。

但還有什麼呢？

架構師無法真正了解工具

如果架構師不參與編程，那麼他們無法親身實踐工具。

首先，庫和工具無法解決問題時，架構師有可能並不知情。可能有一些架構師規定的工具在理想情況下可以正常運行，但是在複雜且常見的用例中這些工具可能會帶來很多困難。 或者恰恰相反，他們推薦了一種適用於複雜場景的工具，但是對於開發人員遇到的簡單日常問題則過於苛刻。

除非架構師使用他們自己推薦的工具，否則就無法真正意識到他們的選擇產生的影響。

設計無法滿足不斷變化的需求

在考慮軟體開發的時候，我們不能假設一個靜態的世界。架構師做的提前設計並不能考慮到所有的可變因素和極端情況。在軟體編寫工作完成之前，我們無法發現其中的細微差別。

總之，架構和設計決策經常需要做出改變。

你可能會說這不是問題。架構師可以回去重新設計系統。然而，實際情況卻並非如此。開發人員注意到有些事情不太對勁。這些事情變得越來越困難。而他們可以做的有：他們可以向架構師彙報這個問題，但是架構師不在其中無法真正掌握情況；他們可以自行重新設計系統；或者他們也可以儘可能地想辦法彌補問題，然後繼續前進。

如果架構師能夠與開發團隊近距離相處，並擔任編程的工作，那麼他們就可以看到變化即將到來，並實時修改設計。他也可以預先做最小的設計，並與團隊合作，隨著時間的推移改進系統的架構。

開發人員備受打擊

如果設計只能自上而下地傳達，而且架構師又不在身邊，那麼開發團隊也會在各個方面遭受困苦。首先，正如我上面提到的，情況會發生變化。 如果架構師不在身邊共同討論，那麼這些變化會導致延遲。

其次，許多開發人員都不喜歡刻板的編程，他們希望能夠創造設計並做出決策。 如果設計過於精細，那麼創造過程就會消失。

最後，當開發團隊注意到實際情況與架構圖上的不一致時，他們會責怪計劃。而且他們會覺得架構師沒有搞明白狀況。無論這是實情還是他們的想像，編寫軟體過程中的障礙都可以視作架構師的失職。

解決方案

在我們注意一些陷阱的前提下，如果架構師參與寫代碼的工作，那麼我們可以獲得哪些好處呢？

尊重架構師

我曾經見過一些開發人員忽略了對架構師的尊重。畢竟，架構師不參與寫代碼的工作。他們不知道如何平衡可讀性、設計和可維護性。

因此，如果架構師參與寫代碼的工作，那麼他們就可以告訴開發團隊他們在並肩作戰。他們了解實際情況。而且如果有必要他們也願意攜手同行。

此外，架構師還可以更頻繁地分享設計見解。通常，開發人員看不到架構模式的需求，因為他們從來沒見過可以讓他們的日子更好過的模式。架構師可以通過傳達設計中重要部分的架構來解決這個問題。或者他們可以幫助團隊將代碼中的混亂部分重構成優雅的東西。

更好地理解設計

如果架構師參與寫代碼的工作，那麼他們就有機會向開發人員傳達更具影響力的設計思想和原則。看到白板上畫出來的適配器模式是一回事，而在 IDE 中親眼看到一個適配器模式是另一回事。

此外，架構師應該鼓勵開發人員多多思考設計。作為導師，你可以教導開發人員處理意外的變化，並找到解決問題的模式和設計。你應該公開討論解決方案的優缺點，提出問題和討論，並開展設計合作。

另一種方法是利用原型。如果架構師將他們的一些架構設計原型化，那麼就可以部分地看到該原型在實際生活中的運作方式，並為團隊提供需要構建的東西。

實時設計更新

參與寫代碼工作的架構師可以實時地評估備選方案。過度架構的解決方案需要花費太多實現的時間，架構師可以為團隊提供有關開源或購買庫的信息。

讓架構師與團隊在一起可以確保根據不斷變化的需求調整架構。此外，過度提前設計的工作壓力也會減少。

如果架構師每周都可以參與一點寫代碼的工作，那麼他們就可以及時地注意到代碼偏離了願景，從而可以及時地調整方向。此外，架構師還可以更好地處理正在創建的技術債務。而且他們能夠指導團隊何時增加技術債務，何時不能增加技術債務。

最終產品的架構所有權

如果架構師參與最前線的寫代碼工作，那麼他們就會擁有更多產品的主動權。可以更好地了解他們的解決方案為企業帶來的成本。如果他們能夠親手實現自己的解決方案，那麼他們就會很快意識到哪些設計決策非常重要，而哪些設計決策可有可無。

例如，通常架構師需要針對可能發生的每種情況進行規劃。 但是在項目開始時，通常很難知道哪些問題是真實的，哪些是想像的。 或者至少哪些情況不太可能出現。如果最終我們只有 100 個客戶，那麼就沒有必要創造一個冗餘且規模巨大的迷宮。 我們應該專心提供價值。

潛在問題

有關為什麼架構師不應該參與寫代碼的工作，支持者們有以下幾點理由：

他們會忽略長期願景或更大的問題。

理解原本不需要了解的應用程序的細節。

架構師參與寫代碼的工作等於鼓勵團隊不配置架構師。

我完全明白。你們希望確保架構師只承擔自己的職責，即制定長期和高層決策。但是，我們並不是要求架構師花費所有時間來編寫代碼。相反，我們只是他們花費少量時間來幫助他們設計的應用程序變成現實。

至於不配置架構師的觀點，我在別的地方看到過這樣的例子。我們常常會遇到有的架構師很喜歡寫代碼，卻不願意將最基本部分之外的東西交給其他開發人員。這種架構師需要信任開發團隊來編寫代碼。隨著時間的推移，開發人員應該能夠承擔越來越複雜的工作。

人人受益

最後我認為，讓軟體架構師參與寫代碼的工作有益於整個團隊和最終產品。同時也可以鼓勵分享設計理念和快速反饋，可以幫助團隊中每個人的成長。

所以讓你的架構師參與寫代碼的工作吧。讓開發人員參與設計的工作吧。加強團隊合作才能提供最佳解決方案。

對此，你怎麼看？

原文：https://dzone.com/articles/should-architects-write-code-you-bet-they-should

作者：Sylvia Fronczak，軟體工程 師。

譯者：彎月，責編：屠敏

【完】

微信改版了，

想快速看到CSDN的熱乎文章，

趕快把CSDN公眾號設為星標吧，

打開公眾號，點擊「設為星標」就可以啦！

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！