對(duì)多對(duì)多軟件解決方案常見的批評(píng)是其架構(gòu)過(guò)度復(fù)雜，在設(shè)計(jì)、抽象、實(shí)現(xiàn)、部署或其他方面造成不必要的復(fù)雜性、理解困難、維護(hù)不易、多余或錯(cuò)誤。然而，過(guò)度架構(gòu)的指控往往缺乏背景或支持性敘述，并可能成為工程師推卸責(zé)任的一種方便手段。本文探討了有問(wèn)題的架構(gòu)的三種基本類型：不同的架構(gòu)、錯(cuò)誤的架構(gòu)和過(guò)度架構(gòu)，并對(duì)這些類型的特征和示例提供了見解。

對(duì)多對(duì)多軟件解決方案經(jīng)常聽到的批評(píng)是，它架構(gòu)過(guò)度，這意味著設(shè)計(jì)、抽象、實(shí)現(xiàn)、部署或其他方面不必要地復(fù)雜、難以理解、無(wú)法維護(hù)、不必要或錯(cuò)誤。批評(píng)往往是無(wú)中生有，沒(méi)有背景或支持性敘述；批評(píng)往往是持久的。

那么將解決方案標(biāo)記為過(guò)度架構(gòu)有什么好處呢？

通常，這是軟件工程師的終極出獄卡，在沒(méi)有客觀分析甚至不了解當(dāng)前實(shí)施情況的情況下，將超出預(yù)期的工作量和時(shí)間表的責(zé)任推卸給別人。不幸的是，高層領(lǐng)導(dǎo)通常會(huì)以同情的“啊，架構(gòu)過(guò)度，我很抱歉”的聳肩來(lái)盲目接受解釋，當(dāng)最初的工程師無(wú)法填補(bǔ)需求、決策、實(shí)施等方面的空白時(shí)，這種方法尤其有效。  

是的，最初實(shí)施的架構(gòu)可能與您首選的架構(gòu)（技術(shù)堆棧、業(yè)務(wù)假設(shè)、抽象等）正交，但您是否可以毫不含糊地說(shuō)它是過(guò)度架構(gòu)？自最初實(shí)施以來(lái)，貴公司的業(yè)務(wù)目標(biāo)或技術(shù)方向是否發(fā)生了變化？需要考慮哪些非功能性需求？提交消息中有什么有趣的內(nèi)容嗎？

最重要的是，您擔(dān)心的是架構(gòu)過(guò)度還是發(fā)生了一些不那么危險(xiǎn)的事情？嗯，我不確定！

軟件工程師 軟件工程師

如果你更喜歡維護(hù)現(xiàn)有代碼而不是編寫新代碼，請(qǐng)舉手。如果你喜歡維護(hù)別人的代碼，請(qǐng)舉手。啊，我想是的。

當(dāng)被分配維護(hù)工作時(shí)——無(wú)論以何種形式——工程師都會(huì)尋找允許他們修改、重組、重寫并總體上使工作更有趣的角度。如果責(zé)任表明過(guò)度變動(dòng)、循環(huán)復(fù)雜度過(guò)高或代碼確實(shí)變得無(wú)法維護(hù)，那么這是一個(gè)正確的決定。誠(chéng)然，產(chǎn)品所有者和Scrum 主管不會(huì)高興，但在某種程度上，過(guò)去的罪孽再也不能被忽視了。  

公開稱現(xiàn)有代碼架構(gòu)過(guò)度，你可能會(huì)如愿以償。然而，偶爾有人會(huì)要求更深入的解釋，這讓人懷疑其原因，因?yàn)楣こ處煟?/p>

• 不理解當(dāng)前的實(shí)現(xiàn)，也不愿意努力去學(xué)習(xí)

• 不了解業(yè)務(wù)或技術(shù)要求或其他基本假設(shè)

• 不同意使用的設(shè)計(jì)模式或代碼結(jié)構(gòu)

• 不喜歡代碼風(fēng)格或格式，甚至不喜歡編程語(yǔ)言本身

而且，毫不奇怪，重寫比預(yù)想的要大，因?yàn)榫哂兄S刺意味的是，他/她必須最終理解現(xiàn)有的解決方案才能重新實(shí)現(xiàn)它：盡管你聲稱自己沒(méi)有鋪平道路，但不可避免地你可能需要這樣做，而這在沒(méi)有全面理解的情況下是不會(huì)顯而易見的。您的組織真的準(zhǔn)備好采用API First、微服務(wù)、NoSQL 或簡(jiǎn)歷中添加的其他任何東西了嗎？

工期越來(lái)越長(zhǎng)，領(lǐng)導(dǎo)層越來(lái)越沮喪，其他重要工作被推遲和延期，這一切都是因?yàn)楣こ處焾?jiān)持認(rèn)為這是必要的。我們都見過(guò)這種情況，我們中的許多人都是始作俑者，而且這通常不是一個(gè)美好的故事。

但問(wèn)題依然存在：它的架構(gòu)是否真的過(guò)度了？

有問(wèn)題的架構(gòu)

軟件工程學(xué)科中應(yīng)用的架構(gòu)有多種標(biāo)簽：例如，企業(yè)、系統(tǒng)、應(yīng)用程序、軟件、云和集成。更令人困惑的是，組織經(jīng)常根據(jù)其內(nèi)部需求定義架構(gòu)學(xué)科，這使得很難明確定義每個(gè)學(xué)科的職責(zé)和界限。這絕對(duì)不是一個(gè)一刀切的比較。

話雖如此，如果您泛泛而談，而不是試圖在架構(gòu)學(xué)科內(nèi)定義具體內(nèi)容，那么定義有問(wèn)題的架構(gòu)是可能的。我發(fā)現(xiàn)有三種基本類型的潛在問(wèn)題架構(gòu)。

1. 架構(gòu)不同

架構(gòu)不同的解決方案是指對(duì)解決方案中非功能性需求的解決方式存在不同看法的解決方案。針對(duì)云的解決方案應(yīng)該是云原生的還是云無(wú)關(guān)的？穩(wěn)定性和可靠性比吞吐量和性能更重要還是更不重要？支持資源是根據(jù)成本、功能還是兩者來(lái)選擇的？

您對(duì)底層架構(gòu)的任何擔(dān)憂或抱怨都必須與非功能性需求相平衡，因?yàn)榉枪δ苄孕枨髮?duì)于成功的解決方案至關(guān)重要。您可能不同意非功能性需求；因此，您的擔(dān)憂或抱怨可能只有在重新確定非功能性需求的優(yōu)先級(jí)時(shí)才有意義。無(wú)論您的感受如何，只要滿足非功能性需求，解決方案就是有效的。

即使您完全同意非功能性需求，不同的工程師也肯定會(huì)創(chuàng)建不同的解決方案：同步與異步、面向?qū)ο蟮睦^承與組合、功能性或基于 CRUID 的 API 端點(diǎn) SQL 與 NoSQL、API First 與 MVC。這是主觀的，因?yàn)槊總€(gè)解決方案本質(zhì)上都是正確的；只是您的方法與我的不同。

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

2. 架構(gòu)錯(cuò)誤

識(shí)別架構(gòu)不當(dāng)?shù)慕鉀Q方案通常需要從構(gòu)思到部署對(duì)有缺陷的實(shí)施進(jìn)行解構(gòu)：需求定義不明確或不明確、代碼質(zhì)量差、項(xiàng)目執(zhí)行不力、時(shí)間表不切實(shí)際以及架構(gòu)無(wú)用。問(wèn)題（以及責(zé)任）通常是多方面的。

拋開這些復(fù)雜性不談，錯(cuò)誤架構(gòu)的解決方案具有以下共同特征：

• 即使已經(jīng)確定了非功能性需求，也不會(huì)予以解決。

• 組織內(nèi)部不具備成功實(shí)施所需的技術(shù)技能和背景。

• 該架構(gòu)需要在組織核心競(jìng)爭(zhēng)力之外構(gòu)建組件，尤其是在存在現(xiàn)有組件的情況下。

• 部署的解決方案不穩(wěn)定，需要定期關(guān)注以避免中斷。

• 維護(hù)和擴(kuò)展依賴于被認(rèn)為不可替代的個(gè)人。

如果您曾經(jīng)參與過(guò)火車失事項(xiàng)目，您可能會(huì)認(rèn)出其中之一。您還可能意識(shí)到，您認(rèn)為架構(gòu)錯(cuò)誤的實(shí)際上是沒(méi)有架構(gòu)的。最重要的是，這些項(xiàng)目及其產(chǎn)生的解決方案通常無(wú)法挽救，與之相關(guān)的一切都是浪費(fèi)時(shí)間。

3. 架構(gòu)過(guò)度

是否有任何解決方案是過(guò)度架構(gòu)的？很可能。這個(gè)電燈開關(guān)是不是有點(diǎn)過(guò)頭了？對(duì)于我們大多數(shù)人來(lái)說(shuō)，也許如此，但這個(gè)世界上的魯布·戈?duì)柌?(Rube Golberg)和創(chuàng)客們可不這么認(rèn)為。

以下經(jīng)驗(yàn)可能代表了過(guò)度架構(gòu)；也可能只是錯(cuò)誤架構(gòu)，絕對(duì)是不同的架構(gòu)。

問(wèn)題陳述

在我擔(dān)任獨(dú)立軟件顧問(wèn)期間，我曾被聘為一位剛離職員工的補(bǔ)充人員。這位前員工為公司構(gòu)建了第一個(gè)真正的 Web 應(yīng)用程序，并設(shè)計(jì)、實(shí)施了一個(gè)自定義框架（大部分工作都由他完成）：他/她留下了示例實(shí)施和少量（沒(méi)有？）文檔（設(shè)計(jì)、使用等），剩下的員工不得不嘗試收拾殘局。 

[對(duì)于閱讀本文的千禧一代，請(qǐng)記住，早期的 Web 開發(fā)沒(méi)有真正的標(biāo)準(zhǔn)或最佳實(shí)踐，開源還處于起步階段，當(dāng)時(shí)還是蠻荒的西部，每個(gè)人都在尋找答案。性能不足的用戶計(jì)算機(jī)難以應(yīng)付簡(jiǎn)單的瀏覽器端腳本（DOM之前），每個(gè)瀏覽器供應(yīng)商的瀏覽器都自由地解釋 HTML 標(biāo)準(zhǔn)。那時(shí)Internet Explorer開始其恐怖統(tǒng)治（但不知何故至今仍然存在）。與今天完全不同。]

我的任務(wù)：擁有框架，了解它的秘密，并定義開發(fā)應(yīng)用程序的路線圖。

理解并內(nèi)化

從 100K 英尺/30.5K 米的高度來(lái)看，概念上很簡(jiǎn)單：服務(wù)器端生成要?jiǎng)?chuàng)建的 HTML，由處理請(qǐng)求、響應(yīng)、導(dǎo)航等的 Java Servlet 應(yīng)用程序（框架）進(jìn)行編排。在 50K 英尺/15K 米的高度，事情就沒(méi)那么簡(jiǎn)單了。在 25K 英尺/7600 米的高度，事情就變得非?？膳铝恕?/p>

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

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

決策時(shí)間

我的結(jié)論是：該框架僅適合用途（勉強(qiáng)），但不適合開發(fā)；任何繼續(xù)的嘗試都會(huì)讓剩下的工程師不知所措，而且很可能永遠(yuǎn)無(wú)法完成。

值得贊揚(yáng)的是，經(jīng)理同意了，并決定減少損失。長(zhǎng)話短說(shuō)：我們?cè)O(shè)計(jì)了一個(gè)更簡(jiǎn)單、更專注的框架，在三周內(nèi)，工程師們就可以開始在工作模型上開發(fā)應(yīng)用程序，并在兩個(gè)月后成功演示了我們的進(jìn)展。最終，我們非常成功，并在退役前用于多個(gè)應(yīng)用程序。

判決結(jié)果

認(rèn)為原始框架架構(gòu)過(guò)度的原因有：

• 缺少非功能性需求：沒(méi)有護(hù)欄來(lái)控制設(shè)計(jì)和實(shí)施

• 自我驅(qū)動(dòng)設(shè)計(jì)：嘗試通過(guò)包含除廚房水槽之外的所有東西來(lái)展示你有多聰明

• 過(guò)于復(fù)雜：難以實(shí)施、維護(hù)和支持

• 缺乏差異化：架構(gòu)功能并不是競(jìng)爭(zhēng)差異化因素，并且會(huì)大大延長(zhǎng)產(chǎn)品上市時(shí)間

您可能會(huì)說(shuō)架構(gòu)不當(dāng)，或者架構(gòu)不同，但這只是語(yǔ)義問(wèn)題。無(wú)論如何，我們?cè)诟淖儾呗灾白隽藨?yīng)盡的調(diào)查，客觀地解釋了這一點(diǎn)，而不是僅僅說(shuō)架構(gòu)過(guò)度。

最后的想法

軟件解決方案的架構(gòu)千差萬(wàn)別，取決于許多外部因素：業(yè)務(wù)與軟件商店、技術(shù)人員的經(jīng)驗(yàn)和技能、可用技術(shù)、組織成熟度等等。這是意料之中的。

很多時(shí)候，人們?cè)诓涣私夤ぷ鞅尘暗那闆r下就很快放棄了一項(xiàng)實(shí)施。正當(dāng)理由可能證明部分或全部重新實(shí)施是合理的，但也可能是為了工程師的私利。作為負(fù)責(zé)任的軟件工程師，我們應(yīng)該證明工作努力最有利于組織，而不是為了軟件而軟件。這并不意味著除了功能和技術(shù)之外什么都不該被詛咒，而是意味著我們應(yīng)該能夠證明所提出的技術(shù)工作是合理的。調(diào)查、記錄、敘述、證明。

路由網(wǎng)(www.lu-you.com)您可以查閱其它相關(guān)文章！