Posted on 2006-04-10 10:33
锋出磨砺 阅读(227)
评论(1) 编辑 收藏
这里将不对具体的模式进行大量的描述，只是总结自己的经验，谈谈自己的浅论。
1，项目管理模式
项目管理模式使得常规的管理问题处理起来变的简单，如果这个团队是新组建的团队，
将会使开头的事情有条理的进行，管理者将只是关注异常的发生，应对那些比较难处理
的困难，不为其他事务所劳累，以使得偏离方向，使一切陷入泥潭。
我的总结是 牢牢的抓住主线，旁支末节套用模式去处理，不必去创新，好的模式已经潜
在的包含了处理风险的方法，要做的就是发现并使用它。当然，用了和用的好差别是很大
的，常规的判断和经验的积累是提高的最快方式。
2，业务模式
领域模型的概念提出很久了，虽然做了很多的领域，自己仍然没有对此进行深入的研究和
探索。业务模式更多的体现于用户权限控制，日志处理等通用模式和一些行业特有模式（
如：电信计费模式，网管报警模式，电力设备运行模式等等）。对于业务模式我的意见还是
知识库的方式，没有银弹。尽可能的收集和提取业务模式（以易懂的描述手段进行编写），以专业
的模式名以大家熟知的方式进行索引归类。方便大家查询，业务模式是帮助大家理解新的业务需求，
并不是套用和借用。
3，构架模式
用成熟的，如mvc.借助一些成熟的framework，中间件等。
因为产品的特殊性，没有成熟的模式匹配，建议大量采用层模式，使得问题处理起来简单一些。
4，设计模式
设计模式是为了设计师之间的讨论。我严格的批判以代码分析模式的学习方法，因为我们大家都是
从代码时期慢慢的转入专业的设计队伍的，所以难免看到模式的时候想到的是如何用某种代码实现
这个模式，引入大家进入了一个误区。可以尝试，不看任何模式代码的实现，先看模式，想想以前的
系统，那些场景适合某些模式的使用或者扩展。懂模式，而后用模式，然后进行设计，再去实现它。
5，代码模式（通用组件）
封装好用的组件是很困难的，将代码模式转化为组件更是难上加难。像我们这些二把刀子，可能做出
的组件还不如不做组件。所以，对于代码模式，为了便于操作和使用，我建议：
第一步：封装一些常用的工具类，如：字符串比较，日期比较等等。使得最常规的一些实现通用稳定适用。
第二步：根据具体产品功能需求，进行针对性的组件封装，功能最好单一简单。
第三步：组件群的设计，为了实现复杂功能，将简单的组件进行群化。