軟體架構師應避免的7種行為 - Daniel Watts

 
1.不要忽視工程團隊
如果您沒有在工程團隊中編寫或審閱過程式碼或深入進行技術討論，則可能是您與問題目標或與工程團隊不夠親密。如果您沒有感到他們的痛苦，那麼您可能缺乏同理心和理解力，無法提供有效的指導。但是一旦您發現自己已經處於這個位置，應該會考慮從一對一開始與工程師配對，這是提高同理心和理解力的最快方法。然後在必要時考慮參加需求的啟動、技術設計討論和程式碼審查。
 

2.不要忽略領域
成為領域專家是角色的一部分。這些知識可以用作在業務和工程之間進行有效的翻譯。也就是說，您也要避免成為溝通的瓶頸，因此為工程團隊教授、翻譯和記錄域上下文和業務價值非常重要。這就是價值流對映，事件風暴和域驅動設計等技術真正可以提供幫助的地方。
 

3.不要規定或要求架構
在大多數情況下，我們的行業實際已經不是這樣一個簡單概念：即系統架構是獨立設計的並交給工程師交付的。實際上軟體架構或體系結構是和開發交織在一起的活動，其中一個的反饋會影響另一個。儘可能縮短反饋迴圈可能會導致更好的結果。因此，如果您想設計和建立更具彈性的系統，而您的組織傾向於強制要求或規定體系結構；考慮如何最好地授權工程師做出合理的架構決策。與工程師合作，就架構原則達成共識，並接受從未完成的架構，隨著時間的流逝，架構應該不斷髮展和變化是一個不錯的起點（請參見有關此方面的更多內容，請參見《構建進化架構》一書。
 

4.不要僅僅尋求架構一致性
在構建和維護許多系統以幫助防止複雜性的組織中，一致性當然佔有一席之地。我認為，最好將其視為可能會有例外的準則。簡單地尋求或更糟的是，加強一致性是確保團隊步伐放緩，壓制創新並減少學習機會的肯定方法。
 

5.不要忘記當前的架構狀態
根據公認的原則並與工程師協作對目標體系結構進行建模可能會很有用（請參見上面的＃1和＃3）。但是，它必須建立在對當前體系結構的所有細微差別和理解上。
 

6.不要過於依賴所需的架構
如果您要為工程團隊提供技術指導的話。將出現新的資訊和不可預見的情況，因此任何目標狀態都將100％更改。當這些情況浮出水面時，您將需要保持開放的態度以適應您的觀點和方向。固定的檢視只會阻礙進度。如＃3所述，架構應經歷不斷的，增量的變化。 
 

7.不要讓稽核過程停滯不前
作為大型組織的架構師，您很可能負責或積極參與體系結構和安全性審查過程，無論是作為審查者還是尋求審查。這些流程通常是變更批准複審，為生產釋出開了綠燈。它們可能漫長而引人注目，其價值不明確，涉及背景為零的審稿人，並導致不必要或不必要的結果；使他們成為抵抗變化的理想人選。
作為一個更高階的人物，架構師應該為這種直覺而努力。他們應設法瞭解審查過程的目的和價值，並將其傳達給他人。他們應該領導或指導工程團隊完成這些過程，尤其是第一次。