應用開發政策選擇

每個軟體架構師，開發經理和開發人員都很可能遇到過軟體設計和開發中“自上之下vs.自下而上”的争論。

正确的答案其實是，這裡并沒有單一的最佳方案。 應用是用自上而下和自下而上的兩種方案之一來建構，每種方式的支援者和另一方的支援者一直争論不休。但是決定企業應該采取哪一種應用開發戰略要求檢視需求和資源，并且考慮到應用可能的變化，了解應用設計上這兩種不同的方案以及各自減少風險的所需步驟。

子產品化程式設計理念和企業架構都影響着軟體開發，使其從上開始，從業務需求和預期收益入手。

實際上，這意味着列出業務目标，基于映射到使用者行為的功能劃分，用通用的軟體術語來描述業務目标，然後将這些功能進一步分解，比對硬體和軟體的需求。在過去的十年裡，這已經被廣泛接受成為應用程式設計的最佳方法。

自上而下和自下而上

自上而下應用設計和開發也更容易和企業以及将使用應用的使用者相比對。大家了解軟體做什麼以及怎麼做，意味着他們從應用的功能驅動視圖來了解應用。如果從這樣的視角開始，就可以從業務部門收集方案使用性方面的需求，并且能夠洞察出業務實踐随時間的改動可能會如何影響到軟體設計。

這樣自上而下方案的問題在于，項目目标還包括使用某種特定技術或者資源集——特别是雲——的時候會遇到問題。應用不會為雲自動優化；他們必須特别設計來利用雲的特定特性，同時避免花費過多。從上開始的話，架構師可能能夠構造出一些和一開始的目标平台以及托管選項不是特别比對的東西。自下而上的方案才能夠確定托管以及資源的正确使用。

自下而上的應用開發戰略更容易契合通過面向服務架構或者微服務的使用而開發的元件庫。如果可以從已有軟體元件組裝出一個應用程式——或者其中的一大部分——那麼就可以減輕開發負擔和應用生命周期管理需求。自上而下方案在現有元件模型沒有什麼用時可以上司設計的方向。

方案之争

經驗豐富的開發團隊已經适應了自上而下vs自下而上的應用開發戰略之争，但是有兩種基礎方案得到了廣泛認可。一種着重考慮資源或者平台目标，認為這些和功能需求一樣重要，另一種更像是“在中間會和”的方案。

很容易看出，如果需要為使用現有子產品化模型而進行優化，或者為雲計算做準備，這樣的需要提升成為需求時，那麼應用程式設計需要從一開始就考慮到這些需求，并且按需作出設計。但是，不是所有開發團隊都能夠輕松在設計的最高層混合功能和技術的需求。使用雲技術如何和支援某種特定的功能行為相契合呢？如果無法回答這個問題，那麼流行的做法是設定某個需求集的優先級高于另一個需求集。這樣能夠完成擁有有限功能的設計。

當基于資源，平台或者元件重用的目标，業務需求适合某個假定的應用模型時，“提升”模型能夠工作得很好。比如，一個基本的web前端軟體模型，管理特定的系統-使用者關系，連結到一系列解決企業功能需要的應用流程上，能夠足夠好地組織開發工作，確定重用需求可見，而不犧牲任何功能性。

“在中間會和”方案假定平台群組件建立一個能夠抽象到一系列技術行為的工具包。比如，可用元件能夠組裝起來更新資料庫或者完成報告。這些高層級的行為也能夠關聯到雲特性上，比如水準擴充或者故障發生時的執行個體置換。雖然它們可能無法直接映射到新應用的功能性需求——或者它們可能對于項目而言并不需要——它們比基礎技術需求更加功能化。架構師随後就能夠基于這些行為組合出第二或者第三層設計。

基于行為，在中間會和的應用開發戰略的問題是，如何向上反應行為感覺性，而不會被底層問題占據。最佳方式是從底層開始組裝有用的行為，然後将其暴露成工具給架構師，架構師從頂層開始功能性設計。該方案在有顯式高層功能性需求時最有用，這些需求可能來自一個良好的ea模型。沒有非常強有力的功能性需求，那麼設計流程就很容易被自下而上的資源探求群組件戰略所占據。

底線

自上而下的設計很好地将應用和業務目标契合在一起，并且優化使用者體驗的品質，但是他們可能建立出不是最優的元件化，并且限制了應用程式采納新技術，比如雲計算的能力。自下而上的設計優化資源群組件化能力，但是可能會偏離使用者的體驗品質。最後，最好選擇契合你的最重要目标的方案，然後一步步確定能夠兼顧到另一端。

本文轉自d1net（轉載）