設計雜談
在設計時會碰到兩種類型的設計,一種是框架級產品的設計,一種是項目產品的設計,在面向這兩種進行設計時覺得還是非常不同的,框架級產品的設計強調一種通用性的抽象上,在這點上通常依賴開發或設計經驗來進行抽象,難度不僅在此,通??蚣芗壆a品的設計都會面對技術性的問題,也就是說在設計階段根本就是無法進行細化的一些部分,這種現象在框架級產品中通常出現,這時在進行設計時就要慎重考慮,通常按照敏捷工程的方法的話是先進行spike,spike后再進行相應的設計;對于項目產品的設計強調的是對項目需求的實現,這個時候通常需要的是業務角度的抽象,當然,這點也是具有難度的,通常來說項目產品上不會出現太多的技術難度,也不希望出現。
其實想想,覺得這兩種在設計上又是一樣的,需要的都是業務的抽象能力以及技術的實現設計能力,對于框架級產品的設計來講,業務的抽象能力即為軟件行業的業務的抽象,而技術的實現設計能力在兩者都是相同的,即當出現技術難點時都應選擇先進行spike,spike后再進行相應的設計,否則做出來的設計是沒什么意義的。
現在經手了一個東西就是先經過設計,再進行開發的,典型的瀑布方式,設計要做的非常的細,覺得這種方式挺依賴系統設計師的,也真正的感覺到一次完整做設計的過程,應該說,這個時候會發現自己的很多不足,建議系統設計師都經歷一個這樣的過程,從架構到概要到詳細,要詳細到足夠編碼的程度,覺得挺容易出現矛盾的時候,因為象框架級的產品來講最終的詳細設計可能是經過N次抽象的具體實現的設計,如果真的想讓其他的人僅憑文檔就讀懂,我覺得還是挺難的,同時由于框架級的產品通常會面臨不少的技術難點,這個時候的設計就更是不好把握,因為會有一些風險點的出現,這個時候設計做的過細就顯得不是那么得有意義,總體而言,我還是更喜歡先做初步設計,在實現過程不斷重構最終形成設計的方式,覺得那樣的過程非常的好,在這樣的過程中詳細、架構都是在不斷的被重構,設計慢慢的就會變得非常的不錯,不過這個要根據團隊而定,只有實力較強的團隊才可這么做,否則會出現無設計和不可控制的現象。
還是信奉自己的一句話:“不要求高質量的實現代碼,但要求高質量的測試代碼”,我相信一個具有優秀習慣和掌握足夠重構技巧、OO思想等的開發人員很容易就可以將不是高質量的實現代碼變魔術般的變為高質量,但依賴于高質量的測試代碼。
其實想想,覺得這兩種在設計上又是一樣的,需要的都是業務的抽象能力以及技術的實現設計能力,對于框架級產品的設計來講,業務的抽象能力即為軟件行業的業務的抽象,而技術的實現設計能力在兩者都是相同的,即當出現技術難點時都應選擇先進行spike,spike后再進行相應的設計,否則做出來的設計是沒什么意義的。
現在經手了一個東西就是先經過設計,再進行開發的,典型的瀑布方式,設計要做的非常的細,覺得這種方式挺依賴系統設計師的,也真正的感覺到一次完整做設計的過程,應該說,這個時候會發現自己的很多不足,建議系統設計師都經歷一個這樣的過程,從架構到概要到詳細,要詳細到足夠編碼的程度,覺得挺容易出現矛盾的時候,因為象框架級的產品來講最終的詳細設計可能是經過N次抽象的具體實現的設計,如果真的想讓其他的人僅憑文檔就讀懂,我覺得還是挺難的,同時由于框架級的產品通常會面臨不少的技術難點,這個時候的設計就更是不好把握,因為會有一些風險點的出現,這個時候設計做的過細就顯得不是那么得有意義,總體而言,我還是更喜歡先做初步設計,在實現過程不斷重構最終形成設計的方式,覺得那樣的過程非常的好,在這樣的過程中詳細、架構都是在不斷的被重構,設計慢慢的就會變得非常的不錯,不過這個要根據團隊而定,只有實力較強的團隊才可這么做,否則會出現無設計和不可控制的現象。
還是信奉自己的一句話:“不要求高質量的實現代碼,但要求高質量的測試代碼”,我相信一個具有優秀習慣和掌握足夠重構技巧、OO思想等的開發人員很容易就可以將不是高質量的實現代碼變魔術般的變為高質量,但依賴于高質量的測試代碼。
posted on 2006-02-20 20:11 BlueDavy 閱讀(2210) 評論(1) 編輯 收藏 所屬分類: 系統設計