設計,看上去很美 wayfarer

2021-04-02 02:40:50 字數 2866 閱讀 3683

設計沒有標準,模式充滿變化,我們對設計與模式的**,就是希望能從沒有標準的設計中體驗設計的樂趣,從充滿變化的模式中尋求問題的解決之道。

我這裡所謂「設計沒有標準」,其實並非沒有標準,現實是設計的標準實在太多了。我們都希望找到最好的設計方案,然而什麼是最好,每個人都有自己的「哈姆雷特」。滿足客戶需求的設計就是最好的,這個結論我想不會有人反對,前提是,怎樣通過設計來滿足客戶需求?

計畫的設計和演進的設計

通常來說,軟體設計不外乎兩種方式:計畫的設計和演進的設計。很多人看來,計畫的設計更符合工程學的理念。如果你要建一間茅屋,那麼你只需夯好土牆,再胡亂堆放一些茅草置於屋頂之上就可以了。然而,如果要你建一座蘇州的拙政園,就必須事先有計畫的設計了。**應該堆放假山,**應該開闢池塘,亭子的形狀,院落的分布,乃至於園內的一花一木,無不需要獨具匠心。軟體設計也是如此,且過之而無不及。接手專案的時候,首先考慮的不是編碼,而是考慮整個系統的架構,根據需求考慮系統中的重大問題。模組的功能,模組間的關係和系統分布的層次,都需要匠心獨運,從乙個抽象的層面來考慮。

演進的設計恰好與之相反,它是一種漸進的過程。它並不要求前期的設計有多麼的完美,實現的需求有多麼的完整,你只需要把現階段考慮的問題編碼實現就可以了,隨著演進的深入,編碼也會隨之而修正,最後設計會逐漸豐滿起來,經過一系列的方法,最後的設計也漸趨完美。

你也許會認為「演進的設計」如此的簡陋與平庸。沒有計畫,只會令設計一團遭。但我需要提醒你的是,雖然都是工程學,軟體的設計並沒有建築設計那麼簡單。因為,你很難在設計之初,考慮到客戶的全部需求,甚至於實現未來的擴充套件。在設計一開始,你能確信:

你對客戶的需求都理解了嗎?

你能確定客戶的需求不再變化嗎?

你設計的軟體架構真的能滿足需求嗎?

是的,你無法給出肯定的回答。總之我在這裡不是想說服每個人,要採取哪一種設計方式。事實上,我也面臨抉擇的困難。

過度設計,還是簡單設計?

kent在《解析極限程式設計——擁抱變化》中為簡單系統制定了四個評價標準,依次為(最重要的排在最前面):

通過所有測試;

體現所有意圖;

避免重複;

類或者方法數量最少;

這些標準寫出來簡單,要根據這個標準來實現,就不是那麼容易的事了。我相信,軟體設計人員都希望自己的設計盡可能簡單。然而,在設計時,我們不僅僅要考慮軟體的功能,我們還要考慮軟體的效能、擴充套件性,模組間的耦合關係,系統的穩定、部署和更新,版本的管理,系統的安全,介面的友好程度。要想簡單,何其之難!

do the ******st thing that could possibly work! 這是xp人士大聲疾呼的口號,我也舉雙手贊成。問題是,我們需要讓簡單的事情,同時又有效。很多人在設計時,並不滿足於實現眼前的功能。看到加法,他們可能還會想到乘法;雖然目前的需求是整數,他們可能想到今後可能會擴充套件到實數,甚至於複數。他們希望能利用某種設計,使其具有更好的擴充套件性。從眼前的需求來看,可能是過度設計;然後對於未來,這個設計才是最完美的方案。

問題不在於設計是否過度,關鍵還是在於設計的理念。是只做目前需要的事,還是未雨綢繆,想好今後的功能擴充套件?這個問題的答案還需要實際的專案開發來檢驗,根據不同的需求,答案會因此而異。

需要設計模式嗎?

重構是必然的!

既然我們無法給出乙個完美的設計方案,因為客戶的需求總是變化的,重構也就成為必然。問題是,這樣沒有新增任何功能的重構,你是否願意為此付出精力、時間去完成。當客戶要求的deadline將要到來的時候,你還認為你的重構工作是必要的嗎?

有時候,軟體設計常常身不由己。然而,純從技術的角度來看,重構非但必然,而且重要。既然我們都明白,複雜的未嘗就是好的,簡單的也不一定是容易的。要保持你的設計盡可能的簡單,可能你還需要時時借助重構的利器,來「改善你既有**的設計」。

對於重構,martin fowler給出了很多條款。這些條款並不是政治課本的教條,也不是「日月神教」的神奇咒語,念著它們就可以防身。這些條款確實很重要,但你需要的是學會他後,然後忘記他,就象張無忌學太極拳那樣。我不是故弄玄虛,事實上只有這樣,重構的精神才能完全融入到你的設計中。

uml重要嗎?

我現在看乙個設計方案的時候,更希望先看看uml圖,然後再看文件的實際描述。如果讓我讀一段**,我希望能先看看類圖,或許更容易理解**的含義。uml在oo世界裡像是世界語,它便於程式設計師間的交流,讓別人更容易理解你的意圖。同時,在設計uml圖的過程中,也是一種對思路的清理,對客戶需求的把握,設計思想的跟蹤。

uml是一種基於物件的統一建模語言,它能夠為系統設計提供清晰直觀的設計。在物件導向世界裡,uml的地位彌足輕重,甚至被稱為是軟體設計的一場革命。對於有計畫的設計,uml的價值就體現得淋漓盡致。如果我們要清晰地表現模組的功能,模組間的關係和系統分布的層次,使用uml可以使設計師減少很多麻煩,同時降低了語義描述的二義性。然而,如果我們在做演進的設計時,uml還有那麼重要嗎?我們只需要對眼前的需求進行編碼、測試,然後重構。可能我們只需要在pair team中討論設計方案,在預定技術框架內**實現的可能和細節。我們完全可以拋開uml繁瑣而死板的設計,畢竟最能忠實體現設計思想的,不是文件,不是用例圖或是什麼類圖,而是**。

那麼,有多少人是這樣想的?

tdd、單元測試和其他

軟體的生命是什麼,是質量!而保證質量的唯一方法,就是測試。傳統的軟體開發過程,強調首先進行需求分析,再從需求分析中抽象出概要設計,進而作出詳細設計,然後編碼,最後才是測試以驗證**的正確性。而測試驅動開發(tdd)改變了編碼的過程,開發僅僅包括三方面的活動:編寫測試用例,編碼並進行測試,重構**以消除重複**使其更簡單、更靈活、更容易理解。通過測試來驅動開發,聽起來是那麼的離經叛道,然而實施起來,又是那麼合理、正確和簡單,前提是:我們不能在一開始就獲得正確的設計!tdd避免了對不完整需求造成的不成熟的設計。通過單元測試,保證了**的正確性與高質量;通過重構,使設計更加簡單、靈活。

雲計算,看上去很美

個人的理解是雲計算執行的應該是計算密集型的任務 不過我有乙個疑問,就是雲計算是執行在分布式的計算機系統上,那麼組成這個分布式系統的計算機由誰掌控?這些計算機之間的網路連線又由誰提供?資料安全性如何得到保證?對於事關國家機要的計算任務應該在 控制的超級計算機上完成的,而不可能在乙個由公共網連線起來的私...

html5看上去很美!

why?寫下這篇博文的目的是給那些在跨平台方面 本文主要圍繞移動平台展開討論 對html5保有過多期望的公司或者創業團隊的一些個人建議,當然是個人建議,就不可能都正確,希望大家能夠剔除糟粕,看到裡面有對自己有用的地方,我的目地也就達到了。overview 談到html5,我就不得不說到faceboo...

三維GIS,看上去很美

發表於 3snews新聞周刊 第22期 三維gis 在今天已經成為了乙個炙手可熱的名詞,在稍具規模的gis會議和展覽上,都可以看到形形色色的三維gis產品,國內的 國外的 單機版的 網路版的 可瀏覽的 可分析的,一幅欣欣向榮的熱鬧景象,頗給人一種2dgis已經過時,3dgis時代業已來臨的感覺。也就...