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

Talk is cheap, show me the code！ 可是在互聯網企業中，身處技術要職的架構師到底需不須要寫代碼？

在咱們的專業領域中有一種廣泛存在的誤解：架構師的工做不須要寫代碼。

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

可是，讓架構師遠離寫代碼會限制開發團隊的潛力。當需求和業務須要發生變化時，也可能致使架構混亂。 因此對於業界的誤解，今天我想要爲架構師正名，接下來，就讓咱們來看看爲何讓你的軟件架構師參與寫代碼的工做是一件好事。不過，在此以前，咱們首先來看看架構師的平常工做。

01 架構師的工做是什麼？

01

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

可是這種說法很模糊。讓咱們來深刻看看。

架構師應該承擔的工做

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

因此架構師的工做聽起來很偉大。你可能想知道爲何我把如此之多的工做都推給了忙忙碌碌的架構師。爲了理解這一點，讓咱們來看看我剛描述的狀況與現實生活的對比。

現實

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

首先，這位不參與編程的架構師將大部分時間都花在了開會上。他還爲這些會議準備大量 PPT 和 Visio 的資料。實際上，這是「PPT 架構師」一詞的來源。除此以外，他編寫了設計文檔，將本身對軟件設計的見解寫成一本 50 頁的書，與開發人員共享。（惋惜這個前期設計已通過了批准的日子）。後來，他還審查其餘設計文檔，簽署設計選擇，並重復全部這些工做，直到他忘記了 IDE 應該是什麼樣子。

02

若是架構師不參與編程會怎麼樣？

若是看不到產品的平常開發過程，那麼人們可能會認爲一切都很順利。 時間線看起來還不錯。功能也在持續增長。咱們正在朝着咱們的目標前進。

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

除非架構師使用他們本身推薦的工具，不然就沒法真正意識到他們的選擇產生的影響。

設計沒法知足不斷變化的需求

在考慮軟件開發的時候，咱們不能假設一個靜態的世界。架構師作的提早設計並不能考慮到全部的可變因素和極端狀況。在軟件編寫工做完成以前，咱們沒法發現其中的細微差異。

總之，架構和設計決策常常須要作出改變。

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

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

開發人員備受打擊

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

其次，許多開發人員都不喜歡刻板的編程，他們但願可以創造設計並作出決策。 若是設計過於精細，那麼創造過程就會消失。

最後，當開發團隊注意到實際狀況與架構圖上的不一致時，他們會責怪計劃。並且他們會以爲架構師沒有搞明白情況。不管這是實情仍是他們的想象，編寫軟件過程當中的障礙均可以視做架構師的失職。

03 解決方案

在咱們注意一些陷阱的前提下，若是架構師參與寫代碼的工做，那麼咱們能夠得到哪些好處呢？

尊重架構師

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

所以，若是架構師參與寫代碼的工做，那麼他們就能夠告訴開發團隊他們在並肩做戰。他們瞭解實際狀況。並且若是有必要他們也願意攜手同行。

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

更好地理解設計

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

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

另外一種方法是利用原型。若是架構師將他們的一些架構設計原型化，那麼就能夠部分地看到該原型在實際生活中的運做方式，併爲團隊提供須要構建的東西。

實時設計更新

參與寫代碼工做的架構師能夠實時地評估備選方案。過分架構的解決方案須要花費太多實現的時間，架構師能夠爲團隊提供有關開源或購買庫的信息。 讓架構師與團隊在一塊兒能夠確保根據不斷變化的需求調整架構。此外，過分提早設計的工做壓力也會減小。 若是架構師每週均可以參與一點寫代碼的工做，那麼他們就能夠及時地注意到代碼偏離了願景，從而能夠及時地調整方向。此外，架構師還能夠更好地處理正在建立的技術債務。並且他們可以指導團隊什麼時候增長技術債務，什麼時候不能增長技術債務。

最終產品的架構全部權

若是架構師參與最前線的寫代碼工做，那麼他們就會擁有更多產品的主動權。能夠更好地瞭解他們的解決方案爲企業帶來的成本。若是他們可以親手實現本身的解決方案，那麼他們就會很快意識到哪些設計決策很是重要，而哪些設計決策無關緊要。

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

04 潛在問題

有關爲何架構師不該該參與寫代碼的工做，支持者們有如下幾點理由：

• 他們會忽略長期願景或更大的問題。
• 理解本來不須要了解的應用程序的細節。

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

我徹底明白。大家但願確保架構師只承擔本身的職責，即制定長期和高層決策。可是，咱們並非要求架構師花費全部時間來編寫代碼。相反，咱們只是他們花費少許時間來幫助他們設計的應用程序變成現實。

至於不配置架構師的觀點，我在別的地方看到過這樣的例子。咱們經常會遇到有的架構師很喜歡寫代碼，卻不肯意將最基本部分以外的東西交給其餘開發人員。這種架構師須要信任開發團隊來編寫代碼。隨着時間的推移，開發人員應該可以承擔愈來愈複雜的工做。

05 人人受益

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

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

做者：Sylvia Fronczak

來源：

https://mp.weixin.qq.com/s/m_0Y9_cJXNLefYThsIA19g

原文:

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