軟體架構設計時容易忽略的幾個重要問題

在軟體開發中，我們對於軟體架構經常看到極端，要麼不重視軟體架構，要麼過分重視以至於她成了“天條”。我甚至遇到了這樣的事情，某公司強制推行某基於Struts的架構設計，然而到了項目組它卻處處遭到抵制，特別是分部基本上拋棄了這個架構設計。那麼，這個原因在哪裡呢？為什麼一個成本高昂的架構設計沒有被接納呢？

　　實際上有時候一個良好的設計也未必會被接納，特別是沒有Java開發實際經驗甚至缺乏軟體開發經驗的專案經理試圖控制技術的時候更加如此。我們拋開這個可能的影響來看待這個問題。

　　我們發現，很多的設計人員在做軟體架構設計的時候忽略了幾個重要的問題：

　　1.軟體的架構在大的方向上是固定的

　　這種固定依據某些基本固定的軟體模式（包括設計模式、編碼模式或者某些特定的約定）來強化和固定。這使得軟體開發在某種程度上具有某些可以明顯看得到的風格，這個風格被整個的項目貫穿和堅持，這樣當我們進入通常可怕的維護或者調整的時候，我們不會害怕我們在很多種不同的實現中常常迷失了方向。

　　2.軟體的架構在具體的應用中可以適度的可控靈活

　　毫無疑問，軟體設計開發不可能沒有例外，在某種程度上保留一些適度的靈活時必要的。一方面，它符合軟體開發的實際；一方面，適度的可控靈活體現了一種對實現者的尊重和信任。然而，如何?可控的靈活呢？通常，我認為可以考慮有限種類的設計選擇並通過有色彩的圖形來表明這種可選擇性。但即便如此，設計者很重要的要考慮這些不同選擇之間的關係，以及這些選擇和整體設計的相容性，這個時候，面向介面的設計和適度的“粘合”設計是必要的。

　　3.架構設計的支撐

　　架構設計通常會涉及到一些支撐設計，這些設計和實現水準直接的體現了系統的最有價值的部分，更細的劃分我們應該可以看到效能和結構相關的部分，以及必要的基礎類。通常，作為設計人員，我們應該能夠設計並實現系統的效能、結構、擴充、粘合等部分的工作，這部分的工作通常不應該離開設計人員的控制和把握，這些代碼的書寫或者至少積極的關注是設計人員必要的素質.我們不應該讓更多的看到我們無法寫出代碼來（我也反對沒有分工什麼都做的設計人員！），實際上，這是軟體最困難也是最有樂趣的地方。特別是在測試結果中發現這些設計實現帶來的效能的極大提高的時候是非常有成就感的事情。至於基礎類，應該是儘可能的減少依賴和耦合的。架構設計的支撐要儘可能的對客戶程式員隱藏不必要的中間細節，對基礎類要盡量簡單、穩定並真正需要。

　　通常，新興的技術會用在架構設計的支撐設計裡面並被封裝以隱藏具體的實現，而通盤應用新興技術的風險是巨大的，並且對人員的獲得也是問題。有些技術是可以提供替代技術的，一些新興的技術實現也是可以參考的（但未必採用她的實現）。要記住軟體開發是需要速度、品質、可維護而不是技術表演，這個度應該由分析設計人員負責任的來把握。

　　4.面向業務還是面向頁面的

　　也許這種說法會招致一些人的反對，認為自然而然的應該是前者，然而，實際的情況是，我們常常看到打著業務的幌子實現為面向頁面的系統，原因很簡單.後者更加的“簡單”並似乎有更少的代碼和工作量。這在某種程度上是對的。然而，區分這兩種不同的設計是必要的，儘管你也可能使用了MVC2的架構，但你可以做出面向頁面的設計的。觀察我們的軟體開發，最先提交的代碼未必是最少的代價的代碼.我們常常可以發現一些項目總是在那些不起眼的地方不斷的“修改”，我們的程式員因此好像很忙，但對我們的項目對公司來說這是糟糕的不必要開銷。因此，考慮這兩種可能的情況，在做出選擇之前加以思考是必要的。

　　5.用團隊和別人的眼光考慮問題

　　實際上，每個項目都是有所差異的，特別是人的差異。很糟糕的是，我們通常不得不面對人力資源的極大壓力，特別是這些人之間常常都沒有共事的經驗也就是常常是臨時組成的，而這些人員也通常也缺乏一個軟體開發的基本共識.對標準的遵從哪怕是最簡單的Java編碼規範和對自己提交的產品的簡單備忘和測試都是缺乏的而通常又沒有達到代碼就是文檔的水準。在這個時候，用團隊和別人的眼光考慮問題就是必要的，這實際上就是取技術上的“交集”，也就是走簡單的路線。如果沒有選擇的時候，培訓工作就是非常必要的。

　　用團隊和別人的眼光考慮問題也會有其它的問題，特別是當項目壓力如進度壓力等來臨的時候或者項目成員根本不考慮公司整體和長期利益的時候，這個問題很突出，有時候作為分析設計人員你甚至很難解決，特別是你面臨剛才我所提到的“沒有Java開發實際經驗甚至缺乏軟體開發經驗的專案經理試圖控制技術的時候”更加如此。

　　軟體架構的設計說起來簡單，也可以說起來複雜，然而，如何把事情做到簡單並且把其中的針對效能、分層、粘合、擴充等處理好，並提供可控的靈活性不是容易的。通常，只有多一些經驗和教訓並能夠在軟體代碼上加以實現核心的才可能成為好的分析設計人員。