第24章 約束

作為軟件開發者，我們創建的每一件東西都存在于現實世界中，而現實世界就有約束。像質量屬性一樣，約束可以驅動、塑造和影響軟件系統的架構。任職的組織或是工作的環境，都會將約束強加于你。約束的形態和大小不盡相同。

時間和預算的約束

時間和預算可能是大多數軟件開發者都熟悉的約束，因為這兩者常常都不夠。

技術約束

構建軟件的時候，我們經常碰到一些技術相關的約束，特別是在大型組織里。

? 批準的技術清單：許多大型組織都有一個允許用于構建軟件系統的技術清單，目的是限制組織必須支持，運行，維護和購買許可證的技術。如果你想使用任何不在清單上的技術，通常有一個漫長的例外流程，需要提出正式的申請。然而，我仍看到有團隊為了能在Java項目中使用Groovy或者Scala而偷偷引入額外的JAR文件！

? 現有系統的互操作性：在大多數組織中，你的軟件需要整合已有的系統，而實現整合的手段往往非常有限。除此之外，就是別的系統需要和你構建的系統整合。在這些情況下，你可能會發現，組織性的約束規定了你可以用于整合的協議和技術。一些我合作過的投資銀行就有他們自己內部用來在軟件系統間交換交易信息的XML結構。我可不會用“簡潔”和“易用”來描述它們！

? 目標部署平臺：構建一個全新的軟件系統時，目標部署平臺通常是影響技術決策的主要因素之一。這包括嵌入式設備、微軟的Windows或Linux服務器的可用性，以及云。是的，即使這個我們稱為云的神奇的東西，也有約束。舉個例子，每個“平臺即服務”（PaaS）提供的都不同，對某些東西，比如本地磁盤操作，你的軟件能做什么，不能做什么，大多數都有限制。如果你不明白這些約束，部署時，陪伴你的很可能是焦慮的返工。

? 技術成熟度：有些組織樂于采用有風險的尖端技術，擁抱這種進步帶來的風險。其他組織本質上則保守得多。

? 開放源代碼：同樣的，有些組織仍然不喜歡使用開源項目，除非它跟IBM或微軟這樣的名字扯上關系。我曾經在一個高街銀行的項目中工作，該銀行拒絕使用開源項目，卻樂于使用來自一個非常著名的技術品牌的Web服務器。那是偽裝過的開源Apache Web服務器。這樣的組織在遇到問題的時候就喜歡沖人大喊大叫。開源許可證的混亂也阻礙了一些組織完全采用開源項目。如果你曾試圖解釋GPL和LGPL的區別，可能已經目睹過這種情況。

? 供應商“關系”：就像生活中的很多事情，不是你知道什么，而是你認識誰。很多合作關系仍然是供應商請CTO（Chief Technology Officer，首席技術官）吃喝玩樂，在高爾夫球場上“達成”的。如果你曾為大型組織工作，也好奇為什么你的團隊被迫使用一些明顯不合格的東西，原因可能就是這個！

? 過去的失敗：2000年前后，我帶著用Java RMI——一種允許通過Java虛擬機進行遠程方法調用的技術——構建解決方案的提案走進一家銀行。我遇到了很大的阻力，因為這家銀行已經“嘗試過它，不管用”。那個設計到此為止，任何討論都沒能改變他們的主意。由于過去的失敗，Java RMI在這樣的環境下被封殺。最終我們轉而構建了一個框架，通過HTTP將序列化的Java對象傳給一群Java Servlets（變相重新發明輪子）。

? 內部知識產權：當你需要找到一個庫或框架來解決所面臨的問題，很可能已經有符合你需要的開源或商業產品。然而對有些人來說這還不夠好，你必須使用組織自己內部的日志庫、持久化框架或通信基礎設施服務。這種情況并不罕見，不管它們是否真能正常工作。最近我聽說一個組織構建了自己的CORBA實現。

人員約束

更常見的是，開發軟件可用的技術和方法受限于你周圍的人。比如下面這些。

? 你的開發團隊有多大？

? 他們有什么技能？

? 如果你的開發團隊需要擴展的話，能有多快？

? 如果需要的話，你能夠提供培訓、咨詢和專家嗎？

? 如果在交付后轉交你的軟件，接手的維護團隊擁有和你的開發團隊相同的技能嗎？

如果你讓一個Java團隊構建一個微軟.NET解決方案，相當于給他們當頭一棒。因此，當你架構一個軟件系統時，也要把人考慮進來。

組織約束

你要知道，有時候還有其他約束，包括下面這兩個。

? 軟件系統是戰術或戰略實施的一部分嗎？這個問題的答案會影響約束的增減。

? 組織政治有時能阻礙你實現真正想要的解決方案。

約束都是不好的嗎

被強加的約束通常是“壞”的，但往往是出于好的理由。比如，大型組織不愿意支持和維護天底下所有技術，就試圖限制最終用于生產的技術。一方面，這會降低創造力；但另一方面，它也剔除了你可能面對的大量潛在選項。軟件架構也事關引入約束，在一個代碼庫里面你到底想要多少個日志庫或持久化庫？

約束可以劃分優先級

最后一點，值得記住的是，約束可以劃分優先級。就像功能需求，有些約束比其他的更重要，利用好這一點。我在培訓中用作案例學習的金融風險系統就是基于我為倫敦的一個咨詢公司工作期間的真實項目。一個投資銀行找到我們，說他們需要一個金融風險系統，背后的基本前提是，由于監管原因，銀行需要有一個風險系統才能進入一個新的細分市場。

經過幾次售前會議和專題研討，對于他們的需求以及在工作中需要面對的約束，我們有了一個比較好的想法。主要的約束之一是包括典型的重量級Java EE棧在內的批準的技術清單，另一個是嚴格的時間約束。

在準備財務提案時，我們大致說了這樣的話，“是的，我們有信心在最后期限前交付系統，但為了加快項目，我們要使用一些不在你們的批準技術清單上的技術”。我們的提案被接受了。在這種情況下，時間約束被看作比只使用批準技術清單上的技術重要得多，實際上，我們會劃分約束的優先級。約束通常是你需要繞過的障礙，但有時候也能相互權衡。

傾聽約束

每一個軟件系統都要屈從于一個或多個約束，軟件架構角色的一部分就是找出這些約束，搞清楚它們為什么會被強加進來，讓它們幫助你塑造軟件架構。做不好這件事，搞不好會出大事。