摘要：畢竟，架構(gòu)師不參與寫代碼的工作。例如，通常架構(gòu)師需要針對可能發(fā)生的每種情況進行規(guī)劃。這種架構(gòu)師需要信任開發(fā)團隊來編寫代碼。

Talk is cheap, show me the code！
但是在互聯(lián)網(wǎng)企業(yè)中，身處技術(shù)要職的架構(gòu)師到底需不需要寫代碼？

在我們的專業(yè)領(lǐng)域中有一種普遍存在的誤解：架構(gòu)師的工作不需要寫代碼。

就目前看來這似乎沒什么問題。畢竟，寫代碼是開發(fā)人員的工作。架構(gòu)師就應(yīng)該在更重要的任務(wù)上忙碌。

但是，讓架構(gòu)師遠離寫代碼會限制開發(fā)團隊的潛力。當需求和業(yè)務(wù)需要發(fā)生變化時，也可能導(dǎo)致架構(gòu)混亂。

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

01
架構(gòu)師的工作是什么？

01

這是一個很常見的問題。許多開發(fā)人員、產(chǎn)品經(jīng)理、甚至連有些架構(gòu)師都不確定架構(gòu)師的工作是什么。一般的定義說他們需要做出高層決策并規(guī)定標準。

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

架構(gòu)師應(yīng)該承擔的工作

理想情況下，架構(gòu)師需要創(chuàng)建一個技術(shù)愿景，通過該愿景我們可以獲得可維護又可靠的產(chǎn)品。架構(gòu)師需要協(xié)調(diào)不同的團隊，共同構(gòu)建一個相互依存的軟件生態(tài)系統(tǒng)。此外，他們還需要分享高層的集成決策，傳達應(yīng)用程序和組件之間協(xié)同工作的方式。除此之外，他們還需要根據(jù)常見的軟件問題審查并規(guī)定工具和框架，并通過向利益相關(guān)者和領(lǐng)導(dǎo)層傳達最終產(chǎn)品的目標和愿景，將所有這些聯(lián)系在一起。

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

現(xiàn)實

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

首先，這位不參與編程的架構(gòu)師將大部分時間都花在了開會上。他還為這些會議準備大量 PPT 和 Visio 的資料。實際上，這是“PPT 架構(gòu)師”一詞的來源。除此之外，他編寫了設(shè)計文檔，將自己對軟件設(shè)計的看法寫成一本 50 頁的書，與開發(fā)人員共享。（可惜這個前期設(shè)計已經(jīng)過了批準的日子）。后來，他還審查其他設(shè)計文檔，簽署設(shè)計選擇，并重復(fù)所有這些工作，直到他忘記了 IDE 應(yīng)該是什么樣子。

02

如果架構(gòu)師不參與編程會怎么樣？

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

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

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

設(shè)計無法滿足不斷變化的需求

在考慮軟件開發(fā)的時候，我們不能假設(shè)一個靜態(tài)的世界。架構(gòu)師做的提前設(shè)計并不能考慮到所有的可變因素和極端情況。在軟件編寫工作完成之前，我們無法發(fā)現(xiàn)其中的細微差別。

總之，架構(gòu)和設(shè)計決策經(jīng)常需要做出改變。

你可能會說這不是問題。架構(gòu)師可以回去重新設(shè)計系統(tǒng)。然而，實際情況卻并非如此。開發(fā)人員注意到有些事情不太對勁。這些事情變得越來越困難。而他們可以做的有：他們可以向架構(gòu)師匯報這個問題，但是架構(gòu)師不在其中無法真正掌握情況；他們可以自行重新設(shè)計系統(tǒng)；或者他們也可以盡可能地想辦法彌補問題，然后繼續(xù)前進。

如果架構(gòu)師能夠與開發(fā)團隊近距離相處，并擔任編程的工作，那么他們就可以看到變化即將到來，并實時修改設(shè)計。他也可以預(yù)先做最小的設(shè)計，并與團隊合作，隨著時間的推移改進系統(tǒng)的架構(gòu)。

開發(fā)人員備受打擊

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

其次，許多開發(fā)人員都不喜歡刻板的編程，他們希望能夠創(chuàng)造設(shè)計并做出決策。 如果設(shè)計過于精細，那么創(chuàng)造過程就會消失。

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

03

解決方案

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

尊重架構(gòu)師

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

因此，如果架構(gòu)師參與寫代碼的工作，那么他們就可以告訴開發(fā)團隊他們在并肩作戰(zhàn)。他們了解實際情況。而且如果有必要他們也愿意攜手同行。

此外，架構(gòu)師還可以更頻繁地分享設(shè)計見解。通常，開發(fā)人員看不到架構(gòu)模式的需求，因為他們從來沒見過可以讓他們的日子更好過的模式。架構(gòu)師可以通過傳達設(shè)計中重要部分的架構(gòu)來解決這個問題?；蛘咚麄兛梢詭椭鷪F隊將代碼中的混亂部分重構(gòu)成優(yōu)雅的東西。

更好地理解設(shè)計

如果架構(gòu)師參與寫代碼的工作，那么他們就有機會向開發(fā)人員傳達更具影響力的設(shè)計思想和原則?？吹桨装迳袭嫵鰜淼倪m配器模式是一回事，而在 IDE 中親眼看到一個適配器模式是另一回事。
此外，架構(gòu)師應(yīng)該鼓勵開發(fā)人員多多思考設(shè)計。作為導(dǎo)師，你可以教導(dǎo)開發(fā)人員處理意外的變化，并找到解決問題的模式和設(shè)計。你應(yīng)該公開討論解決方案的優(yōu)缺點，提出問題和討論，并開展設(shè)計合作。

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

實時設(shè)計更新

參與寫代碼工作的架構(gòu)師可以實時地評估備選方案。過度架構(gòu)的解決方案需要花費太多實現(xiàn)的時間，架構(gòu)師可以為團隊提供有關(guān)開源或購買庫的信息。
讓架構(gòu)師與團隊在一起可以確保根據(jù)不斷變化的需求調(diào)整架構(gòu)。此外，過度提前設(shè)計的工作壓力也會減少。
如果架構(gòu)師每周都可以參與一點寫代碼的工作，那么他們就可以及時地注意到代碼偏離了愿景，從而可以及時地調(diào)整方向。此外，架構(gòu)師還可以更好地處理正在創(chuàng)建的技術(shù)債務(wù)。而且他們能夠指導(dǎo)團隊何時增加技術(shù)債務(wù)，何時不能增加技術(shù)債務(wù)。

最終產(chǎn)品的架構(gòu)所有權(quán)

如果架構(gòu)師參與最前線的寫代碼工作，那么他們就會擁有更多產(chǎn)品的主動權(quán)?？梢愿玫亓私馑麄兊慕鉀Q方案為企業(yè)帶來的成本。如果他們能夠親手實現(xiàn)自己的解決方案，那么他們就會很快意識到哪些設(shè)計決策非常重要，而哪些設(shè)計決策可有可無。
例如，通常架構(gòu)師需要針對可能發(fā)生的每種情況進行規(guī)劃。 但是在項目開始時，通常很難知道哪些問題是真實的，哪些是想象的。 或者至少哪些情況不太可能出現(xiàn)。如果最終我們只有 100 個客戶，那么就沒有必要創(chuàng)造一個冗余且規(guī)模巨大的迷宮。 我們應(yīng)該專心提供價值。

04

潛在問題

有關(guān)為什么架構(gòu)師不應(yīng)該參與寫代碼的工作，支持者們有以下幾點理由：

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

理解原本不需要了解的應(yīng)用程序的細節(jié)。

架構(gòu)師參與寫代碼的工作等于鼓勵團隊不配置架構(gòu)師。

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

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

05

人人受益

最后我認為，讓軟件架構(gòu)師參與寫代碼的工作有益于整個團隊和最終產(chǎn)品。同時也可以鼓勵分享設(shè)計理念和快速反饋，可以幫助團隊中每個人的成長。

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

作者：Sylvia Fronczak
來源：
https://mp.weixin.qq.com/s/m_...
原文:
https://dzone.com/articles/sh...