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