Posted on 2006-04-10 10:33
鋒出磨礪 閱讀(233)
評論(1) 編輯 收藏
這里將不對具體的模式進行大量的描述，只是總結自己的經驗，談談自己的淺論。
1，項目管理模式
??? 項目管理模式使得常規(guī)的管理問題處理起來變的簡單，如果這個團隊是新組建的團隊，
將會使開頭的事情有條理的進行，管理者將只是關注異常的發(fā)生，應對那些比較難處理
的困難，不為其他事務所勞累，以使得偏離方向，使一切陷入泥潭。
??? 我的總結是 牢牢的抓住主線，旁支末節(jié)套用模式去處理，不必去創(chuàng)新，好的模式已經潛
??? 在的包含了處理風險的方法，要做的就是發(fā)現(xiàn)并使用它。當然，用了和用的好差別是很大
??? 的，常規(guī)的判斷和經驗的積累是提高的最快方式。
2，業(yè)務模式
??? 領域模型的概念提出很久了，雖然做了很多的領域，自己仍然沒有對此進行深入的研究和
??? 探索。業(yè)務模式更多的體現(xiàn)于用戶權限控制，日志處理等通用模式和一些行業(yè)特有模式（
??? 如：電信計費模式，網管報警模式，電力設備運行模式等等）。對于業(yè)務模式我的意見還是
??? 知識庫的方式，沒有銀彈。盡可能的收集和提取業(yè)務模式（以易懂的描述手段進行編寫），以專業(yè)
??? 的模式名以大家熟知的方式進行索引歸類。方便大家查詢，業(yè)務模式是幫助大家理解新的業(yè)務需求，
??? 并不是套用和借用。
3，構架模式
??? 用成熟的，如mvc.借助一些成熟的framework，中間件等。
??? 因為產品的特殊性，沒有成熟的模式匹配，建議大量采用層模式，使得問題處理起來簡單一些。
4，設計模式
??? 設計模式是為了設計師之間的討論。我嚴格的批判以代碼分析模式的學習方法，因為我們大家都是
??? 從代碼時期慢慢的轉入專業(yè)的設計隊伍的，所以難免看到模式的時候想到的是如何用某種代碼實現(xiàn)
??? 這個模式，引入大家進入了一個誤區(qū)。可以嘗試，不看任何模式代碼的實現(xiàn)，先看模式，想想以前的
??? 系統(tǒng)，那些場景適合某些模式的使用或者擴展。懂模式，而后用模式，然后進行設計，再去實現(xiàn)它。
5，代碼模式（通用組件）
??? 封裝好用的組件是很困難的，將代碼模式轉化為組件更是難上加難。像我們這些二把刀子，可能做出
??? 的組件還不如不做組件。所以，對于代碼模式，為了便于操作和使用，我建議：
??? 第一步：封裝一些常用的工具類，如：字符串比較，日期比較等等。使得最常規(guī)的一些實現(xiàn)通用穩(wěn)定適用。
??? 第二步：根據具體產品功能需求，進行針對性的組件封裝，功能最好單一簡單。
??? 第三步：組件群的設計，為了實現(xiàn)復雜功能，將簡單的組件進行群化。