架構過度？可能，也可能不是

對多對多軟件解決方案常見的批評是其架構過度複雜，在設計、抽象、實現、部署或其他方面造成不必要的複雜性、理解困難、維護不易、多餘或錯誤。然而，過度架構的指控往往缺乏背景或支持性敘述，並可能成爲工程師推卸責任的一種方便手段。本文探討了有問題的架構的三種基本類型：不同的架構、錯誤的架構和過度架構，並對這些類型的特徵和示例提供了見解。

對多對多軟件解決方案經常聽到的批評是，它架構過度，這意味着設計、抽象、實現、部署或其他方面不必要地複雜、難以理解、無法維護、不必要或錯誤。批評往往是無中生有，沒有背景或支持性敘述；批評往往是持久的。

那麼將解決方案標記爲過度架構有什麼好處呢？

通常，這是軟件工程師的終極出獄卡，在沒有客觀分析甚至不瞭解當前實施情況的情況下，將超出預期的工作量和時間表的責任推卸給別人。不幸的是，高層領導通常會以同情的“啊，架構過度，我很抱歉”的聳肩來盲目接受解釋，當最初的工程師無法填補需求、決策、實施等方面的空白時，這種方法尤其有效。  

是的，最初實施的架構可能與您首選的架構（技術堆棧、業務假設、抽象等）正交，但您是否可以毫不含糊地說它是過度架構？自最初實施以來，貴公司的業務目標或技術方向是否發生了變化？需要考慮哪些非功能性需求？提交消息中有什麼有趣的內容嗎？

最重要的是，您擔心的是架構過度還是發生了一些不那麼危險的事情？嗯，我不確定！

軟件工程師 軟件工程師

如果你更喜歡維護現有代碼而不是編寫新代碼，請舉手。如果你喜歡維護別人的代碼，請舉手。啊，我想是的。

當被分配維護工作時——無論以何種形式——工程師都會尋找允許他們修改、重組、重寫並總體上使工作更有趣的角度。如果責任表明過度變動、循環複雜度過高或代碼確實變得無法維護，那麼這是一個正確的決定。誠然，產品所有者和Scrum 主管不會高興，但在某種程度上，過去的罪孽再也不能被忽視了。  

公開稱現有代碼架構過度，你可能會如願以償。然而，偶爾有人會要求更深入的解釋，這讓人懷疑其原因，因爲工程師：

• 不理解當前的實現，也不願意努力去學習

• 不瞭解業務或技術要求或其他基本假設

• 不同意使用的設計模式或代碼結構

• 不喜歡代碼風格或格式，甚至不喜歡編程語言本身

而且，毫不奇怪，重寫比預想的要大，因爲具有諷刺意味的是，他/她必須最終理解現有的解決方案才能重新實現它：儘管你聲稱自己沒有鋪平道路，但不可避免地你可能需要這樣做，而這在沒有全面理解的情況下是不會顯而易見的。您的組織真的準備好採用API First、微服務、NoSQL 或簡歷中添加的其他任何東西了嗎？

工期越來越長，領導層越來越沮喪，其他重要工作被推遲和延期，這一切都是因爲工程師堅持認爲這是必要的。我們都見過這種情況，我們中的許多人都是始作俑者，而且這通常不是一個美好的故事。

但問題依然存在：它的架構是否真的過度了？

有問題的架構

軟件工程學科中應用的架構有多種標籤：例如，企業、系統、應用程序、軟件、雲和集成。更令人困惑的是，組織經常根據其內部需求定義架構學科，這使得很難明確定義每個學科的職責和界限。這絕對不是一個一刀切的比較。

話雖如此，如果您泛泛而談，而不是試圖在架構學科內定義具體內容，那麼定義有問題的架構是可能的。我發現有三種基本類型的潛在問題架構。

1. 架構不同

架構不同的解決方案是指對解決方案中非功能性需求的解決方式存在不同看法的解決方案。針對雲的解決方案應該是雲原生的還是雲無關的？穩定性和可靠性比吞吐量和性能更重要還是更不重要？支持資源是根據成本、功能還是兩者來選擇的？

您對底層架構的任何擔憂或抱怨都必須與非功能性需求相平衡，因爲非功能性需求對於成功的解決方案至關重要。您可能不同意非功能性需求；因此，您的擔憂或抱怨可能只有在重新確定非功能性需求的優先級時纔有意義。無論您的感受如何，只要滿足非功能性需求，解決方案就是有效的。

即使您完全同意非功能性需求，不同的工程師也肯定會創建不同的解決方案：同步與異步、面向對象的繼承與組合、功能性或基於 CRUID 的 API 端點 SQL 與 NoSQL、API First 與 MVC。這是主觀的，因爲每個解決方案本質上都是正確的；只是您的方法與我的不同。

“ Hello, World !” 可以用數千種不同的方式實現，每種方式都同樣正確或錯誤，因此不同的工程師和架構師將以不同的方式處理每個問題。這是錯的嗎？不是。這是架構過度嗎？如果非功能性需求得到明確識別和實施，可能不是。但您仍然可能不同意我設計和實施的內容。

2. 架構錯誤

識別架構不當的解決方案通常需要從構思到部署對有缺陷的實施進行解構：需求定義不明確或不明確、代碼質量差、項目執行不力、時間表不切實際以及架構無用。問題（以及責任）通常是多方面的。

拋開這些複雜性不談，錯誤架構的解決方案具有以下共同特徵：

• 即使已經確定了非功能性需求，也不會予以解決。

• 組織內部不具備成功實施所需的技術技能和背景。

• 該架構需要在組織核心競爭力之外構建組件，尤其是在存在現有組件的情況下。

• 部署的解決方案不穩定，需要定期關注以避免中斷。

• 維護和擴展依賴於被認爲不可替代的個人。

如果您曾經參與過火車失事項目，您可能會認出其中之一。您還可能意識到，您認爲架構錯誤的實際上是沒有架構的。最重要的是，這些項目及其產生的解決方案通常無法挽救，與之相關的一切都是浪費時間。

3. 架構過度

是否有任何解決方案是過度架構的？很可能。這個電燈開關是不是有點過頭了？對於我們大多數人來說，也許如此，但這個世界上的魯布·戈爾伯格 (Rube Golberg)和創客們可不這麼認爲。

以下經驗可能代表了過度架構；也可能只是錯誤架構，絕對是不同的架構。

問題陳述

在我擔任獨立軟件顧問期間，我曾被聘爲一位剛離職員工的補充人員。這位前員工爲公司構建了第一個真正的 Web 應用程序，並設計、實施了一個自定義框架（大部分工作都由他完成）：他/她留下了示例實施和少量（沒有？）文檔（設計、使用等），剩下的員工不得不嘗試收拾殘局。 

[對於閱讀本文的千禧一代，請記住，早期的 Web 開發沒有真正的標準或最佳實踐，開源還處於起步階段，當時還是蠻荒的西部，每個人都在尋找答案。性能不足的用戶計算機難以應付簡單的瀏覽器端腳本（DOM之前），每個瀏覽器供應商的瀏覽器都自由地解釋 HTML 標準。那時Internet Explorer開始其恐怖統治（但不知何故至今仍然存在）。與今天完全不同。]

我的任務：擁有框架，瞭解它的祕密，並定義開發應用程序的路線圖。

理解並內化

從 100K 英尺/30.5K 米的高度來看，概念上很簡單：服務器端生成要創建的 HTML，由處理請求、響應、導航等的 Java Servlet 應用程序（框架）進行編排。在 50K 英尺/15K 米的高度，事情就沒那麼簡單了。在 25K 英尺/7600 米的高度，事情就變得非常可怕了。

我越深入研究，擔憂就越強烈。頁面緊密耦合，看似微小的變化會迅速影響到相鄰頁面。頁面直接生成 HTML，很難確保整個應用程序的一致性。更改默認框架行爲依賴於找到相應的鉤子，而這些鉤子通常數量衆多且令人困惑。編排在原始 servlet 引擎（Sun Java Web Server）中有效，但如果更改則無效（開始關注Tomcat 的性能）。本地開發需要定期同步其他工程師的代碼，而當時的版本控制（CVS、Subversion、Visual Source Safe等）使同步變得困難。

我已經忘記了其他恐怖事件的擔憂，但障礙令人望而生畏，成功的機會渺茫。必須做出艱難的決定。

決策時間

我的結論是：該框架僅適合用途（勉強），但不適合開發；任何繼續的嘗試都會讓剩下的工程師不知所措，而且很可能永遠無法完成。

值得讚揚的是，經理同意了，並決定減少損失。長話短說：我們設計了一個更簡單、更專注的框架，在三週內，工程師們就可以開始在工作模型上開發應用程序，並在兩個月後成功演示了我們的進展。最終，我們非常成功，並在退役前用於多個應用程序。

判決結果

認爲原始框架架構過度的原因有：

• 缺少非功能性需求：沒有護欄來控制設計和實施

• 自我驅動設計：嘗試通過包含除廚房水槽之外的所有東西來展示你有多聰明

• 過於複雜：難以實施、維護和支持

• 缺乏差異化：架構功能並不是競爭差異化因素，並且會大大延長產品上市時間

您可能會說架構不當，或者架構不同，但這只是語義問題。無論如何，我們在改變策略之前做了應盡的調查，客觀地解釋了這一點，而不是僅僅說架構過度。

最後的想法

軟件解決方案的架構千差萬別，取決於許多外部因素：業務與軟件商店、技術人員的經驗和技能、可用技術、組織成熟度等等。這是意料之中的。

很多時候，人們在不瞭解工作背景的情況下就很快放棄了一項實施。正當理由可能證明部分或全部重新實施是合理的，但也可能是爲了工程師的私利。作爲負責任的軟件工程師，我們應該證明工作努力最有利於組織，而不是爲了軟件而軟件。這並不意味着除了功能和技術之外什麼都不該被詛咒，而是意味着我們應該能夠證明所提出的技術工作是合理的。調查、記錄、敘述、證明。

以上就是架構過度？可能，也可能不是的詳細內容，更多請關注本站其它相關文章！