在此对team的第一次讨论做一些概括。当然，蝈蝈的文章更加原汁原味，各位如果有时间的话可以去看看。
在下面的文章中，大部分论点属于team，不是我个人观点。
大家对设计模式的认识是怎样的
vcfly.net 设计模式就是一种思想，但思想的基础是要有一定的实践经验
wayfarer 我认为在应用设计模式上，有两种方式
从传统的软件开发出发，对体系结构设计的时候，如果熟悉设计模式，那么设计的软件在扩展性和
健壮性，都比较好
但如果从TDD的角度出发，设计模式主要还是在重构中体现
蝈蝈 其实应该是在设计模型的时候考虑模式，具体的模式有了，代码也就出来了 而不拿到模式去套代
码对吗
dudu 模式我觉得可以理解为软件设计的一个理论，学好理论很重要，但更重要的是如何运用理论，就像
懂得了孙子兵法，不一定你就能打胜仗
我觉得模式的最高境界就是你在编程中不知不觉地使用模式去解决问题
单一谈模式的意义不大，在重构中应用模式，是使用模式的一种常见手段，于是乎大家的观点自然而然就开始
发散，谈到了重构，谈到了TDD（测试驱动设计） pairwork xp
重构
dudu 我想我们使用模块是为了解决重复代码的问题，我们在编码时应该更多地考虑如何避免重复代码，
而不是采用哪种模式
Zealot 我自己的原则是如果copy code三次以上，我就会重构它
vcfly.net 一个很突出的问题是，系统的功能越来越复杂，这就需要考重用和重构
vcfly.net 我以前改过一个5000行的程序，代码我给降到了1800行，伸缩性扩展性全上去了，而且功能也多了
很多，但是执行速度却降成了50%
wayfarer 我在读fowler的重构时，就觉得他写的步骤太繁琐，但后来觉得，这种小心谨慎是值得的
idior 对啊，他是再没有测试代码得情况下做得 没有tdd，重构是很危险和麻烦的
Samuel 设计很重要，但是千万不要过度！
小陆 开始设计的时候，用最简单的方式实现。随着需求的复杂，或者发觉出更多的需求，这时候就不可
避免的重构，首先整理现有的功能，这时候可能就要应用各种复杂的模式，等到重构就绪，再添加
新的功能。
dudu 小陆，这是典型的XP思想,
蝈蝈 其实TDD也是这样的，先写测试后来代码，保证所以的代码是因为有测试才出的 也就是有需求才会
有测试代码，这样就没有过度了，所以做的都是现在最需要的
pairwork & 客户
idior 有个问题哪个公司有用pairwork
Samuel 不相信中国的公司会用pairwork
dudu 支持结对编程
umlchina 没有试过结队编程，听起来很有意思
小陆 从来没有尝试过真正的xp，试过一次结对编程，发现效果很不好，就停止了。有人有成功的经验吗
？失败的教训也行啊
wayfarer 国内的客户水平还达不到XP的要求
Samuel 非常反对wayfarer 客户永远是对的 客户不懂的 需要你去引导
vcfly.net 反对Samuel
idior 我也对国内客户没信心
Zealot 不要抱怨或期待客户的水平如何如何，客户要完成自己的需求，又不想多花钱，这是很自然的。
wayfarer 希望关于结对编程和客户交流等问题，留到下一个主题来
常用模式
蝈蝈 大家经常用到的模式有哪些呢
蝈蝈 singleton，factory，模板，这些都是模式中经典的，但是相对比较容易的
wayfarer 不要盲目追求复杂的模式，往往会造成过度设计
RoyDeng Composit 在有樹狀結構的場合應用。非常普遍
umlchina facade比较好用尤其是对付一大堆杂乱的代码的时候
wayfarer 其实Template模式，我相信很多人都用过
idior 强烈推荐bridge strategic state 他们是Favor composition over inheritance的体现
蝈蝈 其实如果拿模式到一个系统中去套，我相信所有模式都用的上的
dudu 我现在在编程中也不刻意去考虑采用哪种模式
模式与架构
jeseeqing 我觉得架构是建立在模式这上的
Samuel 架构需要悟，和patten不是一个层面，模式接近语言层面
RoyDeng 架构？我倒覺得是用模式最多的地方
Samuel to RoyDeng: 实际上在设计架构时，并不会考虑模式 设计架构或者平台，主要的是通用性、延
展性和功能
RoyDeng 你看看.NET的FrameWork
Samuel 当决定了你需要的东西，用模式只是水到渠成 不用亦可
模式的实际应用
RoyDeng 我覺得越是面向商業，我們所說的模式就用的越少
vcfly.net 是的，因为他要考虑商业风险和代价
wayfarer 关键是，我们是做项目，还是做产品
vcfly.net 我给一些公司写过软件，他们只考虑功能的实现，基本就不考虑后期的维护，只要拿到钱了，
他们就不管了，所以你和他们说模式，全是废话
wayfarer vcfly，你当然不能给客户说模式了 你只能说你的产品性能、功能，所需的时间，价格，模式
是帮助你，在设计中提高产品的性能，功能和未来的扩展
idior 有公司面试要求模式的吗？不是说面试者个人
jeseeqing 有,我以前的公司就面试过
wayfarer 我以前公司就要求 成都的一家小公司，凯威斯特
模式的作用
wayfarer 我想问大家：设计模式在项目开发中对你们的帮助是怎样的
蝈蝈 我觉得最大的好处就是省写很多代码
idior 维护性和可扩展性 适应未来的变化 理解oo对模式也就理解的差不多了，同样学习模式可以
帮助你理解oo
wayfarer 其实，通过我对设计模式的学习，确实加深了我对OO的理解
春鱼 我觉得模式还有利于沟通
du 模式是很多人经验的总结，避免我们少走许多弯路，你可以不用模式，但你必须真正理解模式
wayfarer 我始终将模式看作两个层面：一是思想，他能帮助我们理清设计的思想；一个就是工具，他能
帮助我们有效地设计 不能为了模式而模式
dudu 建议大家床头放一本设计模式的书，没事就看看
idior 顺便说说模式的好处：
可以重用已有的好的设计，可以提供一套供程序员交流的语言
模式可以让你站在更高的角度去看待问题，看待设计的过程，更加体会OO的思想，而不是过早的
卷入编码的细节。
看待问题应该从大处着眼，而不是关注于实现的细节。模式可以提升你看问题的抽象程度。这才
是模式最大的益处。
模式是经过考验的思想，比那些突然的想法更可靠，更具有扩展性。
通过学习模式将对OO的思想有更深的体会。
这是我对讨论的摘要。大家可以在此基础上继续评论。这样聊天就可以继续啦 :） 希望大家响应啊，那样在下
次开会前就能整理出一个更完善的模式专题报告. 不然一个小时的时间实在太少啦，通过这种方式可以延长讨
论。
我突然想到一个方式，就是在team讨论的时候，大家引出一些观点，并给出一些争论，然后通过评论的形式，
将讨论不断完善。最后再加以总结。大家觉得怎么样？
