資訊專欄INFORMATION COLUMN
摘要：畢竟，架構師不參與寫代碼的工作。例如，通常架構師需要針對可能發生的每種情況進行規劃。這種架構師需要信任開發團隊來編寫代碼。
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_...
原文:
https://dzone.com/articles/sh...
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/100114.html
摘要：自動填補分號的規則在說要不要寫分號之前，先了解一下自動填補分號的規則。后來看到知乎上的作者尤雨溪和前端大神賀師俊的回答后，我對寫分號的想法完全顛覆了。總是寫分號并不能完全解決缺陷如后換行會自動插入分號。 在打算寫這篇文章之前，我是一個分號黨，在寫這篇文章之后，可能會轉為無分號黨了。之前是寫分號是編輯器語法較檢所養成的強迫癥，現在觀念的轉變，是因為看了不少大神的討論后，覺得javascr...
摘要：命令模式的由來，其實是回調函數的一個面向對象的替代品，命令模式早已融入到了語言之中。 模式是對某情景下，針對某種問題的某種解決方案。而一個設計模式是用來解決一個經常出現的設計問題的經驗方法。這么說來，每個模式都可能有著自己的意圖，應用場景，使用方法和使用后果。本文的行文思路和目的皆在于了解各個模式的定義，應用場景和用實例說明如何在前端開發中使用。 本文所設計到的概念和實例大多來自《H...
摘要：從根本上講，架構師是一個技術領導者的角色，這就是最大的區別。對于這個問題來說，沒錯，有一些相關主題沒有出現在這本書中，這些主題可以構成一本與程序員必讀之軟件架構相互補的書。我從軟件架構的視角特別能注意到這件事。 非商業轉載請注明作譯者、出處，并保留本文的原始鏈接：http://www.ituring.com.cn/article/178034 Simon Brown 是全球知...
摘要：移動精英開發社群的第期，也是圍繞架構這個話題進行討論。本次我們希望結合實際開發中遇到的問題，來聊聊移動端的架構設計。這樣的模式改進一些，可能會更適合移動端架構。潘衛杰之前我們公司移動端的大項目就是插座式開發的，批量出各個行業的。 此前，58 同城的技術委員會執行主席沈劍在 OneAPM 的技術公開課上分享過一個主題，「好的架構不是設計出來的，而是演技出來的」。因為對很多創業公司而言，隨...
摘要：年月日，第屆技術管理工作坊將在深圳華僑城洲際酒店舉行。壹佰案例在開始前采訪了沈劍老師，先行劇透架構師轉型做管理的感悟。 showImg(https://segmentfault.com/img/bVxMfU);2016年6月25-26日，第27屆MPD技術管理工作坊將在深圳華僑城洲際酒店舉行。本次工作坊，我們邀請了58到家技術總監沈劍老師，分享《技術團隊的接手、搭建與發展實踐 》， 講...
閱讀 3002·2023-04-25 21:23
閱讀 3047·2021-09-22 15:24
閱讀 872·2019-08-30 12:55
閱讀 2106·2019-08-29 18:42
閱讀 2616·2019-08-29 16:27
閱讀 955·2019-08-26 17:40
閱讀 2191·2019-08-26 13:29
閱讀 2618·2019-08-26 11:45
